| |
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. |
|
... 13 posts hidden. Click here to view all posts....
|
| |
mhindsbo
Registered: Dec 2014
Posts: 51 |
Thanks. Some good suggestions here. I should perhaps have mentioned that XR refers to the active objects of which there are ~30.
All objects sit in a list linked to the map so they can be spawned when the player is at a specific location. The address I store relate to this table that contains hundreds of objects.
If the total number of objects ends up less than 256 I can use the object flag table idea. But could end up exceeding it. |
| |
Raistlin
Registered: Mar 2007
Posts: 684 |
Could the information be stored in a bit field? With 30 objects you could squeeze this into just 4 bytes and use something similar to the following code (17 cycles, 64 bytes of data and 12 bytes of code). Untested - but I -think- it should work..?
.byte Div8table:
.fill 32, i/8
.byte NegBitMask:
.fill 32, 0xFFFFFFFF - (1<<(i&7))
x is index 0-31
ldy Div8table, x //; 4 cycles
lda AddrTable, y //; 4
and NegBitMask, x //; 4
sta AddrTable, y //; 5 |
| |
Raistlin
Registered: Mar 2007
Posts: 684 |
Worth also saying ... you’d need an additional table with my suggestion of the regular bitmasks:-
BitMask:
.fill 32, 1<<(i&7)
And any other code for setting the bit and testing it becomes much simpler too. |
| |
Hoogo
Registered: Jun 2002
Posts: 105 |
The code looks nice, but all the tables take so much memory, 2 bytes of table for every used bit. In that case it would be better to spend a whole byte for the flag. Such a flag could also be easily reset by lsr, set by sec:ror and tested by bit. |
| |
Raistlin
Registered: Mar 2007
Posts: 684 |
True... it would only make sense if it helped in other parts of the code as well... if there were more flags other than Activated/Deactivated... |
| |
Oswald
Registered: Apr 2002
Posts: 5095 |
"If the total number of objects ends up less than 256 I can use the object flag table idea. But could end up exceeding it."
if exceeds it then use 2 object flag tables :)
Also it would be better to separate all object attributes into such tables, and just use ,x to reach any of your objects.
ldx #objectnr
lda xcoordinatetable,x
lda ycoordinatetable,x
lda isobjactivetable,x
etc. |
| |
Raistlin
Registered: Mar 2007
Posts: 684 |
Yep, Oswald’s right. Having 30 current objects makes this perfect - increase that to 32 (or pad by the extra 2) and align the data so that you never cross pages - that way your reads are always 4 cycles, writes are 5. Try to avoid indirect read/writes where you can. |
| |
Copyfault
Registered: Dec 2001
Posts: 478 |
If I get the initial problem right it is not only about those ~30 active objects but about how to cope with information on any object (be it active or not at a specific moment).
Thus, if there will be>$100 objects in total, also the initial code will come short as this would force to use more than 8 bits for the index register. If 9 Bits suffice this should be done with a case distinction, i.e.
ldx #obj_nr
lda upperbitlist,x
bne OBJECTS_0x100
OBJECTS0x00
lda isobjectactive_0x00,x
..etc..
OBJECTS0x100
lda isobjectactive_0x100,x
..etc..
If possible, use the upperbitlist such that it holds the hi_byte for the information fetch in question, i.e.
ldx #obj_nr
lda upperbitlist,x
sta OBJECTS_LD+2
OBJECTS_LD
lda isobjectactive,x
..etc..
(does maybe have to combined with an ORA as most probably there'll be different such tables)
Last but not least: is it mandatory to use bit7 for the "isactive"-information? If not, it might be a bit tighter to use bit0 and set/clear the active-information with an INC/DEC.
Depends on a lot of other things, so these are just loose ideas... |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
Is the object activation / deactivation a bottleneck even? Depends on the enemy layouts, but I'd imagine only a few objects leaving the screen per frame (and most often, none)
I have typically done it so that when I put an object onto the screen, I zero the object type byte from the spawn data, meaning "no object." Then, if the object leaves the screen without being killed, I store its type back. Therefore no bit manipulation needed. |
| |
mhindsbo
Registered: Dec 2014
Posts: 51 |
You are right. Activation and deactivation is most likely not a bottleneck as only one or two will happen each frame. It just felt that there should be a faster method. From an object handling point og view the original is actually fairly 'elegant'.
And yes the issue is not the subset of active objects, but the total list with more than 256 objects potentially. |
| Previous - 1 | 2 | 3 - Next |
