nesdev.org

Congrats stef for this improvement, i am between 13 and up to 17 kb per frame on thE hu6280, this of course with the classic LZ4. it's not optimised to it's max, but i think i can't go higher . Espozo: LZ4 can be assimilated to a simple bytes copy,it depends of how fast you can transfert bytes and y...

I know, but if you don't want to waste ROM/VRAM like that, you have no choice .
Also the fact you are out of VRAM bandwidth, you must use a double buffer and eat more VRAM,IMO is not really efficient, even if it simplify your metasprite datas .

It's strange to wasting that amount of VRAM(i know it's in ROM, but i think you load all that frame chunks in VRAM ) with 8x8 tiles .

I suppose it's for DMAing always the same amount of datas for each animation's frame ??,or simplify the metasprite datas ??

I played around with forming Final Fight sprites into blocks, and found the biggest sprites can fit within a 2kB slot. So VRAM-wise it can do 6 enemies, and have 4kB left for items. Of course with 16kB you can go with 8 128x128 sprites, it's more than enough,the only problem with snes is you cannot...

Stef wrote:Yeah of course it won't compress as much but i believe it could be not that bad and the speed improvement can be really high

Of course the decompression speed should be very high,but i really think that compression ratio will suffer a lot .
Wait and see .

What a shame there is no word aligned optimized LZW packers so we could properly take advantage of the 68000 word/dword transfer.

Because it should be worse for compression ratio .

It maybe has a good compression ratio, but it seems very slow too . I think really you can find some modern algo that doing the job way better,like pucrunch, exomiser,LZMPi,and many others . You can find in nemessis link this : While the Nemesis format was limited to only 3 tiles of decompressed dat...

I really want to provide the source code for the compressor so any people can compile tools for its platform (linux / osx) :) I downloaded sources but got some troubles when i tried to compile them from my mingw GCC. Ah, it be complicated then,but i understand your point ( here :mrgreen: ). That is...

I think there is no magic solution, it depend what you need, speed or ratio ,but speed and ratio at same time is a chimera .. Now, there are some very good compressor ,better by far than those in 80/90's,to find a good compromise or well suited for a particular project . Thanks Touko :) I actually e...

If I'm doing a compression heavy game, I'd probably use an SA-1. You have the LZ4 compression, here the link with his 65816 implementation : http://www.brutaldeluxe.fr/products/crossdevtools/lz4/ It's a realtime oriented decompressor,this means very fast decompression with good compression ratio(bu...

I am also confused by this? Why does it have 11 bits if the PCE can't use 8x8 sprites? Like tepples said, it intended to use 128ko of VRAM .. And those 11bits are not the same for sprite cells size, those are in another word (the fourth),it's 11 bits for sprite patterns addresses in VRAM only. @esp...

You mean it goes by 8x8, although the minimum sprite size is 16x16?

11 bits for sprite patterns, a complete sprite attributes is 4 words, 1st word for Y position,2nd for X position, 3rd for pattern, and 4th for size,flip, palette .
On the 3rd, 11 bits is used .

Yeah, I meant, like how the minimum sprite size is 16x16, so I said 16x16 tiles. Ah ok sorry espozo :wink: I'm pretty sure the Turbografx 16 has 9 bits for selecting tiles No, it has 11 bits :) it's just that it's going by 16x16 instead of 8x8 Yes :( ,and you lose some sprite bandwidth when only 8x...

They should have made tiles for sprites 16x16 like the Turbografx so sprites could occupy all of vram. The PCE have more size than 16x16, you can have 16x32,16x64,32x16,32x32,32x64 and you can have all that sprites size in your frame at same time,but unfortunately no tiles under 16 pixels . :? SNES...

It seems the TurboGrafx is a bit unbalanced in design, like having a 7+mhz 6502 variant but with only 8KB of ram. This is because the PCE has no restricted acces to VRAM, you can decompress or modify SAT/BAT directly in vram, without any RAM buffer . In fact is less problematic than it seems,but it...