| |
mhindsbo
Registered: Dec 2014
Posts: 51 |
Code optimization
I thought I would tap into the creativity here to see if you have optimization suggestions for the following.
For my game I have a list of objects. When an object spawns I set bit 7 in the first byte of the table so I dont spawn it again while it is active (or if it is destroyed). If the object leaves the screen without being destroyed I flip the bit back again.
Each active objects stores the address of its location in the spawn table and uses the following code to 'reactivate' itself if/when it leaves the screen.
lda object_d6,x ; lo byte of address
sta tempz+0 ; location in zero page
lda object_d7,x ; hi byte of address
sta tempz+1
ldy #0
lda (tempz),y
and #%01111111 ; clear bit 7
sta (tempz),y
That is 29 cycles +3 if page boundary is crossed. Any optimization ideas?
I could of course just add another byte in the object table so I dont have to set/clear a bit, but that adds potentially hundreds of bytes ekstra for a given level. |
|
... 20 posts hidden. Click here to view all posts....
|
| |
Copyfault
Registered: Dec 2001
Posts: 483 |
Hmm, now even though the initial problem is solved already, the following idea just crossed my mind: you could use x (or y) plus a byte in zeropage as index information, and directly use zp-adressing modes for access. I.e.:
$02 $00 (always!) ;lo-byte for accessing information-table, always =$00
$03 (hi-byte of index) ;hi-byte for information-table "=" hi-byte for index
... ...
ldy #obj_index_lo ;full object-index consists of this y-value plus the value currently in $03
lda ($02),y ;get information from table
The number of different values put in $03 gives a multiplier for the $100, extending the index range accordingly. So no need to initialize the vectors on every access to the object information, only if the index value overflows. Could cause problems because most probably the index-hi-byte cannot just be $00, $01, etc but rather some suitable pointer to a mem page. Plus, one needs even more differnt hi-byte-values if different table types come into play (isactive, position,...). |
| |
Oswald
Registered: Apr 2002
Posts: 5118 |
I'd rather duplicate code for the next 256 objs, and branch. fex c can hold the 9th bit for that. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1423 |
Nah, this calls for a complex spooling system - overwrite half the objects as you approach a new area, using a custom decruncher that writes scattered data from a compressed representation that was background-loaded earlier \o/ |
| Previous - 1 | 2 | 3 - Next |
