Hi Thomas!
Von: Thomas Jentzsch <tjentzsch@xxxxxx>
> I've just started disassembling Surround, which has a 20x20 field:
> Alan uses 100 bytes for this, 5 bytes for each row (1*PF0, 2*PF1+PF2), which
For Arkanoid you could do just 2*PF1+PF2 and you'd certainly not have
20 lines of bricks, but maybe only 8, reducing the data to 32 bytes.
Decoding 4 different states of bricks would then cost 96 bytes, doing it the
easy way.
Might do...
> is the most compact format if you can't calculate the data during the
> display kernel. So ALL manipulations of the field are done directly on the
> data that is needed in the kernel.
I think it'd be too much to calculate. Between two lines of bricks you'd have to
to calculate 4 new PF values. Maybe if you'd get all of that in 2 scannlines,
it'd look ok. But in these 2 calculating-scanlines you'd already lose some cycles
for this sequence:
LDX #$1X
TXS
CPY Ball1
PHP
CPY Ball2
PHP
CPY Ball3
PHP
which you'd have to execute in both calculation lines...
> I think this approach may help saving
> some bytes, although it would be "a bit" more complicated for Arkanoid.
It still might work out in the end :-)
Hm... while displaying one line of bricks, you possibly can already
calculate part of the next?
Looks like we're working on yet another Holy Grail...
BTW: No - I've no intention at all doing it. But I admire the problem :-)
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/
