|
Post by spenoza on Aug 19, 2022 17:15:32 GMT
Has anyone tried writing a Rob Northen decompression routine for PC Engine? I know it was used on the Genesis. Is it an algorithm that would be at all useful on the PC Engine and would the Hu6280 be at all capable of effectively running the necessary functions at any kind of speed?
|
|
|
Post by dshadoff on Aug 19, 2022 17:26:15 GMT
What's so special about that compression that isn't already covered by various other techniques ? I know elmer has worked with several...
|
|
|
Post by spenoza on Aug 19, 2022 17:47:18 GMT
It has an average 3 to 1 compression ration for graphics data and was used extensively by US and UK devs during the end of the Mega Drive's life and early in the Saturn and PS1 era.
|
|
|
Post by dshadoff on Aug 19, 2022 17:52:26 GMT
OK, but I wouldn't make assumptions about the compressibility of PC Engine graphics data as compared to other systems' data. Is it documented somewhere ? Note: here is a related thread with other compression methods: pcengine.proboards.com/thread/958/more-compression
|
|
|
Post by audreyhepburn on Aug 19, 2022 22:17:39 GMT
OK, but I wouldn't make assumptions about the compressibility of PC Engine graphics data as compared to other systems' data. Is it documented somewhere ? Note: here is a related thread with other compression methods: pcengine.proboards.com/thread/958/more-compressionWhoa, I've actually never seen that thread before, thanks!
|
|
|
Post by turboxray on Aug 19, 2022 23:28:32 GMT
It has an average 3 to 1 compression ration for graphics data and was used extensively by US and UK devs during the end of the Mega Drive's life and early in the Saturn and PS1 era. Don't believe everything you read on Segaretro. That site is full of horribly inaccurate specs/claims/etc. The scheme is just LZSS with huffman applied for the control codes. Genesis/PS1/Saturn used linear/packed-pixel format which compresses better with those schemes. Doesn't do as well on planar formats (SNES/PCE/etc) - but it still works. There are other similar compressions schemes like RNC which take the same idea/approach (and PuCrunch is one of them).
|
|
|
Post by elmer on Aug 19, 2022 23:40:42 GMT
It has an average 3 to 1 compression ration for graphics data and was used extensively by US and UK devs during the end of the Mega Drive's life and early in the Saturn and PS1 era. Don't believe the marketing-claims! Anyway, I'd not seen it before, and it's really nice to hear what Rob Northen did after his tape and disc copy-protection business started to dry up. Compression was still a bit of a black-art back in 1991, so there was definitely some money to be made by selling a decent compressor to professional devs. Having said which, as turboxray just said, there nothing particularly special about Rob's method by modern standards, and it really doesn't hold up to other compressors. Also, as turboxray just said, transforming the PCE's planar pixels into chunky pixels will help RNC ... but it'll help everything else too, and the results will be similar. **********************************************************
40,164 popcore.bin (uncompressed)
28,612 popcore.bin.lzss16 (4KByte window buffer) 28,227 popcore.bin.lz4
26,345 popcore.bin.lzsa1
25,134 popcore.bin.rnc2 25,029 popcore.bin.pucrunch (2KByte window buffer)
24,366 popcore.bin.pucrunch 24,012 popcore.bin.rnc1
23,958 popcore.bin.aplib (2KByte window buffer) 23,929 popcore.bin.lzsa2 23,012 popcore.bin.deflate
22,926 popcore.bin.aplib 22,646 popcore.bin.zx0
********************************************************** While those results might look OK, here are the results when testing with some actual PC Engine graphics from LoX2 (nowhere NEAR 3:1 compression!) ... **********************************************************
13,088 lox2_lvl2_chr.bin (uncompressed)
10,788 lox2_lvl2_chr.lzss16 (4KByte window buffer) 10,571 lox2_lvl2_chr.lz4 10,146 lox2_lvl2_chr.lzsa1
9,926 lox2_lvl2_chr.rnc2 9,737 lox2_lvl2_chr.pucrunch(2KByte window buffer) 9,526 lox2_lvl2_chr.rnc1 9,407 lox2_lvl2_chr.lzsa2
8,976 lox2_lvl2_chr.zx0
**********************************************************
|
|
|
Post by elmer on Aug 20, 2022 0:23:32 GMT
Whoa, I've actually never seen that thread before, thanks! FWIW, the latest versions of the LZSA1, LZSA2 and ZX0 decompressors are kept in the HuC distribution these days, together with my other assembly-language libraries.
|
|
|
Post by spenoza on Aug 20, 2022 12:52:23 GMT
Don't believe everything you read on Segaretro. That site is full of horribly inaccurate specs/claims/etc. I didn’t read it at Segaretro. Burton of Traveller’s Tales has talked it up and so did one of the devs of the Saturn port of NBA Jam TE. I’m just wondering if it can be used effectively on the PCE in a manner similar to how it was on other systems. That’s all. No need to get your undies in a twist.
|
|
|
Post by elmer on Aug 20, 2022 13:43:31 GMT
I’m just wondering if it can be used effectively on the PCE in a manner similar to how it was on other systems. Sure, it's a lovely compressor for the 90s, definitely better (in terms of compression) to what I was using at the time, and far, far better than the pure-LZSS16 that Hudson was still using in their final PCE games. But the thing that makes RNC1 good, which is the added dynamic Huffman step, rather than using a static Huffman-derived step as he did in RNC2 and everyone else in Europe was doing at the time, is that the dynamic Huffman trees add a significant chunk of processing time to the decompression, and use a bunch of extra memory to store the trees. We're certainly capable of running that decompression on a PCE, but why would we when there are better compressors out there these days that don't require either the extra processing time or memory?
|
|
|
Post by spenoza on Aug 20, 2022 13:51:42 GMT
We're certainly capable of running that decompression on a PCE, but why would we when there are better compressors out there these days that don't require either the extra processing time or memory? I think that addresses my query quite thoroughly (and snark-free, to boot!) I was inquiring because some professional sources of the time talked it up and was curious to know if this was an overlooked opportunity or an artifact of the time. I does seem that using RN compression did require specific image processing steps to see optimal compression ratios (stretching the image vertically prior to compressing - Burton’s video on this is sufficiently detailed). Where all this SegaRetro defensiveness is coming from I have no idea. Can we please not assume the worst of people for a moment?
|
|
|
Post by dshadoff on Aug 20, 2022 15:22:26 GMT
One thing to remember in discussions like this, is that compression is something that s highly dependent on the nature of the data being compressed.
Another thing - especially when reading historical writings of that period (say, 1983 to 1999) - is that everybody had a favorite technique or mechanism, especially if it had written by themselves... but objective comparisons were exceedingly uncommon, so there was a lot of bluster but truth (or proof) was rare (and sometimes the bluster was actually true anyway). This is because it was sometimes difficult/costly to actually obtain the various tools to compare against each other, and the comparisons themselves were costly and time-consuming to plan and to run. Comparisons have become much easier and less costly to run over the years, but they are still unfortunately somewhat uncommon.
|
|
|
Post by turboxray on Aug 20, 2022 16:34:57 GMT
No need to get your undies in a twist. The irony of this statement hahaha
|
|
|
Post by spenoza on Aug 21, 2022 12:39:27 GMT
No need to get your undies in a twist. The irony of this statement hahaha You have a history of rude/blunt comments which could maybe be sat on for a bit before posting. Maybe think about the person reading your comment for more than a microsecond, mm?
|
|
|
Post by DarkKobold on Aug 21, 2022 17:14:16 GMT
Whoa, I've actually never seen that thread before, thanks! FWIW, the latest versions of the LZSA1, LZSA2 and ZX0 decompressors are kept in the HuC distribution these days, together with my other assembly-language libraries. Is there functionality to extract the data directly into VRAM? EDITlooking at github.com/jbrandwood/huc/blob/master/examples/asm/elmer/include/unpack-zx0.asmLooks like the routine exists, but what doesn't exist is my understanding/ability to use this in HuC.
|
|