Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in - nap
CSDb User Forums


Forums > C64 Coding > Code optimization
2018-12-25 15:21
mhindsbo
Account closed

Registered: Dec 2014
Posts: 50
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.
2018-12-25 16:35
Icon

Registered: Jul 2012
Posts: 1
You could preset tempz + 0 to zero (perhaps during initiation of the game) and do the following:

ldy object_d6,x ; lo byte of address
lda object_d7,x ; hi byte of address
sta tempz+1

lda (tempz),y
and #%01111111 ; clear bit 7
sta (tempz),y

Then you are down to 24 cycles and the code is 4 bytes shorter.
2018-12-25 18:34
Frantic

Registered: Mar 2003
Posts: 1627
...or you could move that byte out of the object and keep it in a table, and just do:

lda objectflagtable,x
and #%01111111 ; clear bit 7
sta objectflagtable,x

Not sure if that would work in your case, as it may break your approach of using "objects", but generally speaking it seems like a possibility.
2018-12-26 05:27
ChristopherJam

Registered: Aug 2004
Posts: 1378
What is the range of values stored in that first byte? (clearly it's at most 0..127 or you couldn't safely trash bit 7)

If you're also not using bit 6 you could store (0x40+value) for an inactive object, (0x80+value*2) for an active one.

Then you can just use ASL and LSR to activate/deactivate. Combining with Frantic's suggestion, your code then becomes
   lsr objectflagtable,y  ; 7 cycles
2018-12-26 08:03
mhindsbo
Account closed

Registered: Dec 2014
Posts: 50
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.
2018-12-26 10:47
Raistlin

Registered: Mar 2007
Posts: 552
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
2018-12-26 10:54
Raistlin

Registered: Mar 2007
Posts: 552
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.
2018-12-26 11:13
Hoogo

Registered: Jun 2002
Posts: 102
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.
2018-12-26 11:40
Raistlin

Registered: Mar 2007
Posts: 552
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...
2018-12-26 12:17
Oswald

Registered: Apr 2002
Posts: 5017
"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.
2018-12-26 12:24
Raistlin

Registered: Mar 2007
Posts: 552
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.
 
... 13 posts hidden. Click here to view all posts....
 
Previous - 1 | 2 | 3 - Next
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
Sokratekk
Paladin/G★P
MCM/ONSLAUGHT
manganoid/Hokuto Force
Sentinel/Excess/TREX
Mason/Unicess
wil
bisboch/HF
Scooby/G★P/Light
iAN CooG/HVSC
Guests online: 159
Top Demos
1 Next Level  (9.8)
2 Mojo  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 Comaland 100%  (9.6)
6 No Bounds  (9.6)
7 Uncensored  (9.6)
8 The Ghost  (9.6)
9 Wonderland XIV  (9.6)
10 Bromance  (9.6)
Top onefile Demos
1 It's More Fun to Com..  (9.8)
2 Party Elk 2  (9.7)
3 Cubic Dream  (9.6)
4 Copper Booze  (9.5)
5 Rainbow Connection  (9.5)
6 TRSAC, Gabber & Pebe..  (9.5)
7 Onscreen 5k  (9.5)
8 Wafer Demo  (9.5)
9 Dawnfall V1.1  (9.5)
10 Quadrants  (9.5)
Top Groups
1 Oxyron  (9.3)
2 Nostalgia  (9.3)
3 Booze Design  (9.3)
4 Censor Design  (9.3)
5 Crest  (9.3)
Top NTSC-Fixers
1 Pudwerx  (10)
2 Booze  (9.7)
3 Stormbringer  (9.7)
4 Fungus  (9.6)
5 Grim Reaper  (9.3)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.044 sec.