Re: [stella] Maze Craze and 650x

Subject: Re: [stella] Maze Craze and 650x
From: "Thomas Jentzsch" <tjentzsch@xxxxxx>
Date: Tue, 21 Aug 2001 09:31:36 +0200
Erik Mooney wrote:
>> >I think the biggest challenge wouldn't be so much in the display, but in 
> >the memory.  The simplest brick-breaking game could allocate one bit per 
> >brick.  However, with Arkanoid, you'd need more bits per brick in order to 
> >store its color, how many hits it has taken (for silvers), and whether or 
> >not it hides a capsule.  Assuming four bits per brick, that's only two per 
> >byte, so an 8x16 field (for example) would cost 64 bytes. 

You could reduce that, if there are not to many "uncommon" bricks. Just store 
this data seperated and you might get an average of about 2 or 3 bits. But see below...

> Sure, 64 bytes... that's half the 2600's RAM usage, and already covers the
> majority of Arkanoid's RAM needs.  This can be handled, maybe through
> constraints, something like making the levels not have more than two
> silver bricks per row.

Another problem is, that you need a lot of RAM to display the PF, too. 

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 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 this approach may help saving some bytes, although it would be "a bit" more complicated for Arkanoid.

I found a similar solution in River Raid, where Carol doesn't have any score variables, but is doing all calculations directly on the score _pointers_. But I'm not sure if she did this because of RAM (I doubt this) or cycle optimization (has to be compared). 

Have fun!
Thomas Jentzsch         | *** Every bit is sacred ! ***
tjentzsch at web dot de |

Sie surfen im Internet statt im Meer? Selbst schuld!
Auf zum Strand:

Archives (includes files) at
Unsub & more at

Current Thread