atari2600land's Blog

Looking at the mazes they would compress well using Run Length Encoding (RLE) in my opinion :-

 

http://en.wikipedia.org/wiki/Run-length_encoding

 

You'd be able to get a load of levels in the game then. Or if they are all made from the same sized block and not corner pieces you could compress even further into byte masks e.g.

 

%00011100 would draw :-

 

" ||| "

 

On the screen with the right drawing rioutine.

Yeah, I suppose so, but I have no idea how I would go about doing that.

For bitmap mask style data you'll need to :-

 

Initialise a register to the start of video RAM.

Initialise a register (if possible) the map data of interest.

Create a loop #1

Load the map byte from memory into an accumulator

Create a loop #2

Shift the accumulator left once

if carry is set draw a block

if carry is clear draw a space

increment the video ram register.

adjust the loop counter

Keep going (back to #2) until you've done 8 loop iterations.

Increment the map data register.

Keep going (back to #1) until you've drawn all the map.

 

I'm not familiar with the G7000 architecture so you'll have to adapt the process to suit.

Actually, the maps are pretty compact as they are... you actually only write out 18 bytes per level. What's actually bloating up the size is that you write everything using distinct commands ratger than reading the data from a table.

 

You could read all your level data from a table, similar as you do it now for your shape data. Actually, part of your shape reading routine could be re-used for doing this. For even more effiency, since you need multiple sets of level data, you could read the start of each level from a table itself.

 

Your new_level routine then would look something like this:

 

 

new_level:

 

;call gfxoff

 

mov r1,#level_number ; only R0 and R1 can be used as pointers to intram

inc @r1

 

mov a,@r1 ;a now contains level number

 

add a, #levelstarts & 0ffh ;add start of level starts table

call read_levelstart

mov r1, a ;store in pointer to read

 

mov r0,#004h ; pointer to sprite 1 Y pos in VDC (X pos and color follow afterwards)

mov r7, #3 ;3 bytes (Y and X pos and sprite color) to copy

call copyspriteloop

 

mov r0, #0c1h ;pointer to horizontal grid lines in VDC

mov r7, #7 ;7 bytes to copy

call copyspriteloop

 

mov r0, #0e1h ;pointer to vertical grid lines in VDC

call setshape ;sets r7 to copy 8 bytes

 

jmp reset_sub

 

Then, you need the routine to read the level data starts:

 

 

read_levelstart:

movp a, @a ;get byte

ret

 

This must be on the same page with the level start data, which looks like this:

 

 

levelstarts:

db #level_1_data & 0ffh ;start of level 1 data

db #level_2_data & 0ffh ;start of level 2 data

(and so on for each level you include)

 

Then, on the same page with your sprite data, you have your level data, which now looks as follows:

 

 

level_1_data:

db #020h ; sprite 1 Y pos

db #03bh ; sprite 1 X pos

db #col_spr_yellow ; sprite color

db #081h, #081h, #0cbh, #0efh, #0e7h, #0cbh, #089h ;horizontal grid data

db #07fh, #07eh, #03fh, #010h, #008h, #01ch, #032h, #07fh ;vertical grid data

 

level_2_data:

(data bytes for level 2 structured as above)

 

and so on...

 

Only if with all data bytes you exceed one page (which will probably happen if you need more than 13 levels), you need multiple read routines like the setshape / copyspriteloop routine, which then has to be duplicated in every page you need for level data. But still, this way you can use the majority of the data pages for actual data without the need for a ton of MOV lines.

The above didn't copy quite the way I wrote it... you'll have to indent all lines not ending on a ":" by some characters.

Disclaimer: I didn't test that code, but I'm pretty confident it should work like this.