| |
WVL
Registered: Mar 2002
Posts: 886 |
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....
|
| |
Monte Carlos
Registered: Jun 2004
Posts: 351 |
Whats about packing the clipmap into 8x7 pixel wide chars?
The Sprites are 24x21, so they would be exactly 3x3 chars wide. Would be perhaps much easier, than dealing with 3x(2x5/8) wide chars. ;)
The bitmap could be 406 pixel high, instead of 400, do it would fit exactly, too(40x58 chars).
Montecarlos
|
| |
WVL
Registered: Mar 2002
Posts: 886 |
I dont see how that would make things much easier? it wouldnt save any memory, but would become a bit harder to determine in what charline you are (dividing by 7 is a lot harder than dividing by 8) |
| |
doynax
Account closed
Registered: Oct 2004
Posts: 212 |
Any chance you could search the ROM charset for matching strings too? Shouldn't be much of a problem since you're already storing raw pointers anyway.
It's any ugly hack and probably won't save more than a few chars but I guess it's worth a try. |
| |
Monte Carlos
Registered: Jun 2004
Posts: 351 |
It was just a thought, which
i meant was worth to consider. ;)
And perhaps it is not too hard to calculate
the current charline, because if the ball movement
is max. about 16 lines per frame(which is quite fast), then
there are only 4 (2 back and 2 forward) charlines possible for the new ball position.
Monte
|
| |
tfisher98
Account closed
Registered: Jan 2005
Posts: 3 |
WVL wrote:
-------------------------
%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.
--------------------------
Yes there is a problem, but not quite exactly the way you wrote. The method I suggested, with an extra mask sprite, has
%00 color -> appears to be behind or in front of sprite, depending on priority register
%01 color -> can't be brought in front of sprite; if you set priority here you get %00 color <-- problem!!!!
%1x color -> behind or in front of sprite, depending on
priority register.
So three colors can be brought in front of the sprite; the fourth (%01) color cannot.
Anyway, it was just an idea. It's cool to see a new game under development, and I'm glad you're sharing the process with us.
Best of luck...
--T |
| |
tfisher98
Account closed
Registered: Jan 2005
Posts: 3 |
With a couple more minutes of thought, it seems maybe I wasn't clear in my original suggestion. The ball sprites would ALWAYS have their priority bit in $d01b clear so they have priority over the bitmap. The mask sprite will be used to pull certain pixels of the ball sprites underneath the foreground %1x color pixels, and to hide others by mask (= background) color pixels.
Anyway, still probably not what you want.
--T |
| |
WVL
Registered: Mar 2002
Posts: 886 |
it doesnt work, you cannot 'pull' the mask behind the %01 pixels and the %00 pixels. Ofcourse you can make it invisible, by letting the mask sprite take on the %00 color, but then there's always the %01 color the mask does not go behind...
-> wherever the mask sprite has bit 1, you will see color %00 (really the color of the sprite) where the %01 color should be seen. |
| |
Hoogo
Registered: Jun 2002
Posts: 102 |
What about packing char-columns instead of char-rows? |
| |
WVL
Registered: Mar 2002
Posts: 886 |
i think packing columns instead of rows would :
-reduce bytes needed for pointers
but
-make RLE compression of charscreen worse
you see, since the pinball table is made up from mostly vertical lines, there are a lot of equal horizontal rows. But i'm guessing there would hardly be any equal vertical columns -> compression goes down a lot...
also reading the last byte from columns (64 chars) would take longer than reading from rows (40 chars), since you have to RLE decompress on the fly...
-> i'm not sure it's worth trying.. (or rather, i'm 99% sure things would be a bit worse) |
| |
Hoogo
Registered: Jun 2002
Posts: 102 |
It might take more time to decode till Char64, but when looking at the gif I find that the bottom of the picture would compress best in rows, but the upper part would compress better in columns. I'd say its worth a try. Maybe it's also possible to split and do both (increases the code..) ? |
| Previous - 1 | 2 | 3 | 4 | 5 - Next |
