I'm back, for a short while.... at least...... I'm looking at ways to efficently store game level data.....

My Aquarius game iirc used about 190 bytes to store each level, and the grx are stored in 2x2 tiles.... so using 128 characters, and each block is 4 characters big.... so 1st tile is characters 0,1,2,3.. 2nd tile is characters 4,5,6,7... etc....This gives me 32 different tiles.... but some of the tile characters use 'similar' gfx or identical...

I'm looking to do some kind of Level Draw routine....... a bit etch a sketch style...

Notes so far below....... (uncompleted) but I'd appreciate some comments please...... its based on c64 graphics storage again (each character uses 8 bytes of memory and uses 4 colours) - 1 colour can change on the c64 but bbc can use any....

Cheers, Colin

#############

Tile compressor.....

You only get 32 Tiles of 2x2 Characters to use in the game......Made out of 127 different characters....Character 0, is blank and will NOT be plotted.... It gets ignored and 'does not clear' other gfx.....

Bit 7 of the TILE Number will be Flip GFX Vertically..... (won't work on native c64 but will do on BBC)

Bit 6 of the TILE Number will be flip GFX Horizontally..... (won't work on native c64 but will do on BBC)


Use a table of 128 bytes, to say which characters to use for each of the 32 2x2 tiles.... So we can use 'random' characters for each tile... and not multiples of 4 characters in blocks...

This saves GFX space for repeated characters used in each 2x2 Block..... so you may not need to use 128 8 byte characters (1k of C64).... you could use a lot less..... (but with an overhead of 128 bytes which equates to 16 x c64 single characters)

Bit 7 of the character will be special...... Not decided what to do with this yet - Maybe???


'''''''''''''''''''''''''''''''''''''''''''''''''

Tile Draw'er / Level Compresor.....


Each Level starts with Default Screen positiion offsets flags reset, and with default colours...


## 1st Byte is Tile position on Screen..... You get 240 2x2 Different positions, and this can be expanded... see below....


if 1st byte is 255, then screen position is reset.......( un sticks offsets)... Its default anyway...

if 1st byte is 254, then screen position is offset one char to the right.. and sticks in a flag...

if 1st byte is 253, then screen position is offset one line down.... and sticks in a flag....

if 1st byte is 252, then next byte is change colour 1

if 1st byte is 251, then next byte is change colour 2

if 1st byte is 250, then next byte is change colour 3

if 1st byte is 249, then next byte is change colour 4

This can be expanded....


## 2nd Byte is 'object' type to use..... IF NORMAL TILE

This will be 0 to 31.... You get 31 types of GFX objects to use for level design..... These may me just 2x2 or more complex !!


If 0-31.. then this is a single tile....

If bit 5.... Repeat the Graphic Tile The number of times by the 3rd byte.... eg 32-63

if Bit 6.... type = 0 ... We go Horizontal repeats , if 1 = we go Vertical .. eg 32-63 = horiz,

if bit 7.... if set.... Then ignore bits 5 and 6.... We use Special Tiles with their own rules.... we can have 128 special tiles.... but will probably use a LOT less...


If NOT NORMAL tile... then See above for Colour changes, etc.....

## 3rd Byte is 'object size' .... Used If bits 5,6,or 7 were set.... If not.... Then there is no 3rd byte used....!!!

#####################

To be continued.........

I'll be looking at 'very special' tiles... that have a start tile, a repeated middle tile, and an end tile..... But not sussed this out yet, lol !!!

To start with now..... I've ran a comparison program over the 128 graphics characters (1k - 8 x 4 x 4 colours - 2 bitplanes ) that made up 32 tiles..... Got this down to 70 individual tiles, so its come out 55% of the origonal size... However, I need a 128 byte table to make up the tiles now.... so tiles are now 'random numbers' instead of 0,1,2,3... 4,5,6,7 etc.... so I've gained a little more memory..... and lost a little less...

Program just ran through all tiles looking for matches.... then copied all the individual tiles and then ran another comparision with the origonals against the copys to work out where they all ended up.... and then generated the table...

As there are only 128 characters.... each tile of 4 chars has 4 bits spare.... I'll use these for something..... like the tiles direction for plotting repeats like up/down.... and if it uses the same tile character for repeats or something else... thats 2 bits gone now.... 2 left..... 3rd bit may be if its got collisions or not ?

While I'm redering the sceens, I'll generate a binary map for the collisions.... as looking at the screen bitmap proved hastle and the enemy sprites were colliding with each other....

Cheers, Colin

edit.... I'm going to rewrite the whole game.... and share as may of the routines and tables that I can between the c64 and BBC.... eg... the game engine code should be the same, but the gfx plotting calls will be different.... I'm considering running the c64 game in hires instead of a char map screen also now, as it will allow me more colours..... (3 bitplanes on c64 are all the same and only the 4th can be changed - on BBC , I can tailor the potter to plot any colours for the 4 colours...)

Had a little go at this tonight..... (and a couple of hours a few days ago)

Its a very early implementation yet...... If the byte is 0>31 then it just plots the tile.... and thats as far as I've got so far, lol...

Level01 .byte 00,01,02,03,04,04,04,00,01,02,03,04,04,04,$FF

Gives me this screen.......



It starts at an odd position on the screen.... Just where the Level will display once I put the borders round it, and allow 2 lines for the score and such...... Each Tile KNOWS where the next one is to plot...... eg... to the right, or below...

This is due to setting Bit 7 to 1 in the 1st byte of the tile def, if I'm going down next... (excuse the phrase, lol)

TileDefData .byte $80,$01,$02,$03 ; CHANGED 1ST BYTE TO 80, WAS 00 TO TEST
.byte $84,$04,$05,$05 ; CHANGED 1ST BYTE TO 84, WAS 04 TO TEST
.byte $06,$07,$08,$09
.byte $0a,$0b,$0c,$0d
.byte $0c,$0d,$0c,$0d
.byte $0c,$0d,$0e,$0f
.byte $10,$10,$11,$11
.byte $12,$10,$13,$11 ; tiles 0-7

I'm writing the code in modules, so it should be easy to convert to the BBC !!!

Its repeating the character plots over and over again.... and the stripes show the cpu time...... Will be slower on the bbc.... as it will be plotting hires, instead of single bytes.....

Cheers, Colin

Don't understand a word of it. But it looks pretty.

Sam.

It will look a LOT more pretty once I drop the User Defined Graphics / Characters/ Tiles in place.... instead of the stock C64 Rom Font....

At the moment its just an exercise to see how/if I can squeeze level data into a minimal amount of bytes !!

Cheers, Colin

Eventuallly it will look like this once again.... or something similar....

Your methods seem reasonable to me, To try and compress your data even more try running it through Pu Crunch once your happy with your storage format;

http://www.retrosoftware.co.uk/wiki/ind ... _Pu_Crunch

and see if there's anything more to be gained. Obviously you'll need to decompress to your format and then generate your screen from there, so some scratch pad space for the decompressed PU data will be required.

Thanks.... I'm on plan (but some of the rules have changes a little)



38 Bytes So far......

Level01 .byte 32+(19*3)+00,$1a ; pearl on left
.byte 32+(19*6)+00,$1a ; pearl on left
.byte 32+(19*3)+18,$1a ; pearl on right
.byte 32+(19*6)+18,$1a ; pearl on right

.byte $f0 ; switch to draw mode (special tiles)
.byte 32+(19*1)+5,2,7 ; row of pearls
.byte 32+(19*2)+5,0,7 ; First Platform
.byte 32+(19*2)+2,1,4 ; Column on left
.byte 32+(19*7),0,0 ; platform to left
.byte 32+(19*2)+16,1,4 ; Column on right
.byte 0,0 ; platform on right bottom ; no need for pos !!
.byte 32+(19*6)+5,1,2 ; column in mid left
.byte 2,5 ; row of pearls on bottom, no need for pos !!!
.byte 32+(19*6)+9,1,0 ; column in mid
.byte 32+(19*6)+13,1,2 ; column in mid right
.byte $ff ; end

I've now got the graphics in place..so can see that its working....

I have also re-written some of the tile draw code... It now now uses an X and Y Plot Position on the screen.. (instead of a random screen location value)....

X is 0 to 18
Y is 0 to 9

Why did I do this....

1) To make the code more portable
2) To easily allow an extra drawing mode... called MirrorX

This can be turned on and off as desired in the display list.....

When its on.... anything plotted on the screen is mirrored horizontally (and I also have a small table to sort the flipped tiles out)

Why did I do this Mirror idea ??? - Well a lot of the levels I have designed in the past are very symmetrical..... So this will save even more bytes of data for the level compression !!

Cheers, Colin

PS... Here are the Rules for the display list as they stand at the moment....

If byte = 0 to 31, then just plot the Tile or Special Tile* at the current position on screen**
if byte = 240, (F0) then use special tile defs * from Now on..........
if byte = 241, (f1) then use Normal Tile Defs from Now on..... Default !!!
if byte = 242, (f2) then set mirror x mode ON.....
if byte = 243, (f3) then set mirror x mode OFF.... (Default)
if byte = 32 > 221 then sets the screen position 0>189 (190 positions) into x and y values...
if byte is 255 (or unrecognised) then END the display list......

* SPECIAL TILE DEFS USE 2 Bytes instead of 1.... 2nd byte is the length of the middle character- In the Special Table..They each have a start tile, middle tile and end tile...
** Automatically Increases X or Y position afterwards, depending on 1st Tile Char Bit 7.

Now added another mode (F4) that will plot me repeated patterns of a user defined length......

Eg Pattern 0 = Pearl, Space, Bubble, Space, Repeat...

I call mode $f4

Do.... 0,7

and Get... Pearl, Space, Bubble,Space ,Pearl, SPace, Bubble, Stop.

This will come in VERY handy for ODD Patterns that don't fit in well with the other modes.... (or are very byte hungry !!)

Also.... the actual level data is really easy to enter straight into the assembler source, without needing to program a level editor.... You just need to know what the level looks like... (and I have most of the levels anyway) or you could knock up in paint or on graph paper very quickly !!

I've also started to cheat, and grab some bytes back for the 32 tile defs.... quite a few were spaces and were not used.... So I've copied some of the other defs into these, but made them go down instead of right.... It makes sense when you see the source code !!!

I may also have a few bytes spare, so may expand the number of tiles available to say 50 instead of 32 if required....

I will port the code and data over to the BEEB once I have a good amount of levels done as a test...... The only stuff that will need re-doing will be the co-ordinates and the plot tile code....

Cheers, Colin

Here is the c64 PLOT TILE Subroutine.... The Screen Memory Location for the TOP LEFT Corner of the Tile Position is stored in Zeropage $50 and $51 ... The code could be modified very easily to say have a X and Y Co-ordinate in $50 and $51 instead....And the code below is then re-written to plot the hi-res tile on the BEEB... and I've already done this a few months ago.... so could probably re-use !!

C64 used 40 characters per line......

PLOTTILESUB asl ; Enter this subroutine with the correct tile number in Accumulator..
asl ; Screen location must have already been calculated in 50,51 !!

tax
lda TileDefData,x
sta PLOT1STCHAR ; store 1st character for getting direction out...
AND #$7F ; GET RID OF top bit.... sO WE JUST HAVE CHAR 0-127 !!

ora #$80 ; C64 Bodge to use top 1K of characters 128>255

ldy #$00
sta ($50),y

inx
lda TileDefData,x
ora #$80
ldy #$01
sta ($50),y

inx
lda TileDefData,x
ora #$80
ldy #$28
sta ($50),y

inx
lda TileDefData,x
ora #$80
ldy #$29
sta ($50),y

Pretty Simple stuff eh ?