[stella] Boulderdash - musings and screen demos

Subject: [stella] Boulderdash - musings and screen demos
From: "Andrew Davie" <atari2600@xxxxxxxxxxxxx>
Date: Wed, 2 Apr 2003 23:18:08 +1000
Just having a play with Boulderdash, once again.

In particular, it occured to me that Interleaved ChronoColour (TM) screens
might be usable for this game - and I started playing around with some
samples to see what it would look like.  Check "BoulderDash13x.bin" for the
first attempt.  This has 13 blocks across - the thinking was that if each
block was 3 PF pixels wide, then we'd have one left over and it would look
OK.  It does look OK, but I couldn't figure a good way to represent the
screen in RAM and build on-the-fly.

The next effort - BoulderDash10x.bin is more promising.  This uses 4 PF
pixels across for each block, giving 10 across the screen.  The Interleaved
ChronoColour (TM) system essentially sets up 6 pointers per line, each of
those being a 1:1 relationship to the 6 asymmetrical PF bytes per line.  My
thinking is that the most any of these bytes contains is just 2 blocks (of 4
bits each) - that is, each block is 4 pixels, and there are 8 pixels at most
in any PF byte.  So there are only a small number of combinations possible -
dirt/diamond, dirt/dirt, etc.  In fact,  it's the number of different
object-types, squared.  If each block was (say)20 lines deep, and there were
10 different types, then that would e 100 x 20 = 2000 bytes for the graphic
data.  Seems reasonable.

So to build a playfield, one would just have to point each of the 6 PF
loading (ind),y addresses to the correct 2-block area(s) in the ROM.  Of
course, this is further complicated by the Interleaved ChronoColour RGB
multi-colour definitions - but I'm trying to keep things simple here.
BoulderDash isn't going to fit into a 4K cart - so let's assume we're
looking at a 32K cart.   So for RGB, with the 2-block graphics format,
that's x3 = 6K (roughly) for the background source images of the block

So, the kernel would draw 20 lines of blocks using the ICC(TM) draw loop,
and in the spare time available during those 20 lines, setup the next block
of 6 (ind),y pointers for the next group of 10 blocks.  etc.  That all seems
pretty straightforward, and it automatically encompasses scrolling, too - as
that's catered for at the time you figure out what blocks you're displaying.

The only real issue, then, is one of how to store the data for the playfield
in what little RAM is available.  If there were just a little more RAM, then
this would be a fairly straightforward project, I think.  Perhaps we should
just bite the bullet and specify/use a 3F bankswitching RAM format.  The
ICC(TM) system proposed above would basically need 24 bytes for the drawing,
leaving just 100 for the actual playing area - not enough.

In any case, thought I'd share these musings.  I don't think the screen
binaries themselves are too bad.  Not as nice as Thomas's effort, but they
are much easier to draw and manage.


Attachment: BoulderDash10x.bin
Description: Binary data

Attachment: BoulderDash13x.bin
Description: Binary data

Current Thread