| |
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....
|
| |
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...
|
| |
Hoogo
Registered: Jun 2002
Posts: 105 |
You spend $600 for one small ball and then you start this topic to win maybe $10 by better packing the charset?? Its sick, but I think i like this :-)
|
| |
WVL
Registered: Mar 2002
Posts: 902 |
I don't spend $600 for one small ball :-)
the sprite-images are mixed inside the bitmap-gfx! |
| |
Hoogo
Registered: Jun 2002
Posts: 105 |
You could ask a musician to perform a remix of your patterns ;-) |
| |
Optimus
Registered: Jan 2002
Posts: 122 |
>$600
For a little moment, I thought you were talking about prize money ;) |
| |
WVL
Registered: Mar 2002
Posts: 902 |
you can buy my ball for $600 ;) w8! special price for you!! only $599!! |
| |
Hoogo
Registered: Jun 2002
Posts: 105 |
...$18 Bytes still unused :-) |
| |
tfisher98
Account closed
Registered: Jan 2005
Posts: 3 |
Quote: 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...
Dumb question: do you have any free sprites, or are all 8 used in the rasters that contain the ball?
If you have a free sprite, you might be able to make your code faster and less memory hungary by using the free sprite as a mask. Use a higher priority sprite than the ball sprites, and set this mask sprite to have lower priority than the screen data and the same color as the screen background (lets assume black). The way priority works, first the sprites are checked against each other, so wherever the mask sprite contains a 1 it will win, and wherever it contains a 0 the ball sprites will win. Then this combined sprite pixel is compared to the screen; since the mask sprite is lower priority the screen data wins if there is a foreground color. Where there is a background color, the sprite pixel is displayed (either black if the pixel is masked or a ball-sprite pixel if the pixel is unmasked). The only problem with this is only 2 of 4 screen colors count as foreground priority...
But its an idea that might be worth keeping in mind. It would save you having to store shifted sprite images (so save you 7*3*64 = 1344 bytes = 5.25 pages) as well as save you having to do any AND's whatsoever. Just copy the mask byte data for the corresponding bytes to the mask sprite imagedata, with the mask sprite position restricted to be a multiple of 8... |
| |
WVL
Registered: Mar 2002
Posts: 902 |
working with priority does NOT work.
the problem is how priority between the multicolor bitmap and sprites is being handled :
%00 color of bitmap (background) -> always behind sprite
%01 color of bitmap -> always behind sprite!!!! <-- problem!
%1x color -> behind or in front of sprite, depending on priority register.
as you see, there's no way to 'hide' the ball beneath all 3 colors.
ofcourse it would work if %01 color is always the same as %00 color.
(you see, i thought about this beforehand, but it's just a no-go :), also check 2nd side of my demo Arcanum (the part with the 5 logos) for some nice priority mayhem ;), also in my demo 'World Demise' is an earlier version of that routine, using priority to fake blending of colors) |
| Previous - 1 | 2 | 3 | 4 | 5 - Next |
