Author Topic: Disorganization incarnate <source Q-gears direction and wot's up?> Debugging  (Read 2710 times)

Cyberman

  • *
  • Posts: 1572
    • View Profile
Much silence apart from porting.  However I will be testing the ISO code this day.  I need to make more ISO files too. Ahem.
The ISO code will make Linux testing and coding easier. <-- simple idea at least.
However do we have a debugging step by step system for game starting etc. ?
I think the state of things is great but we might want to focus on stepping through bits of the script with the engine.
We do have a script dumper which will help facilitate this, and inspite of it being incomplete, it's still useful.
So Q-gears debugging console is my next proposed step.  An IDE would be nice however I'm slightly confused (confuzled?) as to wher eto start with a GUI variant so a nice window with a console will be the first animal. Also the debugging I proprose should use a SOCKET. This makes the debugging program seperate from the primary program.
My proposed system is simple.
 q-gears --debug (-D) on the command line sets q-gears to switch on debugging for the game.
 --debug=##### sets the port default port should be 19974 (release date of FF7 and random month?)
 in addition the debug switch can have an option to break at the first point of script execution when the engine loads the game.
Proposed command structure
Each command is terminated by a carriage return <CR> line feeds are ignored (IE <CR><LF> pair the system will only respond to the <CR> and the <LF> will be striped).
S<CR> single step perform 1 opcode and stop
S###<CR> step multiple times (###)
Both of these instructions execute all running scripts one step.
D???? <CR> dump  Complex command dumps hex data by default from a specified location.  Addressing system etc. needs to be worked on.
 Should be able to dump
 STACK
 VARIABLES <temporary>
 GAME VARIABLES <all types and sizes>
 ENTITY and ENTITY state
 SCRIPT STATE
W????<CR> write to an address some data.
B????<CR> break point manipulation
R<CR> reset the engine (IE game engine reboot)

In any case addresses Data etc. Should be in HEX format.  Dumping is much the same.

The idea is to have an external program handle the debugging.  This will allow for example Q-gears to run on one machine and the debugger another (display wise much simpler in my view).
Since the debugger information will be game specific, I recomend storing the variables, descriptions of the variables, opcode and decoding information reguarding them be stored in external XML based files. This makes it easier to create new 'templates' for more game engines as they are added to Q-gears.

Cyb - now testing ISO code.