Faster compression & Imperial Camp boxes

Nice catch. I didn't know stepping on those boxes caused a soft lock. Actually, I never even knew you could get to that Barrier Ring chest. I think the coordinates you listed might be reversed though? It looks like you have them listed as (y,x) instead of (x,y).

Thanks. I must have accidentally switched them while posting.

Well unless I've mistaken, there's no way to ever get the chance to step on those particular boxes though, even by way of going to the secret Barrier Ring chest... so I'm a bit baffled how it could happen.

Yes, you are correct. The bug should not be encountered in a vanilla playthrough. I only posted the Imperial Camp fix for context and in case anyone else wanted to open that map up for exploration.

However, the main reason for posting was to share my compression algorithm rather than the Imperial Camp fix.
Unless an error in my algorithm or testing is found (or someone would like to share a better approach), I believe my method using two additional hash maps can speed up compression in every existing tool and project by an order of magnitude. This potentially also applies to tools and projects for other games using Square's LZSS compression such as Chrono Trigger and FFV (does FFIV use this anywhere?).

I am not very familiar with C#, but I quickly converted the code from FF6LE I found in the source on the wiki to python for the purposes of another benchmark. Attached is the converted code if anyone is interested in checking if the translation can be improved for the benchmark.

I ran the 3 rom start compression tests:
20k compressed in 5.173 seconds by FF6LE compared to my 0.126 seconds
50k compressed in 12.900 seconds by FF6LE compared to my 0.333 seconds
65535 compressed in 18.093 seconds by FF6LE compared to my 0.536 seconds
The resulting compressed file sizes all matched my script exactly and decompressed correctly.

I also believe I discovered a bug in FF6LE while benchmarking. This line in LCDecomp.cs:

Code:

                   while ((run < 31 + 3) &&
                       (buf[bpos - (ulong)x + run] == buf[bpos + run]) &&
                       (bpos + run < fsize))
                   {

Should have the bpos + run < fsize check come before the buf array access to prevent out of bounds access (this occurred during the 50k test):

Code:

while ((run < 31 + 3) &&
   (bpos + run < fsize) &&
   (buf[bpos - (ulong)x + run] == buf[bpos + run]))
{