Hi Glenn!
> I'm only using PF1 and PF2 so that means 32 bits per row and I'd like to
> have about 23 or so rows, about 8 pixels tall, which brings me up to about
> 100 bytes RAM usage. When I add in all the rest of the gamestate, which is
> 4 X/Y positions, the score, etc... that doesn't leave much breathing room.
> The thing is, I will never fill up the entire screen with tombstones.
> If I know, for instance, that I will never have more than 32 tombstones,
> then I could store it in 32 bytes as a list of tombstones, the value of
> which is an index to a pixel.
What about limiting the number of tombstones per row?
Let's say you've a max of four TS per row and you have tables like this:
level1 .byte #<row1, #<row2, #<row3 ...
ORG FX00
row1 .byte pos3, pos6, pos12, empty
row2 .byte pos1, pos5, empty, pos16
...
Now in the kernel you'd access these tables like this:
LDX level1,Y
LDA FX00,X
LDA FX00+1,X
LDA FX00+2,X
LDA FX00+3,X
But I think you'll see only in practice which idea is best...
(At least this is true for me, being a die-hard try&error coder :-))
Greetings,
Manuel
-----------------------------------------------------------------------
Neu: Die Lern-, Spaß- und Erlebniswelt von Nexgo für Kinder
von 4 bis 12 Jahren können Sie jetzt kostenlos testen:
Klicken Sie einfach hier und ermöglichen Sie Ihrem Nachwuchs
den Vorsprung in der Informationswelt von morgen.
http://www.nexgo.de/family/kinder.php
-----------------------------------------------------------------------
-
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
