DCT - это не алгоритм сжатия. Дискретное косинусное преобразование (DCT) - это один из способов представления данных (с потерями) в более сжимаемом виде, поверх него всё равно используются финальные кодеки типа арифметического кодирования или алгоритма Хаффмана.
Реализуем простой алгоритм сжатия Run-Length Encoding.
Это не каноничная реализация алгоритма. Я опущу тот факт, что не представлен декодер. Опущу тот факт что данные форматируются в строку, т.е. число символов может отформатироваться как 1 так и 111 (3 символа) что усложняет разработку декодера. Опущу тот факт, что сначала нужно писать количество, а потом уже сам символ, а не наоборот как здесь, Но сама реализация в худшем случае увеличит исходные данные в 2 раза, в 50% размер или останется таким же или уменьшится незначительно. И только в идеальных условиях данные будут сжаты, опять же с оговорками выше. Про каноничный алгоритм можно почитать к примеру тут https://ru.wikipedia.org/wiki/Кодирование_длин_серий
Ссылки на сами проекты не приведены, что большой минус. Но есть примеры использования, за что спасибо.
В старых играх текстура шрифта представляет собой DDS-текстуру с сеткой 16x16 (по сути вся таблица ASCII), где каждый байт соответствует своему индексу на текстуре.
В новых играх текстуры могут быть больше. Либо вообще свои текстуры под конкретный алфавит, как это в MGRR (там вообще всё очень страшно по структуре)
Часто вместе с текстурой идёт символьная таблица с указанием кода символа и его положением на текстуре:
struct {
wchat_t code;
int32_t left;
int32_t top;
int32_t width;
int32_t height;
// доп. данные типа кернинга и т.д.
} symbol;
Обычно применяются прямые координаты, реже полярные (опять же MGRR).
Просто в hex-редакторе менять строки неправильно. Тем более, что русский текст обычно представляется в UTF-8 кодировке, а там уже другое количество байт на символ.
Зачастую текст игры представлен в виде некоторого бинарного текстового файла, состоящего их массива элементов. Типа такого
struct {
int32_t len; // может быть int8_t либо int16_t, в зависимости от макс. длины строк трок
char text[len + 1]; // в конце терминирующий \0
} text_node;
И перевод нужно делать десериализуя текст в обычный текстовый файл, и потом обратно сериализуя его. Новые игры обычно поддерживают возможность локализации по умолчанию. В старых играх приходится подменять одну из существующих локализаций.
Иногда текст хранится в json или xml. Тогда переводить проще, но всё равно необходимо писать парсер, чтобы вытащить только текст, без прочей шелухи, и затем обратно его вставить.
Редко, когда текст зашит в exe файл, тогда там приходится применять разные хаки для перевода, и это намного более трудоемкий процесс, и в играх с защитой он практически невозможен.
И в общем-то, чтобы это всё расписать не хватит 10 статей. Есть много различных движков, и в каждом своя система локализации.
И, к сожалению, в статье не приведены ни примеры реверс-инжиниринга алгоритмов, ни та структура архивов LFS, ни формат текста, и особенности представления данных на разных платформах.
Насчет GameCube/Wii предполагаю, что там какая-то вариация алгоритма LZMA. LZX, LZO, zlib не дадут нужной степени сжатия, а больше на тот момент и не было ассиметричных алгоритмов с высокой степенью сжатия. Но я могу и ошибаться
DCT - это не алгоритм сжатия. Дискретное косинусное преобразование (DCT) - это один из способов представления данных (с потерями) в более сжимаемом виде, поверх него всё равно используются финальные кодеки типа арифметического кодирования или алгоритма Хаффмана.
Brotli - это разработка Google. https://github.com/google/brotli. Dropbox просто портировали его на rust
Это не каноничная реализация алгоритма. Я опущу тот факт, что не представлен декодер. Опущу тот факт что данные форматируются в строку, т.е. число символов может отформатироваться как 1 так и 111 (3 символа) что усложняет разработку декодера. Опущу тот факт, что сначала нужно писать количество, а потом уже сам символ, а не наоборот как здесь, Но сама реализация в худшем случае увеличит исходные данные в 2 раза, в 50% размер или останется таким же или уменьшится незначительно. И только в идеальных условиях данные будут сжаты, опять же с оговорками выше. Про каноничный алгоритм можно почитать к примеру тут https://ru.wikipedia.org/wiki/Кодирование_длин_серий
Ссылки на сами проекты не приведены, что большой минус. Но есть примеры использования, за что спасибо.
В общем за старания 5, за подачу информации 2
В старых играх текстура шрифта представляет собой DDS-текстуру с сеткой 16x16 (по сути вся таблица ASCII), где каждый байт соответствует своему индексу на текстуре.
В новых играх текстуры могут быть больше. Либо вообще свои текстуры под конкретный алфавит, как это в MGRR (там вообще всё очень страшно по структуре)
Часто вместе с текстурой идёт символьная таблица с указанием кода символа и его положением на текстуре:
Обычно применяются прямые координаты, реже полярные (опять же MGRR).
Всё зависит от конкретного движка и игры
Просто в hex-редакторе менять строки неправильно. Тем более, что русский текст обычно представляется в UTF-8 кодировке, а там уже другое количество байт на символ.
Зачастую текст игры представлен в виде некоторого бинарного текстового файла, состоящего их массива элементов. Типа такого
И перевод нужно делать десериализуя текст в обычный текстовый файл, и потом обратно сериализуя его. Новые игры обычно поддерживают возможность локализации по умолчанию. В старых играх приходится подменять одну из существующих локализаций.
Иногда текст хранится в json или xml. Тогда переводить проще, но всё равно необходимо писать парсер, чтобы вытащить только текст, без прочей шелухи, и затем обратно его вставить.
Редко, когда текст зашит в exe файл, тогда там приходится применять разные хаки для перевода, и это намного более трудоемкий процесс, и в играх с защитой он практически невозможен.
И в общем-то, чтобы это всё расписать не хватит 10 статей. Есть много различных движков, и в каждом своя система локализации.
И, к сожалению, в статье не приведены ни примеры реверс-инжиниринга алгоритмов, ни та структура архивов LFS, ни формат текста, и особенности представления данных на разных платформах.
Насчет GameCube/Wii предполагаю, что там какая-то вариация алгоритма LZMA. LZX, LZO, zlib не дадут нужной степени сжатия, а больше на тот момент и не было ассиметричных алгоритмов с высокой степенью сжатия. Но я могу и ошибаться