Author Topic: ChangeLog  (Read 9128 times)

Akari

  • Moderator
  • *
  • Posts: 766
    • View Profile
ChangeLog
« on: 2006-05-09 20:40:26 »
Revision 63
Case switch done, UpperCase/lowercase clean up. Clean compile on linux. (halkun)


Revision 59
Added all opcodes (dummy) to script parser/fixed scriptdump bugs.  (halkun)


Revision 49
WorldMapModule.h, WorldMapModule.cpp - add placeholder for worldmap module

displaytest.cpp - add M button to go to WorldMap Module.


Revision 47
Start documenting engine by doxygen.

config.h, config.cpp - switched to RString. Removed old param. Now it contains field dumper flag and name of field to load (temporary).

TypeDefine.h - moved u8 u16 u31 s8 s16 s32 definition to separate file from File class.

main.cpp, guitest.h, guitest.cpp, displaytest.h, displaytest.cpp, ModuleManager.h, ModuleManager.cpp, menu.h, partymenu.h - renamed Screen to Module.

displaytest.cpp - add N button to go to Field Module.

math.h, math.cpp - math for pathfinding in field (needs to be merged with other math later)

NoCopy.h, File.h, File.cpp, ModuleManager.h, ModuleManager.cpp, TimFile.h, TimFile.cpp, BinGZipFile.h, BinGZipFile.cpp, LzsFile.h, LzsFile.cpp - rewritten for doxygen and according to standart.

3dtypes.h - add matrix header.

display.h, display.cpp - add method to load camera matrix.

vector.h - add equal, not equal methods.

guibarexp.h, guibarexp.cpp - add fury, sadness states.

savemap.h, gamestate.cpp - fix savemap.

model.h, model.cpp - add placeholder for model.

fieldscreen.h, fieldscreen.cpp, datfile.h, datfile.cpp - add Field Modile (load walkmesh, set camera).

Revision 28

Move all class copy restrictions to NoCopy template.

Create "Dat" file loader for fields.

Create Field screen class.


Revision 30

New RString class implemented. Based on StdString template.

Logger switched to RString.

itoa removed from Utilites.


Revision 31

Add Tim handling class and example in displaytest.cpp

Some small fixes.


Revision 32

Small fixes with struct aligment in SaveBMP and with picture width in TimFile.


Revision 40

Added FFVII GUI support with 2 types of font, counter and pointer and gui testing screen.
Moved all testing screen to separate dir.
Add kernel.
Moved config and logger to utilites.
Added some finor fixes and functions to help with all changes.

Revision 43
Create Timer.
Create a lot of window elements.
Create 'Party Menu'
Add a lot of things to GuiTest.
Add loader for data in database.
Fix small errors.
« Last Edit: 2006-07-16 21:47:01 by halkun »

Alhexx

  • *
  • Posts: 1894
    • View Profile
    • http://www.alhexx.com
Re: ChangeLog
« Reply #1 on: 2006-05-18 21:25:04 »
Wow, quad-post!

I think it would be a better idea to mark this topic sticky and just edit the first post every time. Otherwise this will be a few-hundrets-post topic just with change-logs.  :|

The problem is not that I am concerned that your post-count increases  :-P , but the board software will start marking a multi-page thread of this, since it's configured to have at max ~20 posts per page, so a reader would have to go through a few pages to read the changelog.

That's the reason why I merged your four posts to one.

 - Alhexx
« Last Edit: 2006-05-18 21:27:40 by Alhexx »

Sad Jari

  • Guest
Re: ChangeLog
« Reply #2 on: 2006-05-18 21:55:12 »
The problem is not that I am concerned that your post-count increases  :-P
Besides, at least phpBB used to count each edit as a new post anyway. :lol: Not sure if SMF does the same.

Ok, I'll stop spamming now.

Akari

  • Moderator
  • *
  • Posts: 766
    • View Profile
Re: ChangeLog
« Reply #3 on: 2006-06-09 15:32:03 »
up.

halkun

  • Global moderator
  • *
  • Posts: 2097
  • NicoNico :)
    • View Profile
    • Q-Gears Homepage
Re: ChangeLog
« Reply #4 on: 2006-06-09 17:49:00 »
If you haven't already, add this to trhe ChangeLog file in SVN. Thanks

Akari

  • Moderator
  • *
  • Posts: 766
    • View Profile
Re: ChangeLog
« Reply #5 on: 2006-06-16 19:38:11 »
New Update... you'll need savemap (put it into data directory under name "savemap") and INIT and MENU directory. Place them into data dir.

Akari

  • Moderator
  • *
  • Posts: 766
    • View Profile
Re: ChangeLog
« Reply #6 on: 2006-07-03 17:59:15 »
Up.
Finished first sketch for field module.
You need FIELD dir in addition to mentioned above.

Akari

  • Moderator
  • *
  • Posts: 766
    • View Profile
Re: ChangeLog
« Reply #7 on: 2006-07-13 15:35:25 »
I already implement few opcodes: WINDOW, ASK, RET and a lot of conditional and unconditional jumps.
The code is still draft and looks ugly because I do a lot of experiments, so it's the only way out =)

Look at the screen of current progress. I still experiment with STARTMAP.



And I cant log in to upload changes to SVN.
« Last Edit: 2006-07-13 16:12:15 by Akari »

Cyberman

  • *
  • Posts: 1572
    • View Profile
Re: ChangeLog
« Reply #8 on: 2006-07-13 16:24:33 »
You can't?
Ummm hmmm I was going to submit my updates to it via SVN ..
We do need to remove some directories.  Dang it I now have to go look to see how I can just upload my changes without changing the entire repository.

I probably by the weekend I'll have the ISO code up.  It took a long time (mutter) to do that much (mutter).

Cyb

halkun

  • Global moderator
  • *
  • Posts: 2097
  • NicoNico :)
    • View Profile
    • Q-Gears Homepage
Re: ChangeLog
« Reply #9 on: 2006-07-16 19:26:00 »
I highly sugest you guys do an SVN update.

I took last night and put placeholders (with output) to ALL of the fieldscript opcodes in Script.c and Script.h. (i.e. The entire 256 case switch is in there)

Now I can't compile q-gears at the moment. (I didn't even try) so most likely it's going to barf at compile time due to a off-by-one error or a forgotten semicolon or something.

If it compiles and works the first time, without you touching my code, I will personally send the person who did it first a framed American $10 bill. <--- Not joking, I'm pretty sure it's going to fail.

Some comments on the script dumper.

Akari, You are going to wind up repeating yourself a whole lot with the way the script parser woks now. You need to exteralize some of the more common subfunctions. For example the relational parser for the conditionals and the opcode argument fetch routines. When you grab a byte from the script buffer, you don't automataclly increment the buffer pointer. (My script dumper does by way of using getc(); and extracting the data right off the disk) On read, the file pointer is automaticly incermented byte and saves a lot of needless pointer pushing.

Take a peek at my raw script dumper, even though it's kind of ugly, there is some elegence in there. There needs a function to tell the script parser to get n[/n] amount of arguments and shove the index pointer to the next opcode. Doing 249 "for loops" were a pain and very bug prone.

Also, I did not fetch the correct number of arguments for KAWAI. (This is a bug in my script dumper too) as I haven't come across the function yet in my test dumps.

Ther than than, I hope this helps a little.



I also hoped I declared the varibles correctly

Synergy Blades

  • Guest
Re: ChangeLog
« Reply #10 on: 2006-07-16 19:36:25 »
You need curly braces { around your case statements }. eg:

case PREQ:
{
 // stuff;
 break;
}

case REQ:
{
 // stuff 2
 break;
}

..


For every code, here's what it currently says on compiling:

  [General Error] Too many messages; abort.
  There must be something terribly wrong with your code. Please fix it.

 :-D

halkun

  • Global moderator
  • *
  • Posts: 2097
  • NicoNico :)
    • View Profile
    • Q-Gears Homepage
Re: ChangeLog
« Reply #11 on: 2006-07-16 19:41:36 »
That's odd.
I don't have curlies  around my statements in the script dumper.... Is that a c++ thing?
 

Synergy Blades

  • Guest
Re: ChangeLog
« Reply #12 on: 2006-07-16 19:44:32 »
I expect so. The dumper compiles fine because it's compiled using the C compiler, not as C++; when putting it in the .cpp file, it needs curly braces.

halkun

  • Global moderator
  • *
  • Posts: 2097
  • NicoNico :)
    • View Profile
    • Q-Gears Homepage
Re: ChangeLog
« Reply #13 on: 2006-07-16 21:44:39 »
Ok, I've switched the case and fixed all the bugs in the script dumper. It compiles cleanly on Linux, but I can't run it with my Gimpy OpenGL.

Someone on the windows side needs to fix the makefile/depend list to refect the lower case name. I know it doesn't matter win win32, but even though wiondows is case insensitive, it is case *preserving* and give us case sensitive people a bit of heartache.

Thanks.

I should write a script that generates a makefile from DevC++'s dependecy list.

I'm burnt out. Happy Christmas! I hope you like the improved script..... thing.

Akari

  • Moderator
  • *
  • Posts: 766
    • View Profile
Re: ChangeLog
« Reply #14 on: 2006-07-18 14:04:26 »
I took last night and put placeholders (with output) to ALL of the fieldscript opcodes in Script.c and Script.h. (i.e. The entire 256 case switch is in there)

Please, don't do anything with field module (everything that in game/field directory). I'm still working on it and I have a lot things in my mind that needs to be done and I intentionally didn't write placeholders for opcodes. This is still draft of whole module that can be totally rewritten in future.

I'll revert all changes with it. Please don't touch it for a while.

Quote
Akari, You are going to wind up repeating yourself a whole lot with the way the script parser woks now. You need to exteralize some of the more common subfunctions. For example the relational parser for the conditionals and the opcode argument fetch routines. When you grab a byte from the script buffer, you don't automataclly increment the buffer pointer. (My script dumper does by way of using getc(); and extracting the data right off the disk) On read, the file pointer is automaticly incermented byte and saves a lot of needless pointer pushing.


Everything is done intentionally. It's easier for me to test and experiment with opcodes this way. Just as I say before it's still draft of final module.

Cyberman

  • *
  • Posts: 1572
    • View Profile
Re: ChangeLog
« Reply #15 on: 2006-07-18 15:46:00 »
Hey Akari.

Hmmmm how about we break up the field script module into sections of code?
Instead of writting the code within each case statement, instead we use a function call in the case statement.
This will keep the case statement and all code in that module SANE.
Erstwhile people can work in various sections of opcodes (I suggest we group them acording to function) independantly this way.
It eliminates this kind of gotcha some, makes the code for it much easier to annotate (IE comment), and most importantly removes the code wading from hell problem of finding a bug in an opcode (you don't need to wade through 2300 lines of code to find it).
halkun
Also as a side note, you should return data in a function in one place.  A local variable should be used to contain the return value information.
This prevents weird bugs from happening due to compilor differences and lazy programer syndrom.  I only mention this because it's a bad idea to stick a return statement in a case statement :D  you won't know where your code truely 'ends'  Surprisingly this also reduces the size of the generated code I've discovered.
Also an initial state for the return variable is best to be that of failure (whatever that might be).

Cyb

halkun

  • Global moderator
  • *
  • Posts: 2097
  • NicoNico :)
    • View Profile
    • Q-Gears Homepage
Re: ChangeLog
« Reply #16 on: 2006-07-18 18:06:55 »
Sorry, as you can tell, you and I come from different schools and philosophies of coding.

Placing a variable ouside a scope when I deem it "important" is a bad habit of mine, but I also like globals too. (This makes C++ and ther OO programmer shudder when I say this. Also, yes, I've been known to use "goto" as well. (To quote my cousin, "Wait, 'goto' is a valid keyword in C?"; My answer, "No, it's not, but I use it anyway. (^_^)")

This also has to do with my very weak grasp of pointer refrencing.

Breaking out the commands is a good idea. However, we need to make helpers when you do the same thing over for groups of commands, like split the priority/script in half or "to bank/from bank" or evaluating a conditional in the IF* statements.

That's all I can think of now...


Cyberman

  • *
  • Posts: 1572
    • View Profile
Re: ChangeLog
« Reply #17 on: 2006-07-18 19:05:02 »
Sorry, as you can tell, you and I come from different schools and philosophies of coding.

Placing a variable ouside a scope when I deem it "important" is a bad habit of mine, but I also like globals too. (This makes C++ and ther OO programmer shudder when I say this. Also, yes, I've been known to use "goto" as well. (To quote my cousin, "Wait, 'goto' is a valid keyword in C?"; My answer, "No, it's not, but I use it anyway. (^_^)")

This also has to do with my very weak grasp of pointer refrencing.
Not commenting on your bad habits, just saying here are some good habits.  In this kind of project it's good to be careful especially in complicated functions such as ye olde script dumper.

Breaking out the commands is a good idea. However, we need to make helpers when you do the same thing over for groups of commands, like split the priority/script in half or "to bank/from bank" or evaluating a conditional in the IF* statements.

That's all I can think of now...
All good.
Helper functions are a good idea, this makes the whole thing flow better and less cluttered redundant and repetitious.
One thing I was pondering instead of printf etc why not use a memory stream we pass the dump to.
This way the code dump can go to .. a window the clipboard or STDIO.  It would also allow the dumper to be put into the main program and used for various things (better than Nefarious ;)).