Re: [stella] Playfield ram usage

Subject: Re: [stella] Playfield ram usage
From: "Thomas Jentzsch" <tjentzsch@xxxxxx>
Date: Wed, 22 Aug 2001 12:54:51 +0200
Manuel wrote:
> 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

That a very good approach, I really like it! 
And by ORing two positions into ony byte (i.E. row1 .byte pos2|pos3, ...) it would be possible to put more than one tombstone into one PF variable.

As this happens inside the kernel, every cycle counts, so I have a little improvement:

Store the data for the (i.E. four) tombstones different and save the level1 table:



first:  .byte pos3,  pos1, ...
second: .byte pos6,  pos5, ...
third:  .byte pos12, empty,...
fourth: .byte empty, pos16,...

The kernel could look like this:

  ldy level  
  lda FX00+NUMROWS*0,y
  lda FX00+NUMROWS*1,y
  lda FX00+NUMROWS*2,y
  lda FX00+NUMROWS*3,y

The problem is, that I don't know, if Glenn is generating random levels or not. 

For predefined static levels this works perfect.
For somehow limited random levels, a small (NUMROWS bytes) RAM table (store offset into a bigger ROM table with predefined tombstone patterns) would be necessary. 
If the tombstones should be totally random, this approach won't work. :(

> But I think you'll see only in practice which idea is best...

That's how coding for the 2600 works, sometimes a very little design change results in a totally different optimal solution.

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

______________________________________________________________________________ - 570.000 Nutzer, ein Ziel: der optimale Flug

Archives (includes files) at
Unsub & more at

Current Thread