Не знал.

У меня тоже был такой карик.

там была не унчейнед мелоди

Унчайнед. Сам тогда удивился, когда при знакомой мелодии картинка не в тему была.

Более правильно говорить 83-in-1, поскольку 100-in-1 это достаточно кривой хак первой (даже атрибуты у некоторых тайловых карт не поправили, из-за чего текст отображается с артефактами).
Я сразу думал скрестить 83-in-1 и 300-in-1, сделать море повыше, как в 83-in-1, но тогда оставалось слишком мало места для фишки с облаками, поэтому оставил как есть. 83-in-1 я расковыряю позднее. Может, что интересного найду


На chief-net.ru есть два дампа с похожим сюжетом из Короля Льва (в одном Симба карабкается, в другом орёл какой-то машет крыльями). Там разная музыка в обоих случаях, и не Unchained Melody. То меню, что с орлом (Menu_8888888_in_1_[p]_[!]_by_Guyver.nes) сделано совсем криво, спрайты моргают и глючат, музыка примитивная. А вот то, что с Симбой, идут с кавером на знакомую песенку вроде Элтона Джона Правда, он тоже не цепляет. Хотя может быть, я придираюсь. На сколько я помню, картридж с Симбой идёт вместе с одноимённой китайской приставкой.

-- 13 ноя 2013, 01:14 --

Ради интереса бегло изучил код менюшек с сюжетами из короля льва. Основа у них явно общая, не понимаю, почему версия с орлом так глючит, может быть это кто-то хакал менюшку с Симбой, не имея нормальных навыков. Код в обработчиках RESET и NMI не имеет ничего общего с менюшками Unchained Melody. В версии с Симбой также есть отдельный обработчик IRQ (Unchained Melody обходится без его, в менюшке с орлом тоже нет, судя по всему, вся работа с вводом в основном потоке).

-- 13 ноя 2013, 01:37 --

Что интересно, у 83-in-1 код также достаточно сильно отличается от 300-in-1. Хотя родственная связь между ними очевидна. В случае 100-in-1 из оригинала забыли удалить скрытое тестовое меню по Select+Start и в тайловых картах там, где они добавили текст, они забыли исправить атрибуты групп тайлов, из-за чего некоторые буквы отображаются с неправильной палитрой. В 300-in-1 они забыли удалить кусочки верхних чёрных пальм (там буквально по несколько пикселей осталось). Но мне всё же кажется, что над 300-in-1 работал тот же разработчик — добавлено много хороших сцен, написана новая, более качественная (на мой взгляд) музыка. И код внутри — явно не хак, а нормальным образом написанная программа.

не помню

Итак, хочу поделиться вот ещё какой информацией. Известно, что в этой менюшке используется шрифт идентичный тому, что присутствует в Super Fighter III и всех его хаках Street Fighter III. Я искал ещё что-нибудь, что объединяет эти ромы, и нашёл:

Это табличные данные (в HEX), активно используются звуковым движком в Unchained Melody, в зависимости от нот данные берутся из этой таблицы и отсылаются в APU. Shiru говорит, что это скорее всего табличка нот, т.е. периодов для каждой ноты.

Однако, если поискать эту табличку по всей коллекции моих ROM-ов, выходит не такой уж и большой список:


Я искал при помощи Total Commander среди пары тысяч ромов по последовательности (HEX-последовательности длиннее 255 символов Total Commander не позволяет искать, не забудьте убрать перевод строки):

Основная часть этого списка — варианты меню Unchained Melody, его прообраз 83-in-1, Super/Street Fighter 3 со всеми хаками. Из лицензионных картриджей здесь Family BASIC (!), несколько игр от венгерского разработчика Novotrade и куча нелицензионных игр. Велика вероятность, что в этих дампах встречается именно эта табличка не по случайности. Нужно будет детальнее изучить.

Как искал, кстати? Ты сначала выделил этот конкретный блок хекса, затем уже сам этот блок стал искать Тоталом?
У меня просто была более общая задача - найти все блоки сходств между всеми ромами дабы определить многократно использующийся код или данные, специально для этого чуть переделал исходник LZMA на Дельфях (т.к. сишный не вкурил), и когда увидел огромное количество самых разных кусков, понял... понял, что всё не так просто, как казалось.

Ну я вручную искал сходства между 83-in-1, 300-in-1 и Super Fighter 3. Поскольку код 300-in-1 хорошо изучил, было видно, что может быть скопировано 1 в 1 — то и искал. Поиск в Тотале по HEX включается галочкой:


Программу, которая сама бы искала одинаковые или похожие фрагменты не знаю. Можно попробовать самому написать Хотя мне хватило бы поисковика HEX данных с масками, типа вот этот байт может быть любым, а вот этот байт должен быть +3 от предыдущего байта и т.д. Что-то вроде регулярок, но для двоичных данных. Хотя можно это всё и на обычных регулярках писать, там же есть escape-последовательности для произвольных кодов. Нужно будет попробовать эту функцию в Total Commander. Если работает хорошо, можно будет сигнатуры для кода оформлять для поиска, чтобы оно ещё игнорировало изменившиеся смещения от рома к рому.

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

А пробовал запускать эту утилитку на коллекции ромов для NES? Интересно, кто там у кого чего заимствовал

На NES ещё хуже оказалось. Помимо того, что фрагменты меньше, в них часто есть различия на пару байт или различия разных размеров, отчего куски сдвинуты друг относительно друга на пару байт. Из-за всего этого архиватор видит их как отдельные куски, т.к. умеет проводить только точное и последовательное сравнение (собственно, это есть суть LZ-архиватора, кроме того, такое жёсткое условие позволяет создать алгоритмы очень быстрого поиска).
На простом примере:
abcdefghjiklmnopqrstuvwxyz
abcdezghjiklmnopqrsqxuvwxyz
Во втором различии есть смещение.

Даже в NSF с одинаковыми движками такое есть. Скорей всего, это потому, что код писали руками на асме и вставляли отдельные команды куда надо, а не как на сеге, брали готовую неизменную процедуру и использовали её.

Проверку над полным ромсетом я не проводил. Во-первых, тот исходник, кажись, 32-битный (уже ограничение словаря до 128 МБ), плюс он почему-то автоматом ограничивает словарь до кода -d23, в общем, надо ковырять. Размер уникальных ромов NES этак 400 мб, сеги - больше гига. Особенность сеги позволяет довольно точно выделить код, но он занимает в среднем 10% от рома - т.е. больше 100 мб на всём ромсете.
Даже если запустить проверку над ограниченным набором ромов, получится большое число фрагментов, которые вручную ковырять глупо. В первую очередь будут видны куски между "одинаковыми" играми, такими как серия NBA Live, например. Такие тоже надо будет исключить из набора. Лучше отыскивать наиболее часто используемые фрагменты в разных играх (например, одна и та же процедура распаковки, см. ниже) и максимальные суммарные фрагменты из разрозненных кусков между разными играми (простой пример разрозненности дан выше), а это всё не очень простая задача. Кроме того, архиватор ищет ближайший одинаковый кусок максимального размера, но это не значит, что такого или похожего куска нет ещё где-то раньше, как раз в той игре, с которой мы сравниваем текущую игру.
У меня, если честно, нет времени на всё это.

Я задавался немного другим вопросом: насколько сходны разные ромы, т.е. как часто повторно использовали код и данные? И дополнительно: насколько велика польза от знания повторно используемого кода?
На примере архиватора RNC: по его заголовку легко отыскать игры, которые используют сжатие RNC, а главное - сами архивы. Итог: сжатие RNC использует порядка 50 игр, и объём сжатых данных около 20 мб. Это весьма неплохо. Сам факт использования RNC можно узнать по наличию в роме кода процедуры распаковки - он везде одинаковый (если точнее, есть две версии).
Логично, что:
- схожесть высокая в играх одной серии, особенно это касается спортивных
- схожесть выше в играх одних разработчиков
- процент схожести выше в коде, чем в данных

Что касается кода, то можно не только проводить тупое двоичное сравнение, а искать гомологии. Самый простой вариант гомологии: две команды различаются только числом, или адресом или регистром. Может же так быть, что одна и та же процедура написана с использованием разных регистров или разных абсолютных адресов, а порядок команд остаётся одним и тем же. Соответственно, для поиска гомологий можно в каждой команде заменить операнд на некий единый для этого вида команд. Например,

и

можно считать схожим кодом. Его единый вид может выглядеть так:

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

Я провёл такой эксперимент и посмотрел, насколько лучше сжимается код после приведения непрерывным (solid) сжатием относительно прерывного. Цифры немного условны могут различаться в зависимости от набора ромов, здесь предполагаются разные ромы без всяких спортивных серий и проч., в которых мало сходств.
Чистый код: 1.06 раз
Код с заменёнными адресами и числами на FFFFFF: 1.12 раз
Код ещё с заменёнными регистрами: 1.15 раз
Как видно, при повышении "гомологичности поиска" степень сжатия (а значит, и сходства) повышается, но не бесконечно.

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

Что-то наоффтопил я

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

-- 14 ноя 2013, 21:44 --


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


Это какой именно момент? Если считать по отстукивающему «ударнику», если ровно поделить всю мелодию между всеми сценами, то на каждую приходится по 5 ударов.

Совершенно верно меня понял. Только когда посчитал получилось 4.5 удара, т.е 8 по 5 ударов и 6 по 4. (1 удар - только запустил ром).
Видюшка прилагается. - обновил

Работает на железе просто прекрасно.

У меня ещё есть версия с более замедленной анимацией, без двойного мигание экрана, но там изменено поведение чаек. Они летают по всему экрану и генерятся заново, если улетают далеко за его пределы...

http://gfile.ru/a2dkL

И в чём принцип работы этого корруптора? Как я могу догадаться из названия, он рандомно портит ром, а пользователь пробует результаты, пока не понравятся? Судя по характеру глюков и тому, что, допустим, в предложенном роме зачем-то подменена даже нота в музыке, так и есть

-- 15 ноя 2013, 18:58 --


Отлично. Спасибо за тест. Фейдинг хоть заметен? Я его сделал максимально быстрым — не люблю медленные эффекты. Но в эмуляторе хорошо ощущается разница между обычным миганием и фейдингом.

Заранее извиняюсь за качество - был пьян и лень было искать штатив:

Добавил ролик

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

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

-- 16 ноя 2013, 15:15 --

Кстати, вот что интересно. В ROM-ах стоит флаг, что это NTSC. И при просмотре меню в PAL мне кажется, что какое-то всё слишком медленное и музыка не такая приятная. Но наверное это из-за того, что уже привык к NTSC режиму. Но на Денди это ведь было ближе к PAL, верно?

В Nestopia зачем-то сделано два варианта настроек по сути одного и того же. В главном меню доступна настройка Region: Auto (выбирается по заголовку из ROM-а), NTSC и PAL. А вот в настройках доступны ещё варианты (Favored System): NES NTSC, NES PAL, Dendy, Famicom. То есть в итоге можно выбрать систему NES PAL, но регион NTSC и т.д. — не ясно, что получается в итоге, в общем какая-то путаница или я чего-то не понимаю.