Не, мой лучше жмёт в некоторых случаях.) Тут сжатый тремя разными компрессорами *.bmp скриншот.
Одинаково с моим, я же написал: "Только я указал размер окна 0xFFE в LZSS.c (оставлял на всякий случай), если изменить на #define WINDOW_SIZE_8 0xFFF, то будет также сжимать, сейчас чуть хуже в редких случаях". Это касается и вашего теста. Сейчас адаптировал мой старый медленный алгоритм, но с хорошим сжатием (вроде не предел), получилось 533 448 байт против 535 034 от ViT, что-то недожал. Позже выложу обновлённое сжатие, если доделаю, скорее всего в другой теме, много оффтопа. Я знаю что можно найти макс. сжатие, но хочется самому подумать.
О скорости в курсе, это из-за того что вывод прогресса не оптимизирован. Так как игровые файлы небольшие, это не критично.
Я говорил об ускорении алгоритма сжатия, есть быстрый и медленный, я думал у вас медленный (без исходника не ясно), но оказалось у меня оба работают неразличимо быстро на небольших данных. Разница, например, с быстрым - 600МБ за 25 секунд, а с обычным перестал ждать на 5 минутах. Это важно, когда сжимаешь много файлов сразу. Ваш можно ускорить в 2 раза, если убрать вывод, добавив на конце > nul 2>&1, но видимо вызов функции вывода долгий всё равно.
Из забавно, можно немного улучшить сжатие, если не сжимать последовательность из 2 байт, сжимает только на 1 бит и чаще мешает. У меня для этого поменять константу на #define MIN_SEQ_8 3.