Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
 Welcome to our latest new user zschunky ! (Registered 2019-02-20) You are not logged in 
CSDb User Forums


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

Registered: Dec 2014
Posts: 40
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....
 
2018-12-27 10:23
ChristopherJam

Registered: Aug 2004
Posts: 900
I'm a bit confused about the number of objects thing.

Surely even the original question presupposes no more than 256 objects, as their addresses are stored in the object_d6/object_d7 tables, which are just indexed by X?

And I'm not seeing how Copyfault's suggestion gets past that, unless the upperbitlist table is used to dynamically select for each object ID which of two possible objects it might refer to.

In either case, moving past 256 objects while still storing object ID in X is going to need some kind of system for managing a smaller subset of potentially active ones..
2018-12-27 14:09
cadaver

Registered: Feb 2002
Posts: 1079
In the original code, the X indexed variables are for currently active (onscreen) objects, of which there are much less than 256. The d6 / d7 variables point into an arbitrarily sized object spawn data.
2018-12-27 14:52
Oswald

Registered: Apr 2002
Posts: 4365
btw its hard to imagine a c64 game with hundreds (>256) npcs.. :)
2018-12-27 15:30
mhindsbo

Registered: Dec 2014
Posts: 40
The x indexed is active object data tables (x, y, image, ...) that are sorted etc. for sprite multiplexor.

hundreds of objects is easy ;-) Aviator Arcade has several hundreds of tanks, planes, etc. per level. that get spawned at specific locations on the map.
2018-12-27 16:29
mhindsbo

Registered: Dec 2014
Posts: 40
Thanks for the input. Discussing here made me restructure my data format.

Each tile row on the map now simply has a start index and an end index of object to spawn. If start and end index is the same number is means no objects to spawn on that row.

I will limit the number of objects for any given level to 265. And use the suggestion to change object type to 0 once it is spawned.

significantly simpler, smaller and faster.

Thanks again for all the input.
2018-12-27 17:13
ChristopherJam

Registered: Aug 2004
Posts: 900
Quoting cadaver
In the original code, the X indexed variables are for currently active (onscreen) objects, of which there are much less than 256. The d6 / d7 variables point into an arbitrarily sized object spawn data.


Ah! That makes sense, thank you.

mhindsbo, glad we could help :)
2018-12-28 02:27
Copyfault

Registered: Dec 2001
Posts: 251
Quoting ChristopherJam
[...]
And I'm not seeing how Copyfault's suggestion gets past that, unless the upperbitlist table is used to dynamically select for each object ID which of two possible objects it might refer to.[...]

I did not write out all the details, but you're right, I had some kind of dynamic link list in mind. Ofcourse this does not really widen the length of the index value (X-reg is still in gear) but this rather gives a possibility to choose between "sub"-objects.

For a proper 9-bit-index-value, it should work to use another register (e.g. a zp-reg) as a highbyte for the index-value and use this just like upperbitlist in my former code examples, just without any index! Downside will certainly be the code doubling to choose between the different tables used lateron, but with self-modification of the code this can be worked around I think.


@mindsbo: glad to read that you found a data structure for your need:) Looking forward to seeing what kind of game comes out of it!!!
2018-12-28 02:55
Copyfault

Registered: Dec 2001
Posts: 251
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,...).
2018-12-28 09:10
Oswald

Registered: Apr 2002
Posts: 4365
I'd rather duplicate code for the next 256 objs, and branch. fex c can hold the 9th bit for that.
2018-12-28 10:06
ChristopherJam

Registered: Aug 2004
Posts: 900
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
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
xIII/ATL/WOW
blendo75
Didi/Laxity
hedning/G★P
oziphantom
iceout/Avatar/HF
Nith/TRIÉ…D
Guests online: 71
Top Demos
1 Unboxed  (9.7)
2 Uncensored  (9.7)
3 Edge of Disgrace  (9.7)
4 Coma Light 13  (9.6)
5 Comaland 100%  (9.6)
6 The Shores of Reflec..  (9.6)
7 Lunatico  (9.6)
8 Wonderland XII  (9.6)
9 C=Bit 18  (9.6)
10 X Marks the Spot  (9.5)
Top onefile Demos
1 Smile to the Sky  (9.6)
2 Daah, Those Acid Pil..  (9.5)
3 Dawnfall V1.1  (9.4)
4 FMX Music Demo  (9.4)
5 Crystal Gazer  (9.4)
6 Rewind  (9.4)
7 Pandemoniac Part 2 o..  (9.4)
8 Official X2018 Report  (9.4)
9 Arok 20 Invitation  (9.4)
10 Party Horse  (9.3)
Top Groups
1 PriorArt  (9.7)
2 Performers  (9.5)
3 Oxyron  (9.5)
4 Booze Design  (9.4)
5 Censor Design  (9.3)
Top Hardware-Gurus
1 Soci  (9.9)
2 Wiesel  (9.9)
3 Grue  (9.8)
4 Zer0-X  (9.8)
5 Lemming  (9.7)

Home - Disclaimer
Copyright © No Name 2001-2019
Page generated in: 0.048 sec.