Re: [stella] Boulderdash - musings and screen demos

Subject: Re: [stella] Boulderdash - musings and screen demos
From: Christopher Tumber <christophertumber@xxxxxxxxxx>
Date: Thu, 03 Apr 2003 14:11:35 -0500
>There are about 10 different thingies.  Butterflies, wall type 1,
>surrounding wall, etc...

Ouch, okay guess I never played Boulderdash as much as I thought.

Can all of these objects appear on every level? Or can they be limited somewhat (ie: levels can have butterflies or ameoba but not both)? With 3 bits you can express 8 different objects which might be enough if you redefine their meaning on a level by level basis. You're going to have a tough time getting anywhere near 64x64 (In this format, 1.4k) but maybe couple with a compression scheme?

I think you're still going to be looking at a "display buffer" that's either the actual data used to draw the screen or one step removed (so it can be processed on the fly) and then all the off-screen data stored in a compressed/packed format and swapping between the two as the view changes. You'd have a pretty tough time doing RLE decomp on a line by line basis on the fly while drawing the screen.

You could probably come up with some format that would allow you to scroll on a square by square basis. Say 5 buffers in total, first buffer is still the display buffer. Second buffer is all the area of the virtual screen to the left (including up&left/down&left of the visible screen. The third buffer is all the area to the right (including up&right/down&right) of the visible screen. The fourth buffer is the area above (but not up&right/up&left) the visible screen. The fifth buffer is the area below (but not down&left/down&right) the visible screen. The size of these buffers will vary depending upon the positioning of the visible area of the playfield - ie if the visible area is the upper left corner of the playfield then buffers 2&4 will be empty while buffers 3&5 will be quite large (so these will need to be allocated RAM dynamically). Reallocating, packing and repacking these buffers for every scroll would be a chore but not impossible...

>It's a good idea, but consider the worst-case where the player simply
>removes all the dirt.  THEN you have to somehow store a playfield that is
>mostly (but not all) spaces,

So then reverse the scheme - You have a bitflag, at the begining of a level it's cleared and the level data is stored "All dirt except where specified". Once it gets to a 50/50 split (or some other thresehold depending upon the compression used) the bitflag is set and the data is converted to "All blank spaces except where specified". If you're using some kind of RLE (&etc) compression, you could determine which state offers the best compressed data and keep switching back and forth. Best of both worlds and all that. You are going to need to keep a bit of a buffer available for the conversion process but you're probably going to do that anyway... 

>Basically I really want to start a
>cartridge standard which provides bankswitching and extra RAM (say, 1 or
>2K).  That would *really* open up the doors to interesting programs.

Yeah, a hardware solution would be ideal and extremely usefull for everyone. However, harware soloutions tend to be a big bottlenecks.. (It could be a long while before such a cart is a reality)


Archives (includes files) at
Unsub & more at

Current Thread