Alexander, там в том числе и вложено то, из-за чего этот файл можно открыть через 7zip (но не распаковать). Но да, я аналогично подумал, что это какие-то данные с которыми работает движок игры, но через реверс исполняемых файлов, я не нашел то, что может ссылаться на этот файл вообще (но у меня тут прям мало знаний, наверняка там что-то есть)
Это я понял банальным сравнением количества байтов. если честно. Но мне интересно больше, что до этого всего и теперь еще, почему то, что Вы отметили может оставаться. Если воспользоваться zlib.compress в python, этих данных нет, по-крайне мере перед 78 9C
Saboteur, вряд ли поможет, но это игра Dementium The Ward, а конкретно версия для Switch, является портом с DS версии. Часть структуры отличается, часть структуры один в один, а вот шрифт другой. В оригинале было вообще 5 файлов шрифтов, здесь 1. У меня лично мнение, ничем не подкрепленное, кроме того что в финальном файле нет ничего, кроме данных цвета пикселей, что игра даже не парится. Не использует никакой шрифт, а просто проходит как по тайлмапу. Но это просто подозрение. Потому мне и хочется выяснить, что это за данные которые идут до 78 9C
Я могу сказать только то, что там, если все декомпрессировать, получится чистый raw rgba. Его дальше побайтово, можно преобразовать во что угодно, понятное дело. Покрайне мере, после декомпрессии, повторюсь, ничего кроме данных о цвете и положении нет.
Меня в данный момент больше заботит, что это за начальные байты, до компрессии и как после декомпрессии все запаковать обратно так, чтобы воспринимала игра
В итоге сейчас проблема в том, что я не могу обратно запаковать файл, чтобы игра его воспринимала. С помощью offzip смог распаковать. Там вообще, до 78 9C есть еще значения и они обрезаются. Т.к. файл два раза компрессирован изначально, я его также два раза декомпрессировал, чтобы получить raw rgb
И вот, при обратной запаковке, используя python и zlib.compress(), я получаю файл, который дальше не грузится. Забавно, что если удалить HEX значения до 78 9C в исходном файле, 7Zip его не открывает. Если добавить новому файлу, не оригинальному, эти значения, 7zip открывает. Я думал, что это мусорные значения, но у меня есть подозрения, что возможно там хранится что-то важное, в том числе и offset для разбора шрифта игрой
В любом случае, огромное спасибо за помощь. Вроде нашел в sdk через реверс-инжиниринг подходящую функцию, но тут прям не уверен. Возможно это стандартная функция для всех игр на Switch
В крайнем случае, и это конечно некрасиво, можно заменить английский шрифт на русский, а весь русский текст преобразовать в соответствующие символы, грубо говоря Привет на на русском станет BCDFG, но это прям в крайнем случае и явно некрасивый метод
Daemon23RUS, в том то и дело, что в игровых файлах, а не вижу ничего что как-нибудь бы помогло в этом вопросе. Возможно есть в исполняемых файлах, то там прям нужно углублять в реверс-инжиниринг. К тому же, это игра для Nintendo Switch (вернее порт с NDS на NSW). И тут почему-то они решили изменить структура шрифта. В оригинальной игре 5 видов шрифтов было (один из них чисто под японскую версию). Здесь же, всего 1 шрифт
Ну в целом, я глянул более внимательно, в среднем везде 15 символов и получается. Просто в некоторых случаях...выходит что один символ включает два символа.
Daemon23RUS, по факту так и есть. По факту то, что мы видим в результате, какие параметры для разбивки не задавать, никак не собрать tilemap адекватный, с равными значениями, т.к. особо и всматриваться не надо, чтобы понять что в одной строке больше символов чем в другой. Из чего я начал подозревать, что этот шрифт в игре и не используется, либо там какой-то другой способ его использования. Ну, либо я неправильно сформировал изображение (что вряд ли)
Daemon23RUS, при WxH, если W меньше 128, то программа не работает. При H выше 256, я это проверял сделав 4й байт 255, не важно какое значение 128 (за исключением, что должно быть равно или больше 128), появляется пустой пространство в документе. Т.е. если установить 256x1024, то во-первых, изображение станет как бы сжатым (и дублированным), а во вторых, внизу появится пустое пространство. Прикладываю результат при параметрах 256x1024, как демонстрация
Daemon23RUS, я же прохожусь строго по байтам. Все 4 позиции rgba, соответствует байтам последовательно. Для себя я сделал 4й байт (прозрачность) равным 255
Вернее не дублирование, а искажение. Видимо 128x256px правильные значения для высоты и ширины. Другое дело, что я дальше не представляю, как игра с этим шрифтом работает. Файл имеет приписку 12x15. Я предполагаю, что игра разбирает это изображение на меньшие (Tiles если правильно помню). Только вот при ширине 12 пикселей на один элемент шрифта, в некоторых случаях в одном тайле получается два символа или части других включая первый символ
Daemon23RUS, текущий мой код, если width != 128 или height != 256, искажает изображение. Использую Bitmap C#. Если ширина выше 128, то начинается дублирование контента. Если ниже, то обработка массива байтов выходит за пределы и выдает ошибку
