Перейти к содержимому
Zone of Games Forum

Рекомендованные сообщения

продвинули же фотоаппарат который сохраняет не просто картинку

а характеристику всех лучей, который попали в объектив,

и можно изменять фокус прямо на фотографии уже и

100% идентичность снимков реальности

Ни фига не продвинули. Не вижу я что бы этот фотик продавался в каждом магазине за 100-1000 баксов. Есть технология, есть рабочие прототипы в продаже, но массовости нету. Подобных прототипных инноваций выше крыши, только их не продвигают в массы из-за того, что есть богатые конкуренты которые не дают себя потеснить.

Хочу игры с интерактивностью майнкрафта, но при этом с вменяемой графикой, физикой и геймлеем ^___^ Рушить дома в скайриме мастер спеллами - круто же.

Это все возможно на современных консолях, просто это геморно создавать, связываться ни кто не хочет.

Поделиться сообщением


Ссылка на сообщение

Когда нет ограничения движка или загнанности в рамки аппаратных мощностей,создавать проще.Я думаю то,что описал Лямур,будет воплощено на 8-ом поколении.

Поделиться сообщением


Ссылка на сообщение
Когда нет ограничения движка или загнанности в рамки аппаратных мощностей,создавать проще.Я думаю то,что описал Лямур,будет воплощено на 8-ом поколении.

Когда вычислительные мощности спокойно будут просчитывать все ВСЕ взаимодействия на основе реальных формул... Тогда да..(Даже не воксельная графика, а реальная симуляция атомов, с последующей фото реалистичной графикой.)

Поделиться сообщением


Ссылка на сообщение
Когда нет ограничения движка или загнанности в рамки аппаратных мощностей,создавать проще.

Ни чуть не проще. Даже я бы сказал в РАЗЫ сложнее потому, что очень много сил начинает тратиться на реализацию дополнительных графический фишек, дабы соответствовать времени, мощностям, конкурентам (в 90х годах игра с оценкой 7 баллов считалась почти шедевром, сейчас все, что имеет ниже 9 баллов считается середнячком). Сил на воплощение уникальный и инновационных идей просто не остается.

Ну и ограничения нужны, они помогают мыслить. Чем меньше ограничений, тем хуже конечный результат (Станиславский 20 лет свой идеальный "спектакль" создавал мучая актеров, а в итоге фуфло сделал). Даже такие амбициозные игры как ГТА и РДР можно развивать неограчиченно долго на нынешнем поколении консолей. По сути сейчас не используется даже 50% возможностей консольного железа (я не о графике), для воплощения всех аспектов реалистичности. Яркие примеры тому Л.А. Нуар (Анимация Лиц), Анчартед 3 и Макс Пейн 3 (анимация-симуляция взаимодействия тела с окружающими предметами - облокотиться на стену, оттолкнуться от стола, помочь рукой повернуться и т.п.), ГоВ3 (симуляция мышц под кожей - отчетливо заметно ближе к концу когда Кратос плывет в воде в темноте). Большинство разработчиков делают Графон, а все остальное остается как в 90х.

Ну а что бы делать шедевры и инновационные идеи достаточно железа NDS. И причем именно на таком слабом железе будет больше всего инновационных и шедевральных игр. Потому, что на него разработка стоит копейки, а значит разработчик может не боятся эксперементировать.

Поделиться сообщением


Ссылка на сообщение
Ни чуть не проще. Даже я бы сказал в РАЗЫ сложнее потому, что очень много сил начинает тратиться на реализацию дополнительных графический фишек, дабы соответствовать времени, мощностям, конкурентам (в 90х годах игра с оценкой 7 баллов считалась почти шедевром, сейчас все, что имеет ниже 9 баллов считается середнячком). Сил на воплощение уникальный и инновационных идей просто не остается.

Чем проще работать с движком,чем больше возможностей в него заложено,тем быстрее будет работа. Несколько лет назад смотрел ролик про крайэнжайн 2,человек просто задает параметры,проводит мышкой и создает ландшафт,горы и растительность за секунды. Если к примерно нужно создать огромный бесшовный мир без подзагрузок, с кучей npc (реалистичная анимация + вменяемый AI),полная интерактивность всего и вся,продвинутая физика,то сейчас это лишь в головах,потому что есть консольные ограничения. Это нельзя,то нельзя,в угоду 30 фпс урежем и пойдет.Или детализированную модель надо создать,а полигонами ограничены вот и крутись вертись,а в порог должен влезть. Приходят новые технологии,рамки расширяются,руки разработчиков развязываются для тех идей и возможностей,которые не были воплощены на прошлом поколении (это не только графика). Сейчас на консолях графики нет,как и нет шедевров (раз в год может чего и выйдет),погоня за баблом губительна для нас,одна надежда на инди.

Проще не изобретать велосипед,а подать слегка измененное старое и снять все сливки с продаж,не то чтобы сил нет,а скорее их никто не хочет делать.Да и потом работа в студиях рассредоточена,одни делают одно другие другое,пока команда А делает обертку,команда B параллельно занимается ее наполнением ( ну в крупных студиях по-крайней мере)

Про это и Ансель говорил,что нет аппаратных возможностей для его идей в B&GE 2 (хотя может и врал). Да и многие разработчики ждут новые консоли в плане реализации своих возможностей,лишь нескольких устраивает каррент-ген,таких как Кейдж , Спектор и Левайн,но эта троица действительно способна творить даже с тем,что есть.

Даже такие амбициозные игры как ГТА и РДР можно развивать неограчиченно долго на нынешнем поколении консолей.

Можно сделать интерактивный и детализированный мир,интуитивный AI (хотя вру,сейчас третье нельзя,да и второе вряд ли переварят),и мир будет поживее,вкупе с той же эйфорией.Эти картонные декорации себя уже изжили.Да и не только это,да,но затык все равно будет,рано или поздно.

Большинство разработчиков делают Графон, а все остальное остается как в 90х.

лоу модели и такие же на них текстуры,средняя детализация окружения,грубые тени,статичное освещение,практически нулевая физика - вот он современный графон на консолях.Хотя экзы еще выглядят более менее,но то что я описал истинное лицо мультиплатформы.

Изменено пользователем Selefior

Поделиться сообщением


Ссылка на сообщение
Несколько лет назад смотрел ролик про крайэнжайн 2,человек просто задает параметры,проводит мышкой и создает ландшафт,горы и растительность за секунды.

Это все было и в далекие 90е годы, одним движением руки создается мир. Ты забыл, что этот мир надо еще наполнить, заскриптовать нужные действия, протестировать от багов и т.п. А еще нужно написать движок соответствующий требованиям времени и железа (это занимает годы и сотни миллионов долларов). Демо КрайЭнжен 2 которое ты видел это наибональнейший редактор карт которыми пользуются уже лет 20, а то и больше.

Сейчас на консолях графики нет,как и нет шедевров (раз в год может чего и выйдет),погоня за баблом губительна для нас,одна надежда на инди.

И виной этому на 90% именно то, что современные консоли в десятки раз мощнее прошлых. Цена разработки увеличилась. А следующее поколение еще сильнее удорожит разработку и лучшее что игроки увидят это КоД-клоны. Ты похоже этого не хочешь понимать.

Про это и Ансель говорил,что нет аппаратных возможностей для его идей в B&GE 2 (хотя может и врал).

Чушь он нес несустветную, дабы хоть как то оправдаться перд игроками. И я даже уверен на 100500%, что когда выйдет B&GE2, в геймплейном плане она будет демонстрировать тоже. что могла бы на ПС2 демонстрировать. Единственное что будет иначе это анимация, да и то сомнительно, что она будет верхсовершенства ради которого нужно было обязательно на некстгене ее выпускать.

лоу модели и такие же на них текстуры,средняя детализация окружения,грубые тени,статичное освещение,практически нулевая физика - вот он современный графон на консолях.Хотя экзы еще выглядят более менее,но то что я описал истинное лицо мультиплатформы.
Я не думал что ты из тех даунов графодрочеров которых я описывал на прошлой странице... Прости, но ты не понимаешь даже 1% того, о чем я говорю. Для тебя игр не существует, ты только о графике печешься и не понимаешь, что именно наращивание железных мощностей убило игровую индустрию как индустрию искусства и сделала конвейерном безыдейных блокбастеров. Изменено пользователем Bkmz

Поделиться сообщением


Ссылка на сообщение
Я не думал что ты из тех даунов графодрочеров которых я описывал на прошлой странице...

Он не графодрочер, он объяснил что твоё заявление о том, что дескать большинство разработчиков делают графон, несостоятельно, ибо графона никакого на мультиплатформе нет.

Поделиться сообщением


Ссылка на сообщение
Он не графодрочер, он объяснил что твоё заявление о том, что дескать большинство разработчиков делают графон, несостоятельно, ибо графона никакого на мультиплатформе нет.

Если так рассуждать, то понятие "Графон" невозможно будет употреблять еще лет 100, а может и ни когда. Пока не будет изобретен квантовый ПК способный на все 100% воссоздать наш мир в виртуальности. Прежде чем такую чушь писать, головой надо думать.

Изменено пользователем Bkmz

Поделиться сообщением


Ссылка на сообщение

К слову об Анселе. Он, видимо, хотел сделать несколько планет с бесшовной загрузкой и космосом. Я даже помню, что он типа такого что-то говорил и что PS2 не позволила ему это сделать. Вот видимо он и решил дождаться того железа, которое позволит ему это сделать.

Поделиться сообщением


Ссылка на сообщение

Bkmz

Ну я всегда под словом "графон" понимал уровень графики, который на данный момент является лучшим или одним из лучших в современных играх. И беда не в том, что мы не можем нарисовать неотличимый от реального, а в том что уровень графического и технологического исполнения за последние несколько лет почти не изменился.

Поделиться сообщением


Ссылка на сообщение
К слову об Анселе. Он, видимо, хотел сделать несколько планет с бесшовной загрузкой и космосом. Я даже помню, что он типа такого что-то говорил и что PS2 не позволила ему это сделать. Вот видимо он и решил дождаться того железа, которое позволит ему это сделать.

И опять же это несусветная чушь. Единственное, что в теории могло не дать воплотить это в жизнь, это нехватка места на DVD диске (все мы знаем, что игра занимала 1CD, так что такая теория разваливается). И во времена PS2 и первого Xbox существовали ОГРОМНЫЕ игры с несколькими планетами. Быть может Ансель чего то недоговорил, но то, что он описал из якобы невозможного на PS2 было реализовано различными разработчиками в других играх на PS2.

Хоть убейте, но я не знаю чего у него были за идеи, которые не смогла потянуть PS2, не считая суперграфы. Ну и в целом я много игр играл на PS2, и много игр на PC и современных консолей. Не считая графических аспектов я не увидил ни чего, что бы на супермощных ПК было реализовано такого, чего не было на PS2. Так что вся это чушь о потребности нового железа исходит лишь от производителей железа и тех, кто кроме графики ни чего не умеет делать (Крайтек например).

Поделиться сообщением


Ссылка на сообщение
Это все было и в далекие 90е годы, одним движением руки создается мир. Ты забыл, что этот мир надо еще наполнить, заскриптовать нужные действия, протестировать от багов и т.п. А еще нужно написать движок соответствующий требованиям времени и железа (это занимает годы и сотни миллионов долларов). Демо КрайЭнжен 2 которое ты видел это наибональнейший редактор карт которыми пользуются уже лет 20, а то и больше.

Может и так,но я не думаю,что все было в разы проще.Я к тому,что новое позволит упростить обыденные действия.Опять же не упускай,что есть разделение полномочий.Большая часть студий использует лицензии,не надо это забывать,а те которые пишут свои двиглы,не сильно обременены времен и имеют довольно большой штат, а так же финансирование.

А следующее поколение еще сильнее удорожит разработку

Возможно,но опять же крупные студии это не пугает.

Чушь он нес несустветную, дабы хоть как то оправдаться перд игроками. И я даже уверен на 100500%, что когда выйдет B&GE2, в геймплейном плане она будет демонстрировать тоже. что могла бы на ПС2 демонстрировать. Единственное что будет иначе это анимация, да и то сомнительно, что она будет верхсовершенства ради которого нужно было обязательно на некстгене ее выпускать.

Те идеи известные только Анселю и его студии,а не тебе и не мне. Просто я отталкиваюсь от его слов,которые могут правдивы.

Я не думал что ты из тех даунов графодрочеров которых я описывал на прошлой странице... Прости, но ты не понимаешь даже 1% того, о чем я говорю. Для тебя игр не существует, ты только о графике печешься и не понимаешь, что именно наращивание железных мощностей убило игровую индустрию как индустрию искусства и сделала конвейерном безыдейных блокбастеров.

Опять же ты видишь свои надуманные мысли и звучит твоя коронная фраза : "Ты :censored:а я умнее".На мой взгляд не мощности делают безликим геймдев,а жадность издателей.

Если так рассуждать, то понятие "Графон" невозможно будет употреблять еще лет 100, а может и ни когда.

Не вкладывается сейчас в эту сторону никаких сил,о которых ты пишешь.Если бы каждая игра давала хоть мелкий да в чем-то прорыв в этом,тогда да.

Поделиться сообщением


Ссылка на сообщение
Возможно,но опять же крупные студии это не пугает.

99.9% таких студий, это производители КоД и им подобных одноплановых блокбастеров. То есть в играх полностью пропадут интересные идеи.

Те идеи известные только Анселю и его студии,а не тебе и не мне. Просто я отталкиваюсь от его слов,которые могут правдивы.

Я отталкиваюсь от того игровой индустрии в целом. И Ансель, ни сделал ни одной инновационной игры, то есть в геймплейном плане он копипастер, креативность его кроится в другом. Вот если бы это сказал Кодзима, Левел 5, Мулинье на худой конец, тоесть те кто действительно реализовывал инновационные идеи, можно было, о чем то говорить. Но их я зря приплетаю, у них хватает таланта придумывать инновации в любых средах разработки.

На мой взгляд не мощности делают безликим геймдев,а жадность издателей.

И опять эта наивная детсадовская чушь. Игры это БИЗНЕС, если игра стоит 100 миллионов, а приносит 5 миллионов, естественно такую студию разработчиков распустят и вообще не допустят больше к сему делу. В этом и кроится проклятье данного поколения консолей, и следующего и так далее.

Что бы создать игру, сейчас нужно в 100 раз больше денег вложить (главным образом от того, что на прорисовку современной графики нужен не 1 а 10 человек). Это и убивает индустрию. Рисковать просто так ради воздуха ни кто не хочет (я сомневаюсь, что ты бы отдал 100 миллионов рублей знача, что тебе вертенся всего 5 миллионов, но зато хорошая игра). А во времена ПС2 (и ранее) студия могла себе позволить произвести 10 провальных эксперементов, но с лихвой их окупить 1 успешным (именно поэтому в те времена игр было в разы больше и в разы неординарнее).

Вот именно этого ты не можешь понять в своем рвении за графикой.

Не вкладывается сейчас в эту сторону никаких сил,о которых ты пишешь.Если бы каждая игра давала хоть мелкий да в чем-то прорыв в этом,тогда да.

Сейчас, это последний 1-2 года. Период когда разработчики уже освоились с технологиями и могут творить в свое удовольствие. Но 5 лет до этого они тратили все свое время на графические технологии, от этого на старте поколения было так много шлака который становился популярен на безрыбье (лост планет, Каин и Линч и т.п.). Новое поколение опять поставит перед фактом, что разрабы опять обязаны все свое время тратить на освоение возможностей иного железа (это только на ПК можно выпускать беттаверсии игр и потом пару лет палировать).

Но сейчас еще встал другой вопрос. ДИКО дорогое 7е поколение консолей разоряет игровой бизнес, в последние годы все издатели несут убытки (Даже Нинтендо, впервые за свою, почти столетнюю, историю начала нести убытки). Вот наглядный пример как погоня за графодрочерством убивает игровую индустрию.

Поделиться сообщением


Ссылка на сообщение
И опять эта наивная детсадовская чушь. Игры это БИЗНЕС, если игра стоит 100 миллионов, а приносит 5 миллионов, естественно такую студию разработчиков распустят и вообще не допустят больше к сему делу. В этом и кроится проклятье данного поколения консолей, и следующего и так далее.

Что бы создать игру, сейчас нужно в 100 раз больше денег вложить (главным образом от того, что на прорисовку современной графики нужен не 1 а 10 человек). Это и убивает индустрию. Рисковать просто так ради воздуха ни кто не хочет (я сомневаюсь, что ты бы отдал 100 миллионов рублей знача, что тебе вертенся всего 5 миллионов, но зато хорошая игра). А во времена ПС2 (и ранее) студия могла себе позволить произвести 10 провальных эксперементов, но с лихвой их окупить 1 успешным (именно поэтому в те времена игр было в разы больше и в разы неординарнее).

Нет зависимости от мощности,для того чтобы издатель нанял хорошего сценариста (для глубокого сюжета и интересных диалогов),отдал CGI на аутсорсинг профессионалам (как это делают скворцы),сделал моушен капчур для нормальной анимации,отдал игру в руки нормального именитого разработчика,а не трешоделу,который запросит копейки,выделить деньги на кинематографическую постановку. Этого сейчас нет и графики нет,где связь тогда? Отдаем игру простой команде,лепим на нее именитый бренд и получаем деньги (последний вышедший RE тому пример),маркетинг он такой и никакого вложения в графическую сторону.

Ок,есть цифры/пруфлинк,что на программистов (сконцентрированных на графике) ,дизайнеров и на лицензию движка уходит более 50% бюджета ?

Вот именно этого ты не можешь понять в своем рвении за графикой.

С точки зрения нового поколения,я не акцентируюсь на графике,в другой теме я тебе уже про это писал.Здесь конкретно я отписал про: "огромный бесшовный мир без подзагрузок, с кучей npc (реалистичная анимация + вменяемый AI),полная интерактивность всего и вся,продвинутая физика"

Изменено пользователем Selefior

Поделиться сообщением


Ссылка на сообщение
Нет зависимости от мощности,для того чтобы издатель нанял хорошего сценариста (для глубокого сюжета и интересных диалогов),отдал CGI на аутсорсинг профессионалам (как это делают скворцы),сделал моушен капчур для нормальной анимации,отдал игру в руки нормального именитого разработчика,а не трешоделу,который запросит копейки,выделить деньги на кинематографическую постановку. Этого сейчас нет и графики нет,где связь тогда? Отдаем игру простой команде,лепим на нее именитый бренд и получаем деньги (последний вышедший RE тому пример),маркетинг он такой и никакого вложения в графическую сторону.
Ок,есть цифры/пруфлинк,что на программистов (сконцентрированных на графике) ,дизайнеров и на лицензию движка уходит более 50% бюджета ?

Простая арифметика. Средняя З\П 1.5 тысячи долларов, над КоД работает штат из 200 сотрудников (на самом деле куда больше, но там они параллельно), игра разрабатывается около 2х лет. Сложи и получишь цифру затраченную только на З\П, без учета покупки оборудования, съема помещений, выездов за границу или полигоны для сбора информации, уж молчу о рекламе и прочем.

Если ты не понимаешь, то удорожание разработки идет от того, что на рисовку и тестирование современных высокодетализированных текстур, написание кода который в десятки раз больше и сложнее оного на прошлом поколении) нужно в разы больше народу, и не важно, свой штат или аутсерсинг.

Ну а теперь раскинь мозгами и подумай, как при подобных затратах ты позволишь себе рисковать выпуская десяток нестандартных продуктов?

С точки зрения нового поколения,я не акцентируюсь на графике,в другой теме я тебе уже про это писал.Здесь конкретно я отписал про: "огромный бесшовный мир без подзагрузок, с кучей npc (реалистичная анимация + вменяемый AI),полная интерактивность всего и вся,продвинутая физика"

Нынешнего поколения за глаза для этого хватает. Да, бесспорно следующее поколение это улучшит, одновременно еще подняв в пару раз цену разработки игр. А смысл в этом если 99% разработциков все равно все ресурсы будут тратить на продвижение исключительно полигонов.

Я уже привел выше несколько игр, которые продемонстрировали, как без потерь в качестве картинки поднять реалистичность на пару голов выше. Но таких игр по пальцам одной руки перечесть, а 99% крупных разработчиков остались на уровне 90х годов увеличив только полигоны.

Изменено пользователем Bkmz

Поделиться сообщением


Ссылка на сообщение

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.

Войти сейчас


  • Продвигаемые темы

  • Последние сообщения

    • Есть такое аниме — игра короля, в общем там суть такая что школолам давали задания и если они их не выполняли то помирали. В общем там одному челу дали задание в ближайшие 5 минут насадить тянку на кол, а рядом был его лучший друг со своей девушкой, и они решили его спасти. Друг его вырубил крепким ударом, а девушка сделала все остальное. Ну так суть в чем, если у чела в отключке это получилось, то и у тебя тоже получится.
    • Неоспоримый факт — это ваша стилистическая импотенция и графомания
    • @Universal312, как говорится: "Звиздеть - не мешки таскать."
    • Это явно та медсестра, за которой ты бегал по ночам, с тобой заигрывает и что то подмешивает в каждую твою вечернюю клизму
    • А можешь собрать хотя бы 10000 (лучше — больше) на “разработку инструментов”, чтобы закончить перевод, а потом написать, что комп изъяли? Хотя, погодите-ка
    •   Русификатор Yukan Madam Club 有閑夫人倶楽部 Дата выхода 27 марта 2026(только в Японии) Сайт игры:https://www.empress-game.com/yukanmadam/ Жанр: Визуальная новелла Разработчик: Empress Издатель: Empress Платформы: Windows Описание:  Главный герой только что перевёлся в новую школу и ещё не обзавёлся близкими друзьями. Но однажды он знакомится с Крисом — красивым светловолосым юношей из своего класса; они быстро находят общий язык и становятся близки. Когда Крис приглашает его к себе домой, герой обнаруживает, что тот живёт в невероятно роскошном особняке с бассейном во дворе, а комната Криса выглядит куда богаче, чем его собственная. Однажды, когда Крис выходит из комнаты, герой случайно находит на его компьютере файл и заглядывает в него — там оказывается огромное количество фото и видео, на которых Крис занимается сексом с женщиной, очень похожей на его мать... Крис открывает ему правду об их запретных отношениях между родителем и ребёнком и даже предлагает герою самому переспать с матерью, если тот этого пожелает. Не в силах противостоять соблазну и собственным желаниям, герой в итоге поддаётся и вступает в связь с мамой Криса... Это становится началом: вскоре он начинает заводить отношения с матерями других одноклассников и даже познаёт запретную любовь со своей собственной матерью... Куда же в итоге приведёт эта запретная родительская любовь?
      Сделал нейросетевой перевод:
      Rio1.arc - Google Диск - Файл с русским переводом. (Просто добавить в папку игры с заменой и всё) translation_complete3_ready.tsv - Google Диск — Таблица, в которой работал. (для тех кто хочет сам поработать над переводом) Переведены: диалоги, имена и выборы(остальное в оригинале)
    • У меня Опера. Там нема. Но стоит расширение. Нужно было выделить текст. Но почему-то не выделялся. Б-я-да, короче.
    • Архитектура инструмента для распаковки и обратной упаковки ресурсов PS3-игры Ниже — безопасный подход к разработке утилиты для фанатского перевода, редактирования шрифтов, текстурных атласов, строк и субтитров в The Ratchet & Clank Trilogy (HD Collection) либо похожей PS3/Vita-игре. Подход рассчитан только на легальный моддинг: собственные носители, личные дампы, homebrew-среду и уже доступные для редактирования ресурсы. Он не включает обход DRM, подписи исполняемых модулей, ключи, защищённые EBOOT/SPRX или другие системные механизмы защиты. 1. Общий анализ задачи Какие структуры обычно встречаются в ресурсах PS3-игр Игровые данные редко состоят из независимых файлов «как на ПК». Обычно применяются контейнеры одного или нескольких уровней: Тип структуры Назначение Обычный архив Последовательность файлов с таблицей содержимого (TOC). bigfile / packfile Большой бинарный файл с ресурсами, доступными по offset и size. PSARC Контейнер Sony, часто содержащий сжатые файлы и таблицу записей. Внутренний контейнер Формат движка: строки, текстуры, модели, шрифты, субтитры в собственных бинарных блоках. Таблица смещений Список адресов начала ресурсов или секций. Таблица размеров Список размеров исходных или сжатых данных. Таблица имён / хешей Имена файлов либо хеши путей, если имена не хранятся открыто. Индексный бинарник Отдельный файл, сопоставляющий языки, архивы, шрифты, видео и ресурсы. Условная структура архива может выглядеть так: +-------------------------------+ | Header | | magic: "PACK" / "PSAR" / ... | | version | | file_count | | toc_offset | | data_offset | +-------------------------------+ | TOC / File entries | | entry[0]: offset, size, hash | | entry[1]: offset, size, hash | | ... | +-------------------------------+ | Name table / string table | +-------------------------------+ | Resource data | | file 0 | | padding | | file 1 | | padding | | ... | +-------------------------------+ Почему архив может перестать загружаться после перепаковки Даже если содержимое ресурса изменено корректно, движок может отклонить архив, если нарушена его структура: смещение файла в TOC указывает на старый адрес; поле размера не соответствует фактическому числу байтов; нарушено выравнивание данных; не обновлена CRC32 или другой хеш; изменился порядок записей; файл должен быть сжат, но записан несжатым; таблица имён, хешей или индексов не соответствует содержимому; сдвинулись внутренние указатели внутри самого ресурса; изменена endian-последовательность чисел; изменился формат текстуры, но метаданные остались прежними. Что обычно называют «проверкой веса» Фраза «проверка веса файла» технически неоднозначна. В игровых форматах это может означать: Возможное значение Что это на практике Размер файла Поле size в заголовке, TOC или внешнем индексе. Сжатый размер compressed_size, если ресурс хранится сжатым. Исходный размер uncompressed_size, нужный для выделения буфера и распаковки. Размер контейнера Поле archive_size или ожидаемый конец файла. Размер записи Размер блока в TOC, включая служебные поля. CRC Контрольная сумма, часто CRC32. Хеш MD5, SHA-1 или пользовательский алгоритм для проверки данных/пути. Выравнивание Размер округляется до 0x10, 0x80, 0x800, 0x1000 и т. п. Padding Заполняющие байты между ресурсами, часто 00, FF или специальный шаблон. Правильная цель инструмента — не отключать проверку, а определить формат и корректно пересчитывать зависимые поля. 2. Юридическая и этическая рамка Инструмент следует проектировать для работы только с: собственными легально полученными данными; личными дампами; тестовыми или homebrew-ресурсами; открытыми, распакованными, незащищёнными контейнерами; модами, распространяемыми без оригинальных игровых ассетов. Не следует: извлекать и распространять чужие коммерческие игровые ресурсы; публиковать игровые архивы, текстуры, видео и бинарники целиком; заниматься обходом DRM, подписей, шифрования, лицензионных проверок; модифицировать защищённые системные модули ради снятия ограничений. Если требуемая часть логики находится в защищённом EBOOT/SPRX либо зависит от криптографически защищённого контейнера, безопасная граница работы — анализ уже распакованных открытых ресурсов, использование существующих легальных средств извлечения и создание патчей/манифестов, а не распространение оригинального содержимого. 3. CLI-проектирование инструмента Утилита должна быть предсказуемой, воспроизводимой и по умолчанию не портить исходники. Пример имени: rctool. rctool list archive.bin rctool inspect archive.bin rctool extract archive.bin —out ./extracted rctool pack ./extracted —out ./archive_packed.bin rctool verify original.bin modified.bin rctool diff-toc original.bin modified.bin rctool font-report ./game_resources —dump-glyphs rctool atlas-verify font_atlas.dds font_metrics.bin rctool subtitle-report subtitles.bin rctool psarc list data.psarc rctool psarc extract data.psarc —out ./psarc_extracted rctool psarc pack ./psarc_extracted —out ./data_mod.psarc Полезные параметры —format auto|psarc|bigfile|custom —endian auto|big|little —alignment 0x800 —dry-run —strict —verbose —json-report report.json —manifest manifest.json —keep-order —verify-checksums —no-compress Принципы CLI Исходный файл никогда не перезаписывается по умолчанию. Любая распаковка создаёт манифест. Упаковка работает только на основе манифеста. —dry-run показывает будущие offsets, размеры и расхождения без записи файла. verify проверяет структуру независимо от запуска игры. Все неизвестные поля и подозрительные записи логируются. 4. Структура парсера ресурсов Парсер не должен быть «набором жёстких смещений». Лучше разделить чтение формата на явные слои. Базовые поля, которые нужно искать Поле Типичный размер Назначение Magic / signature 4—16 байт Идентификатор формата: например, PSAR. Version 2 или 4 байта Версия контейнера. Endianness Не всегда явно Обычно определяется по magic/version/count. Header size 4 байта Размер заголовка. File count 4 байта Число записей в TOC. TOC offset 4/8 байт Адрес таблицы файлов. Name table offset 4/8 байт Адрес строковых имён, если есть. Data offset 4/8 байт Начало области ресурсов. Entry offset 4/8 байт Смещение конкретного файла. Packed size 4/8 байт Размер хранимых данных. Unpacked size 4/8 байт Размер после распаковки. CRC/hash 4—32 байта Целостность данных или идентификатор пути. Flags 4 байта Сжатие, тип данных, язык, платформа и т. п. Alignment 4 байта или константа Требуемое выравнивание блока. Endianness PS3 часто использует big-endian, но это не означает, что каждый ресурс обязательно big-endian. В одном проекте могут сосуществовать: big-endian заголовки движка; little-endian DDS-текстуры; little-endian сжатые блоки; собственные форматы с фиксированным порядком байтов. Нельзя выбирать порядок байтов «по платформе». Его нужно подтвердить наблюдением. Пример: Bytes: 00 00 01 00 Big-endian: 0x00000100 = 256 Little-endian: 0x00010000 = 65536 Если архив содержит 256 файлов, big-endian здесь правдоподобен. Если 65536 — вероятно, интерпретация неверна. Указатели на внутренние секции В ресурсах могут быть внутренние адреса: font_table_offset glyph_count atlas_texture_id string_table_offset language_table_offset subtitle_track_offset video_cue_table_offset Важно установить, что представляет собой offset: абсолютное смещение от начала файла; относительное смещение от начала секции; относительное смещение от текущей структуры; виртуальный адрес, который не следует путать с file offset; индекс записи, а не смещение. 5. Безопасное исследование «проверки веса» Цель исследования: найти зависимые поля и правила их обновления. Рекомендуемый процесс 1. Сохранить нетронутый оригинал Работать только с копией: original/ work/ output/ reports/ Для каждой версии фиксировать: имя файла; размер; SHA-256 для локальной идентификации; дату; использованную версию инструмента. 2. Открыть бинарник в hex-редакторе Подходящие инструменты: ImHex; 010 Editor; HxD; wxHexEditor; любой hex-diff-инструмент. Искать: читаемый magic; повторяющиеся записи одинаковой длины; числа, похожие на offsets; возрастающие значения, кратные 0x10/0x800/0x1000; ASCII/UTF-8/UTF-16-строки; хеши длиной 4, 16, 20 или 32 байта. 3. Сопоставить TOC с реальными данными Для каждой записи проверить: offset + stored_size <= archive_file_size offset >= data_region_start offset % alignment == 0 Если ресурс начинается по offset 0x12000, а следующая запись начинается с 0x12800, то: real data range: [0x12000, 0x12800) allocated span: 0x800 stored size: может быть меньше 0x800 padding: allocated span - stored size 4. Выполнить минимальный контролируемый эксперимент Например, заменить один текстовый ресурс на вариант: той же длины; на 1 байт длиннее; на 16 байт длиннее; на 1 байт короче. Затем сравнить результаты упаковки или файлы, обработанные известным инструментом, если он существует. Так можно увидеть: какие поля меняются; где лежит size; меняется ли архивный размер; пересчитывается ли CRC; сохраняется ли прежний allocation span; сдвигаются ли последующие записи. 5. Построить таблицу наблюдаемых полей Пример рабочей таблицы: Offset Размер Предполагаемое поле Значение до Значение после Уверенность 0x0C 4 file_count 1532 1532 высокая 0x10 4 toc_offset 0x40 0x40 высокая 0x24 4 archive_size 0x028A4000 изменилось средняя 0x144 4 entry[0].offset 0x8000 0x8000 высокая 0x148 4 entry[0].size 0x1A2C изменилось высокая 0x14C 4 entry[0].crc32 изменилось изменилось средняя 6. Сравнивать CRC, MD5, SHA-1 и пользовательские хеши Если 4-байтовое поле меняется после изменения содержимого, проверьте кандидаты: zlib.crc32(data) & 0xFFFFFFFF Для распространённых хешей: hashlib.md5(data).digest() hashlib.sha1(data).digest() hashlib.sha256(data).digest() Но совпадение не следует предполагать: поле может быть: CRC от распакованных данных; CRC от сжатых данных; CRC от имени/пути; хешем другой секции; ID записи; пользовательским алгоритмом. 7. Реализовать dry-run До фактической упаковки вывести отчёт: Entry 0042: strings_ru.bin old offset: 0x00124000 new offset: 0x00124000 old packed size: 0x00003A20 new packed size: 0x00003B10 alignment: 0x800 padding required: 0x4F0 checksum: CRC32 9A0B1C2D status: valid 8. Не отключать проверки Если игра отвергает модифицированный архив, правильный вопрос: «Какие метаданные формат ожидает и как они вычисляются?» А не: «Как отключить проверку?» 6. Алгоритм распаковки Результат распаковки extracted/ manifest.json files/ 0000_unknown.bin 0001_menu_strings.bin 0002_font_atlas.dds 0003_font_metrics.bin reports/ extract_report.json suspicious_entries.json Пример манифеста { "format": "custom_bigfile", "source_file": "archive.bin", "source_size": 42614784, "endianness": "big", "header": { "version": 3, "file_count": 1532, "toc_offset": 64, "data_offset": 49152, "alignment": 2048 }, "entries": [ { "index": 0, "name": "0000_unknown.bin", "name_hash": "0xA1B2C3D4", "original_offset": 49152, "stored_size": 6700, "unpacked_size": 6700, "flags": 0, "compression": "none", "checksum_type": "crc32", "checksum": "0x19D5A0F3", "alignment": 2048 } ] } Пошаговый алгоритм Открыть файл в бинарном режиме. Прочитать минимальный заголовок. Проверить magic и версию. Определить endian-порядок. Прочитать размер заголовка и расположение TOC. Прочитать все записи TOC. Для каждой записи: извлечь offset, stored_size, unpacked_size, flags; проверить выход за границы файла; проверить выравнивание; извлечь блок; проверить CRC/hash, если алгоритм известен; определить сжатие по флагам или сигнатуре; распаковать известный формат, например zlib/deflate; сохранить файл и метаданные. Записать манифест. Создать отчёт о подозрительных местах. Подозрительные записи Нужно фиксировать, но не игнорировать: offset + size > archive_size; offset не выровнен; два файла перекрываются; размер распакованных данных не совпадает с unpacked_size; неизвестный compression flag; checksum не совпадает; пустой файл с необычными флагами; запись с offset 0, но ненулевым размером. 7. Алгоритм обратной упаковки Обратная упаковка должна быть детерминированной: одинаковый вход и параметры дают одинаковый результат. Основной порядок работы Прочитать manifest.json. Проверить, что все ожидаемые файлы существуют. Сохранить исходный порядок записей. Для каждого файла: прочитать изменённые данные; сжать тем же способом, что указан в манифесте; определить фактический stored size; обновить unpacked size; вычислить checksum нужного типа. Рассчитать новые offsets с учётом alignment. Создать новый TOC. Записать заголовок, TOC, имена и метаданные. Записать блоки данных и padding. Обновить размер контейнера, если он хранится. Выполнить внутреннюю проверку созданного файла. Сравнить структуру с оригиналом через verify и diff-toc. Важное решение: перемещать файлы или сохранять исходные места Есть два режима. Режим A: полная перепаковка Все offsets рассчитываются заново. Плюсы: подходит для значительных изменений; не ограничивает размер конкретного ресурса; проще алгоритмически. Минусы: все последующие данные могут сдвинуться; внешние ссылки на offset могут стать невалидными; архив может сильнее отличаться от оригинала. Режим B: in-place / фиксированные слоты Файлы остаются на старых offsets и не могут превысить выделенный span. Плюсы: минимальные отличия; безопаснее, если внешний бинарник хранит offsets; удобно для маленьких текстовых правок. Минусы: новый файл нельзя сделать больше доступного места; приходится перераспределять резерв или сокращать данные. Для первой версии полезно поддержать оба режима: rctool pack extracted —mode rebuild rctool pack extracted —mode in-place Проверки после сборки header.file_count == len(entries) entry.offset % alignment == 0 entry.offset + entry.stored_size <= archive_size no_ranges_overlap(entries) stored_size == len(stored_data) unpacked_size == len(unpacked_data) checksum(entry_data) == entry.checksum 8. Работа со шрифтами и атласами Шрифт в игре часто состоит минимум из двух частей: текстурный атлас — изображение с пикселями символов; таблица метрик — бинарная структура, объясняющая движку, где искать глиф и как его рисовать. Иногда добавляются: таблица Unicode/codepoint → glyph index; kerning pairs; несколько атласов для разных размеров; fallback-шрифт; таблицы языков; стиль текста: обводка, тень, цвет, масштаб. Где может быть таблица глифов Она может находиться: рядом с текстурой в одном контейнере; в отдельном .bin, .fnt, .font, .dat; внутри бинарника движка; внутри локализационного пакета; в ресурсной записи, найденной по имени или хешу. Признаки таблицы: последовательность структур фиксированного размера; значения x/y/width/height, не превышающие размеры атласа; ASCII-коды 0x20—0x7E; количество записей, близкое к 96, 128, 256, 512, 1024; повторяющиеся значения advance/width; ссылки на одну и ту же текстуру. Варианты хранения символов Модель Пример Direct ASCII Glyph 65 = A. Unicode codepoint U+0410 → глиф А. Индексная таблица Codepoint → индекс → запись глифа. Custom encoding Байтовые коды игры отображаются в собственную таблицу. Смешанная схема ASCII напрямую, расширенные символы через lookup table. Типичная запись глифа struct Glyph { uint32_t codepoint; // U+0041, U+0410 и т. п. uint16_t atlas_index; // номер атласа uint16_t flags; float u0; // левая UV-координата float v0; // верхняя UV-координата float u1; // правая UV-координата float v1; // нижняя UV-координата int16_t bearing_x; // смещение пера по X int16_t bearing_y; // смещение пера по Y uint16_t width; uint16_t height; int16_t advance_x; // на сколько сдвигать курсор }; В другом формате UV могут быть не float, а пиксельными координатами: struct Glyph { uint16_t codepoint; uint16_t x; uint16_t y; uint16_t width; uint16_t height; int16_t advance; int16_t bearing_x; int16_t bearing_y; }; Добавление кириллицы без поломки латиницы Безопасная стратегия: Сначала извлечь существующие символы и создать отчёт. Определить диапазоны: ASCII: U+0020—U+007E; кириллица: U+0400—U+04FF; часто нужные символы: Ё, ё, №, длинное тире, кавычки. Не заменять латинские глифы, если их индексы используются напрямую. Добавить новые записи в свободный диапазон либо расширить таблицу только после понимания её структуры. Внести символы в codepoint lookup table. Добавить пиксели символов в атлас. Обновить UV/координаты, размеры и advance. Проверить fallback-логику: некоторые движки заменяют неизвестный символ ? или пустым глифом. Почему может понадобиться новый атлас Если в исходном атласе нет свободного места, новые глифы некуда разместить. Варианты: уплотнить существующие символы; использовать пустые/неиспользуемые глифы; увеличить разрешение атласа, если формат и движок это допускают; добавить второй атлас, если таблица поддерживает atlas_index; уменьшить размер шрифта; выбрать компактный набор символов. Нельзя просто увеличить DDS/текстуру, не проверив, где хранится ширина, высота, mipmap count и формат пикселей. Проверка границ глифа Для атласа 1024 × 1024: 0 <= x < 1024 0 <= y < 1024 x + width <= 1024 y + height <= 1024 Для нормализованных UV: 0.0 <= u0 <= u1 <= 1.0 0.0 <= v0 <= v1 <= 1.0 Автоматический font-report Отчёт должен содержать: Atlas: font_0.dds Resolution: 1024 x 1024 Glyph entries: 248 Unique codepoints: 246 Duplicate codepoints: U+003F, U+0410 Out-of-bounds glyphs: 2 Missing Russian characters: U+0401, U+0451, U+042A Unused atlas area: 31.4% Идеально также создать: CSV с метриками; JSON для дальнейшего анализа; PNG-превью с сеткой и подписанными glyph indices; перечень символов, реально используемых в переводе, но отсутствующих в шрифте. 9. PSARC и привязка к контейнеру Если ресурсы находятся в PSARC или похожем контейнере, его нужно рассматривать как отдельный слой. PSARC ├─ archive TOC ├─ block/deflate metadata ├─ file path table или hash table └─ внутренние ресурсы ├─ font atlas ├─ font metrics ├─ strings ├─ subtitles └─ texture packages Требования к PSARC-адаптеру Прочитать заголовок контейнера. Прочитать и сохранить TOC. Сохранить порядок файлов. Сохранить размеры блоков и признаки сжатия. Извлечь внутренние файлы. Создать отдельный PSARC-манифест. При сборке применить исходное выравнивание и порядок. Выполнить валидацию offsets, размеров и блоков. Внешние зависимости После изменения PSARC нужно проверить, есть ли другой файл, который хранит: путь к архиву; хеш ресурса; индекс файла в архиве; ожидаемый размер; offset; версию пакета; таблицу языков; список загружаемых ресурсов. Если такая зависимость найдена, корректно обновляется или валидируется именно её открытая ресурсная структура. Работа с защищёнными исполняемыми модулями и механизмами платформы остаётся вне рамок инструмента. 10. Субтитры и видео Субтитры могут быть реализованы несколькими способами. Вариант Что редактируется Строки текста + таймкоды Таблица строк и cue table. Текстуры субтитров Атлас изображений и таблица кадров. Предрендеренные изображения Последовательность текстур/спрайтов. Встроенные в видео Практически не редактируются без исходного видеопайплайна. Скриптовые события Команды показа текста с timestamp и ID строки. Что проверить формат времени: кадры, миллисекунды, ticks; FPS: 25, 30, 50, 60 или иной; ID строки и соответствие локализационной таблице; порядок cue-записей; длительность отображения; кодировку текста; максимальную длину строки; переносы, теги и управляющие символы; привязку к конкретному ролику или главе. Типичная структура cue struct SubtitleCue { uint32_t start_time; uint32_t end_time; uint32_t string_id; uint16_t style_id; uint16_t flags; }; При текстурных субтитрах вместо string_id могут быть: uint16_t atlas_id; uint16_t sprite_id; Нельзя менять порядок или количество записей без проверки того, как ролик или сценарий обращается к ним. 11. Рекомендуемый стек Python: лучший старт для исследования Python хорошо подходит для первого рабочего прототипа. Библиотека Назначение struct Чтение и запись чисел заданного endian-порядка. pathlib Безопасная работа с путями. argparse CLI. json Манифесты и отчёты. logging Диагностика. zlib CRC32, deflate, zlib. hashlib MD5/SHA-1/SHA-256 для исследования. dataclasses Описание header/entry структур. pytest Unit-тесты. Пример чтения big-endian числа: import struct file_count = struct.unpack(">I", data[0x08:0x0C])[0] Little-endian: file_count = struct.unpack("<I", data[0x08:0x0C])[0] C# Подходит, если нужен GUI: удобная работа с бинарными файлами; WPF/Avalonia для интерфейса; просмотр atlas/glyph table; drag-and-drop для архивов; Windows-ориентированный пайплайн. Rust / C++ Подходят для финального производительного инструмента: строгая работа с бинарными структурами; контроль ошибок; большие архивы; потоковая обработка; безопасное разделение модулей. Но начинать исследование формата обычно быстрее в Python. Инструменты анализа 010 Editor — шаблоны бинарных форматов. ImHex — pattern language, визуальный анализ. HxD — быстрый просмотр и сравнение. QuickBMS — быстрые экспериментальные скрипты для распаковки известных форматов. vbindiff / Beyond Compare / Hex Fiend / HxD — побайтовое сравнение. Kaitai Struct — декларативное описание формата и генерация парсеров. 12. MVP-архитектура rctool/ cli.py config.py formats/ base.py custom_archive.py psarc.py parsers/ header_parser.py toc_reader.py font_table_parser.py subtitle_parser.py services/ extractor.py repacker.py verifier.py diff_service.py manifest_service.py codecs/ compression_handler.py checksum_validator.py texture_adapter.py models/ archive_header.py archive_entry.py font_glyph.py manifest.py reporting/ logger.py json_report.py font_report.py tests/ test_header_parser.py test_toc_reader.py test_repacker.py test_alignment.py fixtures/ Назначение модулей Модуль Ответственность header_parser Чтение и валидация заголовка. toc_reader Чтение записей файловой таблицы. entry_extractor Извлечение конкретных блоков. compression_handler Сжатие/распаковка известных алгоритмов. checksum_validator CRC/hash-проверки и пересчёт. repacker Сборка контейнера, offsets и padding. manifest_serializer Сохранение метаданных извлечения. font_table_analyzer Глифы, метрики, codepoint table, UV. psarc_adapter Поддержка PSARC как отдельного формата. CLI interface Команды и параметры пользователя. logger/reporter Диагностика, отчёты, dry-run. 13. Тестирование Не хранить игровые ассеты в репозитории В репозитории должны находиться только: синтетические тестовые архивы; минимальные искусственные текстуры; тестовые таблицы глифов; обезличенные фрагменты заголовков при необходимости; генераторы фикстур. Не следует добавлять оригинальные данные игры. Набор тестов Unit-тесты чтение big-endian и little-endian значений; чтение header; чтение TOC; выравнивание 0x10, 0x80, 0x800, 0x1000; проверка диапазонов; CRC32; сжатие и распаковка; сериализация манифеста; проверка UV и границ глифов. Интеграционные тесты synthetic archive -> extract -> pack -> verify -> byte-identical result Если архив собирается без изменений, ожидаемый результат: original.bin == repacked.bin Побайтовая идентичность крайне полезна: она доказывает, что парсер и упаковщик верно воспроизводят формат хотя бы для неизменённого случая. Тесты изменения размера Файл без изменения длины. Файл увеличен на 1 байт. Файл увеличен до следующего alignment boundary. Файл уменьшен. Несколько файлов изменены одновременно. Сжатый файл, у которого packed size меняется непредсказуемо. Проверка отчётом rctool verify original.bin repacked.bin —structure-only rctool diff-toc original.bin repacked.bin 14. Типичные ошибки Ошибка Последствие Перепутан big-endian и little-endian Неверные offsets, sizes, counts; файл не читается. Не учтён padding Следующий ресурс начинается не там, где ожидает TOC. Изменён порядок записей Внешние индексы или хеш-таблицы указывают не на тот ресурс. Не обновлена offset table Движок читает старые адреса. Не обновлены size fields Переполнение, обрезание или отказ загрузки. Не пересчитан CRC/hash Формат определяет ресурс как повреждённый. Нарушено выравнивание Ошибка чтения блоков или проблемы DMA/потоковой загрузки. Неверно определено сжатие Невозможно распаковать ресурс. Строка сохранена в неверной кодировке Кракозябры, пустые символы, сбои parser-а. Не учтена нуль-терминация Следующая строка «склеивается» с текущей. Таблица глифов не соответствует атласу Неправильные буквы, визуальный мусор, вылет. Кириллица добавлена без codepoint table Игра не находит символы. UV выходят за границы Захватываются соседние глифы или пустые области. DDS/текстура пережата в другом формате Неподдерживаемый pixel format, неверные цвета или крах. Не обновлены mipmaps Артефакты или ошибка загрузки текстуры. Субтитры потеряли тайминги Реплики появляются слишком рано, поздно или не появляются. Изменена длина блока, но старые внешние offsets сохранены Ломается загрузка последующих данных. Техническое ТЗ для MVP Цель Разработать CLI-утилиту для анализа, извлечения, проверки и обратной упаковки открытых игровых ресурсных контейнеров, с сохранением структуры, порядка записей, offsets, размеров, выравнивания и контрольных сумм. Функциональные требования Автоматическое или заданное пользователем определение формата. Поддержка big-endian и little-endian. Чтение заголовка и TOC. Извлечение всех ресурсов. Генерация JSON-манифеста. Поддержка known compression codecs, начиная с none и zlib. Проверка CRC32 и известных хешей. Детерминированная перепаковка. Поддержка rebuild и in-place режимов. dry-run, verify, diff-toc. Анализ шрифтов: глифы, codepoints, метрики, UV, пересечения и границы. Отчёты JSON/CSV/text. Набор тестов на синтетических контейнерах. Нефункциональные требования не изменять входные файлы; не требовать доступа к защищённым системным компонентам; не содержать оригинальные игровые ассеты; давать понятные ошибки вместо молчаливой записи повреждённого файла; вести лог операций; обеспечивать воспроизводимость упаковки. Псевдокод парсера function parse_archive(path, format_config): file_size = get_file_size(path) stream = open_binary(path) raw_header = stream.read(MIN_HEADER_SIZE) magic = raw_header[0:4] if magic not in format_config.supported_magic: raise UnsupportedFormatError(magic) endian = detect_endianness(raw_header, format_config) header = read_header(stream, endian, format_config) validate_header(header, file_size) stream.seek(header.toc_offset) entries = [] for index in range(header.file_count): entry = read_toc_entry(stream, endian, format_config) entry.index = index validate_entry_range(entry, file_size) validate_entry_alignment(entry, header.alignment) entries.append(entry) names = read_name_table_if_present(stream, header, format_config) assign_names(entries, names) return Archive( path=path, file_size=file_size, header=header, entries=entries, endian=endian ) Псевдокод распаковщика function extract_archive(archive_path, output_dir): archive = parse_archive(archive_path) create_directory(output_dir) create_directory(output_dir / "files") create_directory(output_dir / "reports") manifest = create_manifest_from_archive(archive) suspicious_entries = [] stream = open_binary(archive_path) for entry in archive.entries: stream.seek(entry.offset) stored_data = stream.read(entry.stored_size) if length(stored_data) != entry.stored_size: suspicious_entries.append(entry, "truncated data") continue if entry.compression is known: unpacked_data = decompress(stored_data, entry.compression) else if entry.compression is none: unpacked_data = stored_data else: save_raw_data(entry, stored_data) suspicious_entries.append(entry, "unknown compression") continue if entry.unpacked_size exists and length(unpacked_data) != entry.unpacked_size: suspicious_entries.append(entry, "unpacked size mismatch") checksum_result = verify_checksum(entry, stored_data, unpacked_data) if checksum_result is invalid: suspicious_entries.append(entry, "checksum mismatch") output_name = create_safe_output_name(entry) write_binary(output_dir / "files" / output_name, unpacked_data) manifest.entries[entry.index].extracted_name = output_name manifest.entries[entry.index].verification = checksum_result write_json(output_dir / "manifest.json", manifest) write_json(output_dir / "reports" / "suspicious_entries.json", suspicious_entries) return manifest Псевдокод упаковщика function pack_archive(extracted_dir, output_path, mode): manifest = read_json(extracted_dir / "manifest.json") validate_manifest(manifest) prepared_entries = [] for entry_meta in manifest.entries in original index order: input_path = extracted_dir / "files" / entry_meta.extracted_name unpacked_data = read_binary(input_path) stored_data = compress( unpacked_data, method=entry_meta.compression, settings=entry_meta.compression_settings ) entry = copy_metadata(entry_meta) entry.unpacked_size = length(unpacked_data) entry.stored_size = length(stored_data) entry.checksum = calculate_checksum( entry_meta.checksum_type, stored_data, unpacked_data, entry_meta.checksum_scope ) prepared_entries.append((entry, stored_data)) if mode == "in-place": assign_original_offsets_with_capacity_checks(prepared_entries, manifest) else if mode == "rebuild": current_offset = manifest.header.data_offset for entry, stored_data in prepared_entries: current_offset = align_up(current_offset, entry.alignment) entry.offset = current_offset current_offset += length(stored_data) archive_size = current_offset else: raise InvalidModeError(mode) validate_no_overlap(prepared_entries) validate_all_alignments(prepared_entries) header = rebuild_header(manifest.header, prepared_entries, archive_size) toc = serialize_toc(prepared_entries, manifest.endianness) output = open_binary_for_write(output_path) write_header(output, header) write_toc(output, toc) write_name_table_if_needed(output, manifest) for entry, stored_data in prepared_entries: seek_or_pad_to(output, entry.offset) output.write(stored_data) write_padding_to_alignment(output, entry.alignment) close(output) result = parse_archive(output_path) verify_repacked_structure(result, prepared_entries) return result Поля, которые нужно исследовать в неизвестном формате Минимальный список: Magic/signature. Версия. Endianness. Размер заголовка. Число записей. Смещение TOC. Размер одной TOC-записи. Смещение таблицы имён. Смещение области данных. Offset каждой записи. Packed size. Unpacked size. Compression flags. Encryption flags — только для идентификации; не для обхода. CRC/hash и область, по которой они считаются. ID/хеш имени. Alignment. Padding pattern. Поле общего размера архива. Внешние ссылки на архив, индекс или ресурс. Внутренние offsets конкретных форматов — шрифт, атлас, локализация, субтитры. Версия текстурного формата, ширина, высота, mip levels, pixel format. Таблица Unicode/codepoint → glyph index. Метрики glyph table. Таблицы языков и string IDs. Формат subtitle cue и единицы таймингов. Вопросы для формата, который пока неизвестен Для точного анализа полезно получить не весь игровой архив, а безопасные технические сведения и небольшие обезличенные фрагменты: Первые 0x100—0x400 байт заголовка в hex-формате. Размер файла в байтах и hex. Hex-дамп предполагаемой TOC: 5—10 записей. Предполагаемый размер записи TOC: 16, 20, 24, 32 или 48 байт. Несколько известных offsets и соответствующие им размеры. Название/расширение контейнера: .psarc, .pak, .dat, .bin, .arc и т. п. Начало одного извлечённого ресурса: первые 0x40—0x100 байт. Сравнение оригинального и изменённого файла, если существует образец, созданный известным инструментом. Какие данные точно известны: имя ресурса, размер текстуры, число символов шрифта, ожидаемая строка. Скриншот или экспорт структуры из ImHex/010 Editor. Для шрифта: размер атласа, несколько известных символов, их предположительные координаты. Для субтитров: пример одной реплики, её таймкод в игре и соответствующий фрагмент файла. PS3 или Vita-версия, регион и версия игры: структуры ресурсов могут отличаться. Не нужно передавать защищённые исполняемые файлы, ключи, лицензионные данные или полный коммерческий архив. Безопасный план работ в 5 шагов Шаг 1. Инвентаризация Создать копии исходных файлов. Зафиксировать размеры и SHA-256 локально. Определить контейнеры, текстуры, шрифты, локализации и субтитры. Найти открытые ресурсные архивы, пригодные для анализа. Шаг 2. Read-only анализ Реализовать inspect, list, verify. Определить magic, endian, header, TOC, offsets, sizes и alignment. Создать отчёт о структуре без записи файлов. Шаг 3. Распаковка и воспроизводимая сборка без изменений Реализовать extract. Сохранить manifest. Реализовать pack. Достичь побайтового совпадения original == repacked для тестового контейнера без изменений. Шаг 4. Контролируемые изменения ресурсов Изменить один текстовый ресурс. Затем протестировать шрифт и один небольшой атлас. Проверить size, CRC, offsets, padding и загрузку на собственной тестовой среде. Использовать in-place режим, если внешние ссылки не изучены. Шаг 5. Специализация под перевод Реализовать анализ таблиц строк. Добавить font-report, проверку кириллицы и atlas-границ. Реализовать subtitle-report. Подготовить распространение в виде патча, манифеста или инструкций, а не полного набора оригинальных ресурсов. Итоговая рекомендация Практически лучший путь — начать не с «универсального перепаковщика PS3-игр», а с узкого исследовательского инструмента: inspect -> list -> extract -> manifest -> rebuild unchanged -> verify -> edit one resource Критическая контрольная точка: инструмент должен сначала уметь распаковать и собрать неизменённый архив так, чтобы результат был побайтово идентичен оригиналу либо, если формат намеренно недетерминирован, структурно и checksum-совместим. Только после этого разумно переходить к текстам, шрифтам, атласам, кириллице и субтитрам.   Предлагаю написать универсальный комбайн-софт, для распаковки-запаковки PS3 игр. С заменой латиницы на кириллицу, с подтверждением , если длина разная, автоматическим подбора похожего шрифта игры. Но нужны ответы на вопросы. Какой функционал обязательно должен быть. GUI или CLI оболочка и. т. д. Скорее всего получится переводчик именно под все игры Ratchet and Clank.
  • Изменения статусов

    • Perfect End Strange  »  SerGEAnt

      Привет, озвучку для Silent Hill 4: The Room выпустил энтузиаст под ником Perfect End Strange, а вы написали совсем другую студию, пожалуйста, исправьте эту оплошность
      · 0 ответов
    • Jimmi Hopkins  »  SerGEAnt

      я его уже открыл в свободный доступ, чтобы не потерялось среди новинок
      · 0 ответов
    • NekoNya  »  Onzi

      https://www.dropbox.com/scl/fi/4xncxr2tqy77vz4644q08/text_RU_FINAL.json?rlkey=xckxss3jkql4gjmc1ah6qjb5e&st=k5ql651f&dl=0 
       
      Вот, то что вышло. Извинюсь, что зря говорил, что помогу (
      · 2 ответа
    • serfly  »  SerGEAnt

      Доброго времени! Недавно столкнулся с проблемой автоперевода XUnity AutoTranslator BeplnEx iL2cc. Пару последних лет часто пользовался, теперь консольные команды виснут на стадии загрузки библиотек, хотя они есть там изначально. На GitHub есть подобные вопросы, но ни одного рабочего ответа я не нашел. А Вы что можете посоветовать?
      · 0 ответов
    • serfly  »  SamhainGhost

      Доброго времени. По локализации игры Wicked Seed. Шрифт размазан и в полях, другие можно попробовать? Например arialuni_sdf_2022? Я профан в этом, но интересно.
       
      · 0 ответов
  • Лучшие авторы


×