| |
WVL
Registered: Mar 2002
Posts: 902 |
WVL/Xenon's challenge!
A small challenge for all coders out there.
first let me explain how i got here. As most of you will know i'm working on a c64 conversion of Pinball Dreams. And as some will know, i'm rather stumbling on the 64K memory limit. So I'm always puzzling and optimizing to free up some more memory.
This morning i got an idea to optimize the way the clipmap data is stored. (what is the clipmap, you might ask? it's a black/white map that describes where the ball goes behind objects on the table).
Now this clipmap is stored as a 40*64 charscreen (RLE-ed) and a charset (lucky for me, it fitted in $a1 chars).
The idea comes to letting go of putting the chars at n*8 memory position with n integer and using pointers to point to where the data is to be fetched. The pointers will not costs any memory themselves, as for speed i'm already using a 512 table (lo/hi) with numbers times 8.
;---------------------------------------
so here's my challenge to you all!
;---------------------------------------
try to fit all $a1 chars of this charset : http://www.interstyles.nl/Charset.prg into the minimum amount of bytes you possibly can!
the answer has to be in the following form :
-a pointer table, with $a1 pointers to the positions in the chardata
-a chardata bin, as small as possible.
ofcourse all the chars still have to be made from the pointer table and the bin. All the chars have to lie COMPLETELY inside the bin, don't assume the bytes before or after the bin take on certain values.
Winner gets a beer + a hug if winner is a girl ;-)
regards,
WVL/XENON, who's anxious to win the competition himself ;-) |
|
... 38 posts hidden. Click here to view all posts....
|
| |
WVL
Registered: Mar 2002
Posts: 902 |
some quick numbers..
compressed charset : 678 bytes
pointers to chars : 322 bytes
RLE-ed screendata+pointers : 1115 bytes
makes 2115 bytes total = $843
not bad for describing a 160*512 b/w bitmap (raw data = 10240 bytes). f.e. the same file as .gif is 4867 bytes. |
| |
Hoogo
Registered: Jun 2002
Posts: 105 |
Is that gif somewhere to download? And what about the other maps?
Its really interesting :-) |
| |
WVL
Registered: Mar 2002
Posts: 902 |
http://www.interstyles.nl/CLIP.gif
it looks a bit insane bcoz of all the RLE optimizations. |
| |
Hoogo
Registered: Jun 2002
Posts: 105 |
Hm, a fast hack (I only removed duplicate lines) without puzzling and the simple counting of 0/1 gives 2.450 Bytes. I doubt that optimizations in the graphic, the puzzling and a fast dictionary compression could press that to less than 1.100 bytes... So this might only be of use if it is used for more than one map (2 maps will turn that from 0/1 to 0..3. That compresses poorer, but the 1024 Bytes pointer are only needed once). |
| |
WVL
Registered: Mar 2002
Posts: 902 |
erh.. but then you have to do RLE decoding for every byte..
I only have to do RLE-decoding for every char (saves a lot of cycles) and then i can fetch data by a simple loop. Also my data is smaller ;) |
| |
TDJ
Registered: Dec 2001
Posts: 1879 |
Quote: erh.. but then you have to do RLE decoding for every byte..
I only have to do RLE-decoding for every char (saves a lot of cycles) and then i can fetch data by a simple loop. Also my data is smaller ;)
Hmm .. normally people just brag about their 'data' being bigger ;) |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
Btw, how about enabling backwards fetching of char-gfx from the bin? This shouldn't take many more cycles if you make a dedicated routine for it. The highest bit of the address could indicate if it should be fetched backwards, so it wouldn't mean more lut-data. |
| |
WVL
Registered: Mar 2002
Posts: 902 |
cruzer : that probably wont work very well in my code, that reads from 3 chars at the same time. It's a good idea, but unfortunately a no-no :)
the loop that uses the clipdata looks like :
clipoffset
ldy #0
cliploop
spritea1 lda $1000,x
char1 and $1000,y
point1a sta spriteimage,x
spriteb1 and $1000,x
point2a sta spriteimage2,x
spritec1 and $1000,x
point3a sta spriteimage3,x
dex
spritea2 lda $1000,x
char2 and $1000,y
point1b sta spriteimage,x
spriteb2 and $1000,x
point2b sta spriteimage2,x
spritec2 and $1000,x
point3b sta spriteimage3,x
dex
spritea3 lda $1000,x
char3 and $1000,y
point1c sta spriteimage,x
spriteb3 and $1000,x
point2c sta spriteimage2,x
beq point3c
spritec3 and $1000,x
point3c sta spriteimage3,x
dex
bmi endclip
dey
bpl cliploop
lda #7
sta clipoffset+1
bne bigcliploop
endclip
char1/char2/char3 pointing to 3 different chars in the clipmap.
I was thinking of improving the search routine a bit, so it would also search in the bitmap-gfx for finding certain patterns... |
| |
Hoogo
Registered: Jun 2002
Posts: 105 |
How Do you manage the fine X/Y-movement? Usually one would place the sprite at the needed pixel-position, but the routine looks as if the block is aligned to a char and the sprite-data is hard-scrolled within the spriteblock to do the fine positioning. What a clever trick :-))) I was wondering how much shifting and buffering was needed to move the clipmap to the correct pixel-position...
I would not call the line-data RLE-encoded. The data contains nothing but a number of equal bits. Using it would have needed an outer loop for each pixel-row and in the inner a loop with adc and some logic to delete from pixel x1 to pixel x2.
|
| |
WVL
Registered: Mar 2002
Posts: 902 |
easy.
i have 8 sprite images for each color, shifted 0-7 pixels (luckily, the ball is only 15 pixels wide, so i CAN fit all the shifted images into a sprite :D)
also check how i only need a clipmap-byte once to apply it to all 3 ball-sprites (3 hires sprites, darkgrey,grey,lightgrey), saved a lot of lda's ;)
The trick is that i first apply the ANDing with the clipmap to the dark-grey sprite, which is dgrey+mgrey+lgrey colors, then i and with the mgrey+lgrey colors to get the mgrey sprites, and i and again with the lgrey colors to get the lgrey sprite...
|
| Previous - 1 | 2 | 3 | 4 | 5 - Next |
