Is there a way to easily locate the sprite routine in a game code using Winape debugger?
Or the main loop... from there it should be easier...
Quote from: ssr86 on 18:54, 04 December 13
Is there a way to easily locate the sprite routine in a game code using Winape debugger?
Or the main loop... from there it should be easier...
look for code that looks like this:
ld a,(de)
ld c,a
ld a,(bc)
and (hl)
or c
ld (hl),a
sometimes if you just stop the game it can end up in a bit of code like this.
Alternatively look for lots of CALLs together, these are often the main loop.
Disable each (replacing with NOPs) to find which draw the sprites.
Sometimes you can find them this way too.
Probably if you run in an emulator and pause it during the game 50 times at random. Make a note of PC and try to determine where that block of code starts. Chances are that most sprite heavy games will spend most of their time drawing sprites and so you're likely to find you've paused the game in that area the majority of times.
Not a guaranteed rule, of course, but it's as good a starting point as any...
You could also try using the Graphics Finder to locate the sprites in memory if possible, then look for references to similar adresses (WinAPE disassembler can do FIND *#2000* for example).
The main loop for a game usually starts with a wait for frame flyback (or vysnc) routine.
ld b,&f5
.ml2
in a,(c)
rra
jr nc,ml2
From there you should find CALLs to the sub-routines (e.g. sprites, logic etc).
I remember looking at "Electro Freddy" one time and coming across the Sprite Routine it had in it which was pretty standard XOR Sprite Routine affair. From memory I just started from the Execution Address of the program and checked out what the various calls did. Given it's a really old game from 1984 and Firmware is used a bit (except in the sprite routine) and the size and simplicity of the game, things maybe easier to track in something that early vs. a lot of the later stuff.
Quote from: redbox on 23:47, 04 December 13
The main loop for a game usually starts with a wait for frame flyback (or vysnc) routine.
ld b,&f5
.ml2
in a,(c)
rra
jr nc,ml2
I find this is not always true when the game is driven using interrupts. The only time I see this code is often in the interrupt handler.
If the game runs at a fixed 50hz then yes, you will probably see this to synchronise it.
From there you should find CALLs to the sub-routines (e.g. sprites, logic etc).
A method to find main loop is to put a breakpoint on interrupt handler.This way , you can trace the stack to find the "lower" level of nesting, this is generaly the main loop.When you found it , you have to check what every call on it does.A good clue about what each subroutine do is to use nop/µs counter , object displaying routines usually use the bigger amount of time.
Thanks
I used fano's method and was able to somewhat locate the routines. It's quite hard for me to read the "raw" code in the debugger (without variable names and labels) though...
Learned something new about Winape:). I haven't noticed the option of 'disassembly' and 'find'. Also have never used 'find graphics".