News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu

Finding sprite routine in game code (using disassembler)

Started by ssr86, 18:54, 04 December 13

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

ssr86

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...

arnoldemu

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.
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

ralferoo

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...

Executioner

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).

redbox

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).

AMSDOS

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.
* Using the old Amstrad Languages :D   * with the Firmware :P
* I also like to problem solve code in BASIC :)   * And type-in Type-Ins! :D

Home Computing Weekly Programs
Popular Computing Weekly Programs
Your Computer Programs
Updated Other Program Links on Profile Page (Update April 16/15 phew!)
Programs for Turbo Pascal 3

arnoldemu

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).
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

fano

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.
"NOP" is the perfect program : short , fast and (known) bug free

Follow Easter Egg products on Facebook !

ssr86

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".

Powered by SMFPacks Menu Editor Mod