Funnily enough, I think the compression format I disassembled and wrote a decompressor and recompressor for is some variant of LZSS. People must've gotten a ton of mileage out of it.

____________________
(Lv 235 with 200075605 EXP)

This one in particular was on the SNES, which I think was a while before this sort of thing? Maybe?

If this format exists elsewhere then boy howdy do I feel stupid.

____________________
(Lv 235 with 200179710 EXP)

Well, I'll be damned. But, ah...

---

Developers: Tomcat System (SNES Version)

---

Tomcat System also made Itadaki Street 2. I feel kind of silly, but hey, at least I have my own utility for it, hehe.

Their version reveals a bug with my code, though (namely that mine doesn't prevent lookbacks over 4096 bytes, which would bomb later). Oops. I'll have to fix that.




Doesn't seem to answer what the second pair bytes are, though, unless they're actually the input size and I'm just a dumb idiot. Entirely possible, mind.

____________________
(Lv 235 with 200265977 EXP)

Oh, you made that? Welp.

So that's the final (compressed) size? I never noticed, but I also didn't check much of it; I guess that makes sense.

I suppose I should make mine insert that post-compression, too.

____________________
(Lv 235 with 200286872 EXP)

Well, here's a question. Do you ever see cases in SimEarth where the compression data doesn't match the output size?

For example, when decompressing data from $766e0 in Itadaki Street 2:

---

0017FC/000A43    Decompress bit set, doing lookback decompression

0017FC/000A45      Original value: 03f9

0017FC/000A45      Lookback: 003f bytes, readPtr 17bc

0017FC/000A45      Length:   0c (12)

0017FC/000A45        Copying byte ff

0017FD/000A45        Copying byte 00

0017FE/000A45        Copying byte ff

0017FF/000A45        Copying byte 00

001800/000A45        Copying byte 00

001801/000A45        Copying byte 00

001802/000A45        Copying byte 00

001803/000A45        Copying byte 00

001804/000A45        Copying byte 00

001805/000A45        Copying byte 00

001806/000A45        Copying byte 00

001807/000A45        Copying byte 00



PHP Fatal error:  Uncaught Exception:

somehow wrote more data than expected? wrote 6152, expected 6144

in /home/xkeeper/Documents/Repo/ita2/data/decompressor.php:86

---

This happens with several offsets. Initially I thought it was my fault, but it happens fairly often, the final portion of the decompression is "00", and I'd assume that if there was something fundamentally wrong with my decompression algo that it would break everything, not result in otherwise perfect files.

It's also possible that the decompressor in-game immediately aborts if it reaches the write size; mine will continue until it finishes copying from a loopback command. I haven't looked at the disassembly today to confirm it.

____________________
(Lv 235 with 201081292 EXP)

Ah.

---

for( uint_fast16_t i = 0; i < run; i++ )

{

    output[ outptr++ ] = output[ runptr++ ];

    if( outptr >= outlength ) return outptr;

}

---

I see that your code quick-aborts if it reaches the specified size, even if it should in theory continue on.

That's what I get for not consulting your source first, I suppose.

____________________
(Lv 235 with 201094974 EXP)