Джордж Мартин: «Я консультировал разработчиков одной японской игры»

В конце марта в сети прошел слух, якобы в разработке следующего проекта от FromSoftware принимает участие Джордж Мартин, известный своим циклом «Песни Льда и Огня». Тогда утверждалось, что писатель выступает в качестве сценариста, а в игре будет несколько королевств.

Многие не поверили в слух, поскольку он звучал слишком хорошо. Однако похоже, что он частично правдив.

20 мая в своём блоге Мартин опубликовал пост, в котором без контекста заявил, что «консультировал разработчиков одной японской игры».

Источник издания Gematsu подтвердил, что речь идёт действительно об игре FromSoftware от Миядзаки, которую представят на E3 2019.

Это игра с открытым миром и возможностью ездить на лошади, а аббревиатура названия — GR. Разработка ведётся уже три года, однако с учётом концепции, этого можно быть недостаточно для релиза в 2019-м.

О том, что FromSoftware покажет свою следующую игру на E3 2019, также говорил другой доверенный инсайдер, который ранее сообщал точную информацию о Sekiro до её анонса. По его словам, игра будет мультиплатформенной и в сеттинге тёмного фэнтези.

сурс: https://dtf.ru/gameindustry/51077-dzhordzh-martin-ya-konsultiroval-razrabotchikov-odnoy-yaponskoy-igry

Есть один мульт.

ПОСТ НЕНАВИСТИ

Epic Store выкупили права на эксклюзивный показ третьего сезона OreGairu только на своей площадке.

А сейчас за такое авторов сериала бы повесили на рее, разорвали на части и скормили собакам.

В общем пока я тут подгорал и https://twitter.com/deeppomf начал подтверждать мои самые страшные опасения, а онлайн клиент, вместо оффлайна. http://joyreactor.cc/post/3881919#comment18116150 этот комментарий дал мне силы на изучение темы. На самом деле все нужные алгоритмы придуманы до меня, что нужно, так это собрать большой объем данных, может быть в будущем как-то модернизировать модель как это сделал товарищ Deeppomf(на самом деле возможно он нихуя и не сделал, так как сам код сети он не выкладывал, сказал только, что она базируется на deepfill).
Глаза боятся, а руки делают. Начал с гугления, конкретно мне интересна тема расцензуривания мозаики, так-как в целом с полосочками нормально справляется и deepcreampy, нагуглил одну интересную статейку, правда на китайском: https://zhuanlan.zhihu.com/p/27199954
Благодаря ей я определился какую модель использовать, а именно pix2pix. По сравнению с тем же Deeppomf у меня в отличие от него нет для обучения 150 гигов. Пришлось собирать данные вручную, а именно exhentai в руки, ищем по тегу decensored в разделе игровых cg. Находим нужную новеллу, проверяем наличие зацензуренной версии, качаем обе.
По первой я раздуплялся как лучше скармливать данные, ебашил фулл изображения и разумеется сеть меня посылала нахуй, все же нужно было подсовывать только нужные места. А именно берем гимп, открываем расцензуренную пикчу, затем открываем как слой зацензуренную, выделение в 256 пикселей и обрезание по выделению. Потом склеивать обе части. Тогда сеть начала кушать и давать результаты.
ОСТОРОЖНО NSFW: https://cdn.discordapp.com/attachments/389502656684621837/566500510794907649/SPOILER_unknown.png
Пока по датасету не густо, это результаты тренировки на 76 пикчах, которые я вчера часа за 4 нарезал. В принципе все не так уж и плохо, но я ебанусь вручную так данные собирать. Судя по всему нужно будет копать в сторону opencv и писать детектор мозаики, что бы автоматом вырезать нужные части и хоть как-то сэкономить время по сбору.
Всем спасибо за внимания, продолжаю заниматься аутизмом.

Делаем собственный hcode к новелле.

Собственно почему бы и нет. В русскоязычном сегменте гайдов никаких нет, в англоязычном все довольно-таки старенькие. Поэтому запилю свой гайд как делать хук код к новелле которую вы собирались почитать, а текст нихуя не вытаскивается.

Во первых нам нужен инструментарий.

1. Cheat Engine как дебагер, удобный, мало весит, имеет вполне себе юзерфрендли интерфейс. Скачать можно всегда с офф сайта https://www.cheatengine.org/

2. Textractor — собственно достойная замена ITH и ITHVNR, хотя если точнее продолжение. Скачать можно на странице релизов с гитхаба https://github.com/Artikash/Textractor/releases

3. Наша подопытная новелла. Я взял тупа первую новеллу к которой просили хук на хонге. Скачать эту новеллу можно отсюда https://sukebei.nyaa.si/view/2640189

Собственно поехали.

Я скачал данную новеллу и открыл текстрактор. Жмакаем аттач то гейм и выбираем процесс с нашей игрой. Автоматом подхватились нужные треды с обрывками текста.

В данном случае это GetGlyphOutlineA, как видно текст дают нам не полностью а только его часть. Данный косяк мы и будем исправлять.

Прежде всего следует поискать существует ли в памяти нужная строка в неизменном виде.

Жмакаем кнопку add hook и в открывшимся окне вводим S[впечатываем сюда нужную строку]

Жмем ок и чуточку ждем. В консоли должны появится записи, что добавились новые юзерхуки, проверяем их.

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

Переходим к самому интересному и веселому открываем cheat engine.

Подрубаемся деббагером к нашей новелле. Выбираем процесс и жмакаем Attach debugger to process.

После того как подключились к процессу необходимо перейти на нужный адресс в окне memory view. 

В красной рамке собственно располагается окно с ассемблерными инструкциями. Жмем по нему правой кнопкой мышки и нажимаем Go to address.

Нужный нам адресс можно получить в окне textractora треда который не полностью захватывает текст.

Красным подчеркиванием выделил где находится данный адрес. Вводим его в окошко Goto Adress, первые две цифры не трогаем, мы должны поменять только последние 6.

Собственно в окне memory view должна выделится нужная позиция.

Конкретно здесь выделение должно быть в инструкции адрес который я подчеркнул красным. Кстати в окне memory view адрес пишется с учетом оффсета от реального адреса, а не того который выделили в памяти. Поэтому реальный адрес инструкции 6F298 относительно начала файла экзешника нашей новеллы, в то время как в памяти нашего пк адрес 0046F298. Ну это так чисто техническая инфа, я хуй знает зачем это пишу.

Далее мы должны поставить breakpoint, выделяем нужный адрес и правой кнопкой мыши установить breakpoint либо же просто жмем ф5.

Итак мы выделили нужный адрес и поставили брикпоинт, когда он ставится, до инструкция выделяется зеленым цветом.

Ткнем в диалог новеллы и она должна зависнуть, а интерфейс memory viewera слегка изменится. Давайте пройдемся по нему поподробнее.

Собственно 1 это окно просмотра адреса памяти в хекс режиме. Полезно посмотреть что скрывается в различных адресах. Нихуя не буду углубляться в что такое поинтеры и с чем их едят. Я вообще когда начинал ебашил все методом научного тыка и нихуя не знал.

2. Окно с нашим стеком, что такое стек я тоже нихуя не буду писать, во всяком случае сейчас. Окно это дюже полезное и позже объясню почему.

3. Регистры, собственно в 32битных программах есть регистры EAX, EBX, ECX, EDX, ESI, EDI, EBP и ESP подробнее про них вы можете прочитать не у меня, так-как по большему счету я тоже мало знаю об этом, короче считайте регистры что-то вроде переменных. Про флаги и сегменты регистров я тем более нихуя не знаю, так-как их не использую в принципе.

4. Окно с ассемблерными инструкциями.

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

Собственно наше окно с регистрами горит красным и если мы пощелкаем ф9, то сможем увидеть как некоторые показатели в регистрах меняются. Мы знаем, что по адресу 6F292 вызывается инструкция GDI32.GetGlyphOutlineA собственно туда отправляются наши японские символы в количестве одной штуки. Я кстати не читал документацию но чисто на эмпирическом уровне думаю, что данное апи выводит на экран текст, хотя если бы было так, оно выводило не весь текст, хуй с ним, может люди умнее меня скажут нахуй она нужна. Опять я что-то отвлекся.

Конкретно в данном случае можно сразу запалить 2 байта 

В регистре ESI 82B1 я уже столько раз делал хук коды, что точно знаю, что все японские символы в SJIS кодировке состоят из двух байтов и первый байт у них начинается с 80. Есть очень полезный сайт который позволит хекс коды перевести в читабельный текст http://freaka.freehostia.com/charset.php

Благодаря этому сайту мы понимаем, что 82В1 = こ. Да так и есть, каждый раз при вызове ф9 мы продолжаем выполнение программы и каждый раз когда срабатывает брикпойнт регистр ESI меняется показывая нам новую букву. Хорошо с этим мы разобрались. Но как же выловить весь текст полностью? Ну в данном случае придется окунуться в наш стек, что бы найти истину.

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

Нам нужно поставить брикпоинт прямо перед выполнением функции в которой происходит вызов в GDI32.

В нашем случае это адрес 72CE9 чуть ниже мы можем увидеть функцию call и еще на один ниже наш адрес возврата из той функции 72CF0. Поставим брикпойнт и немного погоняем ф9, смотрим есть ли где-нибудь наш текст. Ах да, поставим full stack в окне стека. Если мы дважды щелкнем кнопкой мыши на первую позицию в стеке после того как нажмем ф9, то в окне хекс отображения сможем увидить два байта нашей буквы в sjis кодировке. Значит мы сделали все правильно и буква появляется еще выше по выполнению данной функции, если бы мы нигде не смогли отыскать нашу букву, то алгоритм работы слегка изменился и нам пришлось искать место где она появляется в функции где вызывается GDI32, но этого не произошло и продолжаем искать дальше.

В данный момент у нас должно быть активно два брикпоинта при нажатии Ctrl+b мы увидим их адреса, либо же можно нажать мышкой сверху view -> breakpointlist. Наша задача понять они выполняются каждый одинаково, то есть сначала первый потом второй и если да, то это место для хука не подходит, так-как мы знаем что у нас проебаны буквы.

Жмакаем ф9 и видим, что они выполняются последовательно, значит ищем дальше. Мне чуйка сразу подсказала, что текст формируется именно в этой функции и я решил пройтись по ней с самого начала. Брекпоинт по адресу 0046F292 можно нахрен удалять. Что бы попасть в начало функции жмакаем правой кнопкой мыши на окне с инструкциями выбираем select current function, наш отшвырнет на адрес 72A2D, поставим здесь брикпойнт и пощелкаем ф9.

Ага, вот тут после выполнение команды в адресе 72A88 в регистре EAX появилось кое-что интересное. А именно появляется первый байт нашей буквы, мы ведь помним, что первый байт всех японских символов начинаются с 80. Отлично идем дальше.

А вот наклюнулся и второй байт в регистре ECX, он появился после выполнения команды в адресе 72A92. За ним идут две операции and, где по сути избавляются от минуса, и мы применяем побайтовый сдвиг влево на 8 у регистра EAX. Вот оно, уже рядом.

Собственно вот и оно. После инструкции в адресе 72AA2 наши два байта объединились и стали единым целым. В адресе 72AA4 можно поставить брикпойнт и пожамкать ф9, что бы убедится, что все буквы появляются именно здесь. Как только мы в этом убедились. Жмем Ctrl+B и удаляем все брекпойнты, они нам больше не понадобятся. Самое время запилить наш хук.

Цепляться будем ка адресу 72AA4 который идет сразу после того как наши два байта объединяются.

Откроем textractor подрубимся к экзешнику с нашей игрой, если вы вдруг его закрыли, если не закрывали, то он должен быть уже заатачен к процессу игры. жмем добавить хук код add hook

Ну и собственно вбиваем наш хук. Если у вас экзешник из иероглифов, имя желательно полностью скопировать. Как составлять хуки тут есть целая памятка. /H собственно с этого начинается любой хук код. A - берет два байта в кодировке SJIS little endian, B следует использовать когда байты повернуты наоборот. То есть в данном примере у нас 8179 - это А, а если бы было 7981, то нужно было бы в писать в хук B. Префикс N, блядь, я знаю, что это значит но по умному хуй знает как описать. Короче, суть. Если не писать N, то будет дополнительно учитываться регистер ESI вроде бы, точно не помню и если он постоянный то все будет ок, но если вдруг каждый вызов он будет меняться, то вы получите кучу всяких потоков, поэтому использовать его нужно с умом. Собственно собака, потом адрес куда мы будем хукаться, напомню этот адрес идет сразу после того как мы получили наши цельные два байта. Двоеточие и имя экзешника полностью. Жмем окей и вуаля. Хук работает, а мы великолепны.