Quote:
If we talk about decompression, in Miniplanets I'm just streaming rafts and conveyor belts because I'm too lazy to make a software scrolling routine for them, but I also don't want them to eat up too much ROM space so I keep them compressed... meaning the game has to decompress the graphics on the fly.* Same deal with the player, because the player has a rather significant amount of sprites (remember it has to have every sprite three times due to the different angles). I think the worst case in the game is 40 tiles per frame i.e. 1.25KB (while doing everything else, mind you - the globe eats up its good chunk of CPU time despite using look-up tables).
I took sonic for his fast scrolling, i knew your game and i like it, read also you did eavy decompression on the fly is very amazing .
The concept is very intersting and fresh, changing of all classics style .
Quote:
Normally I'd say the SNES should be able to do the same, but the algorithm I'm using has been specifically adapted to the 68000's strengths (and packed format), I have no idea how good one can make an algorithm adapted to the 65816.
It depend how you treat your datas, if all was designed for 32bits processing, the 65816 could not compete i think .
For exemple lz4 is designed for 8/16 bits values, and works very well on 65816 .
EDIT:Oh uftc use 16bits datas with dictionaries, lz4 on a 2.5 mhz 65816 decompress at 210 KB/s, with a 348,7 KB/s at max .
With packed pixels Md's 68k could be better .