Original *.PKG Resource extraction
Original *.PKG Resource extraction
Да, жаль, что твои опасения подтвердились...
Ну все равно, ты сделал отличную работу! Спасибо!
Я восстановил полностью карту, оригинал поставлявшийся в самых первых дискетных версиях игры.
Выкладываю для всех: https://www95.zippyshare.com/v/m2oV76YZ/file.html
Ну все равно, ты сделал отличную работу! Спасибо!
Я восстановил полностью карту, оригинал поставлявшийся в самых первых дискетных версиях игры.
Выкладываю для всех: https://www95.zippyshare.com/v/m2oV76YZ/file.html
Original *.PKG Resource extraction
Спасибо. И да, действительно жаль, что игра в своё время осталась без русского перевода.
Помнится, в отдельных старых проектах народ прямо английские буквы в корявые русские перерисовывал, но вечно сталкивался с проблемой того, что латинский алфавит короче русского. Но это всё проблема десятая - основная же, как и здесь, всегда была: найти, извлечь и внедрить обратно.
Помнится, в отдельных старых проектах народ прямо английские буквы в корявые русские перерисовывал, но вечно сталкивался с проблемой того, что латинский алфавит короче русского. Но это всё проблема десятая - основная же, как и здесь, всегда была: найти, извлечь и внедрить обратно.
Original *.PKG Resource extraction
Ну игра есть на Японском, Немецком, Французском.
Во вложении Японка.
Во вложении Японка.
Original *.PKG Resource extraction
Возможно, есть ещё смысл отписать на ЗоГе, хотя там народ с большего уже по современным ресурсам. Или в Бюро переводов на old-games.ru - те ребята уже не одну старую игру расковыряли.
Original *.PKG Resource extraction
Ну возможно у Malin что-то получится...
Original *.PKG Resource extraction
Magiczoom писал(а):Ну возможно у Malin что-то получится...
Эт вряд ли.
Глянул японский файл. В нём есть всё тот же английский текст. Японского текста в японской кодировке Shift-JIS я не углядел. Думаю японский текст, если он есть в японской версии игры, закодирован как-то по-другому. Однако нашёл забавные вставки такого вида
По итогу мыслей, как определить секцию шрифтов в файлах игры, в голову мне не пришло.
Original *.PKG Resource extraction
Я хотел бы для истории немного, так сказать, "приподнять ковёр" и показать подноготную происходившего в этой теме.
Когда PKG файлы удалось разбить на отдельные файлы, я пытался определить что есть что. Что есть изображение, что звуки, а что текст. Если для поиска текста достаточно блокнота, то вот для поиска изображений нужно что-то другое. И я написал небольшую программку, которая читает файл и пытается превратить его в изображение.
Поясню на всякий случай, что любой файл - это последовательность байт, и когда нам говорят что файл весит, скажем, 1024 байта это значит что где-то там в компьютере выстроились друг за другом ровно в ряд 1024 числа-байта. Но если нам говорят что эти 1024 байта представляют из себя некое изображение, то возникает вопрос:"А как же вот эту дружную колонну байтов превратить в двухмерное изображение?" Для пытливого читателя, ответ конечно же очевиден - изображение состоит из какого-то количества рядов и надо лишь разделить общее количество байт файла на длину одного ряда (ширину изображения), чтобы получить количество этих рядов (высоту изображения). Также стоит отметить, что многие изображения содержат внутри себя три или даже четыре байта на цвет одно пикселя, поэтому чтобы построить изображение байты файла возможно надо сначала объединить в трёх (или четырёх) байтные числа.
И вот, ведомый этими мыслями, я написал небольшую программу, которая может представить любой файл в виде картинки по заданным параметрам ширины и высоты изображения, которое хочется получить. Конечно вывести на экран весь файл целиком как изображение не получится, если он очень большой. Поэтому программа берёт только некоторый кусок файла.
Вот так например выглядит начало exe-шного файл игры:
Пестрящий хаос цветов, кажущееся отсутствие какого-либо порядка - это явный признак каких-то "машинных данных", не изображений, не текста, не звука.
Однако важную роль играет правильный выбор ширины изображения, ведь порядок наступает только в небольшом количестве случаев при выборе ширины и нарушается довольно легко. Тем не менее изображения даже с неверной шириной выглядят совершенно иначе и не сложно понять что здесь что-то есть.
Вот так выглядит начало одного из PKG файлов в трёхбайтных цветах при изменении желаемой ширины изображения:
И вот, прямо на глазах, из бурлящего хаоса раскрашенных байт вырисовывается таинственное изображение, а вы словно археолог радуетесь своей находке! И даже наличие всяких "мусорных метаданных" в начале изображения не сильно омрачает, а лишь придаёт таинственности - ведь они зачем-то были нужны, раз уж их туда вставили.
Однако изображение выше построено по объединению трёх байт в один цвет, чего делать не нужно, поэтому-то оно даже в лучшем своём виде косое. Отбросим данное правило и будем раскрашивать в цвет каждый байт, и, для разнообразия, поглядим нашим программным оком на некоторый кусок PKG файла где-то в его середине, так сказать сместимся от его начала в глубь и дебри:
Тут всё совсем хорошо - чётко отрисованный домик, в неверных цветах, да, но это лишь потому что мы не знаем нужной палитры... Да разве что со смещением мы не сильно попали (слева часть того же изображения, которая должна быть справа).
В общем оказалось весьма любопытно визуализировать какой-либо файл в виде картинки.
Когда PKG файлы удалось разбить на отдельные файлы, я пытался определить что есть что. Что есть изображение, что звуки, а что текст. Если для поиска текста достаточно блокнота, то вот для поиска изображений нужно что-то другое. И я написал небольшую программку, которая читает файл и пытается превратить его в изображение.
Поясню на всякий случай, что любой файл - это последовательность байт, и когда нам говорят что файл весит, скажем, 1024 байта это значит что где-то там в компьютере выстроились друг за другом ровно в ряд 1024 числа-байта. Но если нам говорят что эти 1024 байта представляют из себя некое изображение, то возникает вопрос:"А как же вот эту дружную колонну байтов превратить в двухмерное изображение?" Для пытливого читателя, ответ конечно же очевиден - изображение состоит из какого-то количества рядов и надо лишь разделить общее количество байт файла на длину одного ряда (ширину изображения), чтобы получить количество этих рядов (высоту изображения). Также стоит отметить, что многие изображения содержат внутри себя три или даже четыре байта на цвет одно пикселя, поэтому чтобы построить изображение байты файла возможно надо сначала объединить в трёх (или четырёх) байтные числа.
И вот, ведомый этими мыслями, я написал небольшую программу, которая может представить любой файл в виде картинки по заданным параметрам ширины и высоты изображения, которое хочется получить. Конечно вывести на экран весь файл целиком как изображение не получится, если он очень большой. Поэтому программа берёт только некоторый кусок файла.
Вот так например выглядит начало exe-шного файл игры:
Пестрящий хаос цветов, кажущееся отсутствие какого-либо порядка - это явный признак каких-то "машинных данных", не изображений, не текста, не звука.
Однако важную роль играет правильный выбор ширины изображения, ведь порядок наступает только в небольшом количестве случаев при выборе ширины и нарушается довольно легко. Тем не менее изображения даже с неверной шириной выглядят совершенно иначе и не сложно понять что здесь что-то есть.
Вот так выглядит начало одного из PKG файлов в трёхбайтных цветах при изменении желаемой ширины изображения:
И вот, прямо на глазах, из бурлящего хаоса раскрашенных байт вырисовывается таинственное изображение, а вы словно археолог радуетесь своей находке! И даже наличие всяких "мусорных метаданных" в начале изображения не сильно омрачает, а лишь придаёт таинственности - ведь они зачем-то были нужны, раз уж их туда вставили.
Однако изображение выше построено по объединению трёх байт в один цвет, чего делать не нужно, поэтому-то оно даже в лучшем своём виде косое. Отбросим данное правило и будем раскрашивать в цвет каждый байт, и, для разнообразия, поглядим нашим программным оком на некоторый кусок PKG файла где-то в его середине, так сказать сместимся от его начала в глубь и дебри:
Тут всё совсем хорошо - чётко отрисованный домик, в неверных цветах, да, но это лишь потому что мы не знаем нужной палитры... Да разве что со смещением мы не сильно попали (слева часть того же изображения, которая должна быть справа).
В общем оказалось весьма любопытно визуализировать какой-либо файл в виде картинки.
Original *.PKG Resource extraction
Malin рад, что эксперименты тебе принесли удовольствие.
Не понимаю зачем разработчик TFB так извращался с созданием игры.
Это прям их фишка (фирменный почерк).
Кстати, было выяснено что в 9 кусках карты одна и та же палитра. А ты не проверял подходит ли она к другим изображениям?
Т.Е. может палитра для всех изображений заранее статично определена...
Ну, а поводу шрифта, ну нет, так нет. (Желание и попытки были, а впереди стена, не убиться же об нее).
Не понимаю зачем разработчик TFB так извращался с созданием игры.
Это прям их фишка (фирменный почерк).
Кстати, было выяснено что в 9 кусках карты одна и та же палитра. А ты не проверял подходит ли она к другим изображениям?
Т.Е. может палитра для всех изображений заранее статично определена...
Ну, а поводу шрифта, ну нет, так нет. (Желание и попытки были, а впереди стена, не убиться же об нее).
Original *.PKG Resource extraction
Magiczoom писал(а):Кстати, было выяснено что в 9 кусках карты одна и та же палитра. А ты не проверял подходит ли она к другим изображениям?
Проверял, не подходит.
Original *.PKG Resource extraction
Malin, а PKG чисто контейнер ресурсов (картинки, звуки, текст) или там и исполняемые коды есть?