Разработка и ромхакинг > Ромхакинг и программирование
конвертация аудио сэмплов и планы на треккер
<< < (5/6) > >>
Sharpnull:

--- Цитата: SeregaZ от 08 Апрель 2020, 05:26:32 ---я так понимаю мне второй вариант из архива нужен?
--- Конец цитаты ---
Да.
Забыл сказать, что это исправление с битами тоже "неправильное". Если движок GEMS пропускает 0xFF в железо, в нашем случае в эмуляцию звука, то так и должно быть и значит ошибка где-то ещё.

Добавлено позже:

--- Цитата: SeregaZ от 08 Апрель 2020, 05:26:32 ---а нет, чото он правил. смотрю на гитхабе какие-то обновки.
--- Конец цитаты ---
Да... Теперь нет второй проверки на Gems 2.8, но изменилась первая. Число 0x200000 теперь стало 0x80000 как в ASM. Jump для VGM.
Сэмплы исправил, увеличил размеры переменных, но не добавил смещение указателя DstAddr из-за которого был треск.
Исправил UINT16 ChnMask; о котором я говорил, но он всё равно не влиял.
И ещё есть новые фиксы.

Придётся проверять.

Добавлено позже:
Так. Он наверно не исправил, потому сам не проверил.
* DstAddr += SmplLeft; не добавил, без которого треск, мы "арию" в Nightmare Circus - The Jester отдельно слышали.
* UINT8 LoopID = 0; из loader.c не исправлен (для VGM).
* Зря он убрал вторую проверку:

--- Код: --- DoGems28 = Gems28Mode;
if (stseqx[0] > 1) // [extra code to detect GEMS 2.8]
{
if (stseqx[3] <= 1 && stseqx[6] <= 1)
DoGems28 = 0x01;
}
--- Конец кода ---
В кривом (наверно) банке Nightmare Circus теперь все треки неправильные, потому что первая проверка срабатывает один раз и она не сработала, но дополнение к ней помогло определить в вырезанной дорожке 020, о которой говорил недавно.
* Сэмплы (DAC), которые не останавливались из-за CLIPLOOP(), не исправил, хотя там по ASM-коду понятно.
SeregaZ:
но главная интрига - это с той переменной 4.4?
Sharpnull:
SeregaZ, проблема осталась как и со 2-м грязным фиксом - снятием 7-го бита. Я проверил, скомпилировав его код с github'а, на всякий случай.
Интересно, что код там лежит с нормализованным переносом (LF, а не CRLF как в Windows), из-за этого я не смог сделать апгрейд проекта с VC++6 до VS2019. Это если скачивать с github, а если клонировать проект, то преобразование идёт до CRLF.
Интересно, что новые коммиты теперь датируются не 7 апреля, а 4 апреля. Получается он ещё тогда исправил, но на github добавил только вчера.
SeregaZ:
ну вчера еще не было. когда я смотрел - висело 11 коммитов. а вот когда седня зашел - уже смотрю 13. а даты да. странные. может создал, но на первое время было приватным? я сам только только на гитхабе зарегистрировался :) довольныыыыый... надеюсь оттуда файл со списком ссылок на гемс архивы брать при запросе из редактора. чтобы не вшивать в ехешку этот список намертво. хотя он там вшит будет - но сначала проверит есть ли доступ к онлайн списку. если нет - покажет вшитый.

а насчет грязного фикса - на том сайте с документацией по ym2612 указано что 7 бит в любом случае illegal. да и на слух вроде нормально - звучит так-же, как и без него, но до тарахтения. мне нравится :)
Sharpnull:

--- Цитата: SeregaZ от 08 Апрель 2020, 14:48:57 ---может создал, но на первое время было приватным?
--- Конец цитаты ---
Скорее локально (на компьютере) сделал коммит, push на github 7 апреля (https://api.github.com/repos/ValleyBell/GEMSPlay - pushed_at: "2020-04-07T21:48:08Z", это по UTC).
--- Цитата: SeregaZ от 08 Апрель 2020, 14:48:57 ---на том сайте с документацией по ym2612 указано что 7 бит в любом случае illegal
--- Конец цитаты ---
Дело в том, как железо реагирует, а не что формально.
Если всё нормально до шума, и нужно просто его обрезать, то возможно дело в остановке трека, которого не происходит из-за этого бита.
Sharpnull:
Обновил github и сборку: https://github.com/infval/GEMSPlay/releases.
* Применил исправления от Valley Bell за исключением второй проверки на GEMS 2.8.
* Добавил функцию void gemsplay_set_gems28mode(int enabled);, чтобы включать GEMS 2.8 режим. Нужно вызывать перед gemsplay_play(), если передать 1 (или != 0 значение) - включение 2.8, если 0 - отключение. Но, так как я оставил вторую проверку, если программа определить режим как 2.8, то установка 0 или первое определение в gemsplay_init() не повлияют. По-хорошему нужно убрать вторую проверку, чтобы точно форсировать нужный режим, тогда придётся и в GEMSPlay плеер добавить такую команду.
* Добавил два "грязных" исправления с Comix Zone и Nightmare Circus (до этого в код не добавлял на github). Обернул их в макрос препроцессора #ifndef DISABLE_GEMSPLAY_DIRTY_FIXES, чтобы выделить и можно отключить во время компиляции, если добавить в настройки проекта.
Когда пытался разобраться в писке/шуме после конца трека, то попробовал передавать тишину после окончания трека, потому что там постоянно вызывается эмуляция YM2612, даже после завершения трека. Оказалось, что в треках только с DAC сэмплами, а точнее в какой-то игре NBA где только голос человека, определение остановки срабатывает раньше, при этом трек играет и пауза работает после неправильного определения конца, это влияет на автоматическое переключение треков (вкл. - клавиша 'A'). В принципе, если добавить ещё проверки, то можно определять конец точнее. Для вашей программы это не важно, так как вам не нужно знать конец.
SeregaZ:
наконец он ответил:

--- Код: ---I finally found some time and had a look at all the bug reports.
I also started a GitHub repository that contains the current version of the GEMSPlay source code. (There is no EXE release for now - might do one at a later date.)

DAC looping is fixed now (based on the original Z80 assembly source - had it already fixed when you posted a link to infval's repo)
Your "Select Algorithm" is done by doing bit checks on the CARRIERS variable. In Z80 ASM, this is faster then checking for 0..3, 4, 5..6 and 7 separately.
VGMs are written into a folder called "dumps" that must be in the current directory.
I just made a fix in the Git repo, so that the folder is created automatically when enabling VGM logging.
The problem with Comix Zone is unfortunately an emulation related. That particular instrument requires the YM2612 to be emulated at its native sample rate, 53267 Hz.
However due to the way GEMSPlay is written, it can only be emulated at 44100 Hz. (This is also what Gens usually does.)
Thus, the bug won't go away unless GEMSPlay gets a major rewrite regarding audio processing.
Bit 7 from the value for register $27 will be kept for now, because GEMSPlay aims at an accurate reproduction of the original GEMS sound engine and this bug is present in the original as well.
Thanks for posting infval's GEMSPlay repo, btw. It made me notice a few additional bugs left.
Feel free to invite him to the vgmrips IRC, in case he has questions about GEMSPlay or other GEMS related stuff.

About bugs in general:
Every software has bugs. The reason for such obvious bugs in GEMSPlay is just the lack of testing.
I lost interest in GEMS music shortly after finishing GEMSPlay. I went on to write SMPSPlay instead.
And apparently also nobody used GEMSPlay between 2013 and 2019, so the bugs weren't noticed until now.
--- Конец кода ---

теперь у него коммитов на один больше.

по поводу неверного окончания проигрывания - раньше я использовал длл для эмуляции чипа ym2612 - там проигрывание сэмплов было реализовано отдельной самодельной функцией. и в этой функции была проверка на тишину так сказать. если сэмпл играет, но в нем идет в течении пол секунды, наверное, тишина - $80 $80 $80 $80 $80 (или 0 0 0 0 для сэмплов другого формата)... то проигрывание отрубалось, даже не доиграв до конца. может быть здесь подобная система?

Добавлено позже:
ааааааа... перечитал еще раз более внимательно :) определение остановки работает верно. там дело в другом. в коде "мелодии" используется длительность ноты, сиречь сэмпла. но это больше сделано для сохранения темпа так сказать то есть чтобы мелодия не сбилась, потому что сэмпл не слушается параметра duration, а играет пока не проиграет.
получается что-то типа такого:
delay 5 ; пауза между событиями
duration 5 ; длительность ноты, но в данном случае сэмпла
sample (скажем он играл бы по времени как duration 10)
eos ; конец дорожки
то код определения конца трека сработал бы по времени после достижения duration 5, но сэмпл продолжил бы играть пока не доиграет.
Sharpnull:
На счёт его коммита: теперь он исправил то, что было у меня. LoopID для VGM я исправил неверно, начальное значение там 0xFF и оно устанавливается каждый трек заново. Из нового: FMWrite(CurBnk & 0x04, 0x22, ChnPat[0]); -> FMWrite(CurBnk & ~0x03, 0x22, ChnPat[0]);, значит больше каких-то банков будет поддерживаться. Про создание папки dumps вы знаете.
Он забыл добавить заголовочные файлы #include <direct.h> в main.c для _mkdir() и #include <string.h> в GemsPlay.c для memset(). Всё компилируется, но компилятор пишет предупреждения. В C++ наверно была бы ошибка, потому что в C функция без объявления по умолчанию int func() и допускается передавать аргументы в функцию с пустыми параметрами, из-за этого для C приходиться писать void func1(void), а не void func1(), чтобы компилятор сообщил об ошибке, если случайно переданы аргументы.

Я обновил код и сборку. Код практически совпадает, за исключением 2 грязных исправлений и второй проверки на GEMS 2.8, которая неизвестно даёт ли ложноположительный результат (тогда нужно убрать обязательно).


--- Цитата: SeregaZ от 10 Апрель 2020, 01:08:53 ---The problem with Comix Zone is unfortunately an emulation related. That particular instrument requires the YM2612 to be emulated at its native sample rate, 53267 Hz.
However due to the way GEMSPlay is written, it can only be emulated at 44100 Hz. (This is also what Gens usually does.)
Thus, the bug won't go away unless GEMSPlay gets a major rewrite regarding audio processing.
--- Конец цитаты ---
Это похоже не так, раз я одним делением исправил :) Точнее, чтобы переписать код под эмуляцию от MAME потребуется major rewrite. Этот коммит он не видел, очевидно.
Так и думал, что связано с частотой (53267 Гц), потому что в MAME rate передаётся как clock() / 72, а здесь 44100. Где clock() должен быть 7670454 (частота YM2612 NTSC), только вот это 7670454 / 72 == 106534, а 7670454 / 144 == 53267. Магическое число 144 встречалось в fm2612.c, как раз 144/32 == 4.5 (я исправил 4.4 на 4.5 в коде), только я не знаю почему 32.
Можете ему написать, чтобы посмотрел моё исправление в fm2612.c:

--- Код: ---OPN->fn_max = (UINT32)( (double)0x20000 * freqbase * (1<<(FREQ_SH-10)) );
--- Конец кода ---
на

--- Код: ---OPN->fn_max = (UINT32)( (double)0x20000 * freqbase * (1<<(FREQ_SH-10)) / 4.5);
--- Конец кода ---
В Genesis Plus GX код YM2612 основан на MAME, но у GP GX текущий код чище, без множителей частоты, так что наверно в другом месте идёт преобразование в конечную частоту. Но я мало разбирался и всё равно не пойму.
--- Цитата: SeregaZ от 10 Апрель 2020, 01:08:53 ---Bit 7 from the value for register $27 will be kept for now, because GEMSPlay aims at an accurate reproduction of the original GEMS sound engine and this bug is present in the original as well.
--- Конец цитаты ---
Поэтому я писал, что это "грязное исправление".
SeregaZ:

--- Цитата: Sharpnull от 10 Апрель 2020, 04:20:48 ---Поэтому я писал, что это "грязное исправление".
--- Конец цитаты ---
пофиг, главное что работает без явных глюков. да, может что-то где-то немного не верно звучит... но по сравнению с моими глючными самопальными художествами на эту тему - текущая версия dll просто космос.

я еще посмотрю в логах что GEMS в эмуляторе в этот регистр шлет. думаю может все-таки обрезает $FF из инструмента до $7F. плюс еще тестировал собранный ром в Gens и Fusion - в Gems играет как-то дважды чтоль. то есть два раза звук появляется, а во Fusion - только один. у нас как во Fusion - один :) полагаю что это правильно.

Добавлено позже:
значение так и остается $FF. я думал гемс его порежет. смотрел в VGM записи во Fusion. значит обрезки нет, и как-то эмуляторный чип реагирует по другому на этот 7 бит.
Sharpnull:

--- Цитата: SeregaZ от 10 Апрель 2020, 04:42:26 ---как-то эмуляторный чип реагирует по другому на этот 7 бит.
--- Конец цитаты ---
Меня тоже смущало, там проверка на 7 бит (0x80) встречается. Только сейчас поискал информацию "CSM mode auto key on ym2612" :) Например:

--- Цитата ---CSM (illegal Mode)
This mode is will also switch the YM2612 in special mode
It was officially called “Illegal Mode” because it seems SEGA did not find any use of this or developers found it too hard to program...
CSM stands for COMPOSITE SINE WAVE MODELING aka early speech synthesis system
--- Конец цитаты ---
Интересно, как много игр с GEMS использовали CSM.
--------
Можно убирать 7-й бит, только если передаётся 0xFF или если установлены 7-й и 6-й биты одновременно, потому что так обычно не ставят, как я понял.
SeregaZ:
не не. я написал что как-то по другому реагирует - я не имел ввиду что реально звук что-то как-то изменился. просто написал что реагирует по другому, типа жужжит, а эмуляторный не жужжит. это жжж не спроста. :) я на еще одном форуме тему создал с этим битом и скопировал эту ремарку про то, что сега типа не знала как это дело использовать и посему предала анафеме - illegal, но может там чо подскажут. причем жужжание меняет частоту. если запускать 019 жужжание одно, если 020 - другое. напоминает мне использование 4 - шумого канала для PSG. там 7 типов шумов и два по моему могут изменять частоту жужжания, а остальные одинаковые.

посему меня устраивает что без 7 бита не жжужит. пока не появилось какой-то новой архиважной информации по сему вопросу - предлагаю так и оставить :) а так по идее я могу сделать парсер всех FM инструментов и перепроверку именно этого параметра у всех игр, что у меня распакованы с целью выяснения где еще подобное используется.
SeregaZ:
он ответил, что 7 бит должен быть раз он есть. it just gets hidden by Kega Fusion in some way. я голосую фиг с ним :) без 7 бита хорошо - ну и хорошо.

по поводу 4.5 - говорит может где-то вылезти боком. тоже предлагаю забить. раз играет более менее близко к оригиналу - уже хорошо.

у меня теперь другой вопрос - можно ли читать указатель? в момент сборки банков GEMS в памяти - у меня происходит парсинг всего кода песни. то есть я там могу подсчитать итоговую длину песни, то есть общее количество delay. и типа если в песне нет loop 127 - то есть такая песня будет звучать бесконечно - определить её длительность. то есть лимит прогресс бара таким образом можно выставить на окне программы - но можно ли как-то получать указатель? или может не указатель, а количество тиков, то есть сколько единиц delay прошло за время звучания в данный момент? то есть таким образом сделать прогресс бар с отображением сколько проигралось.
Sharpnull:
Вы могли просто подсчитывать время от начала запуска проигрывания, если только есть проблемы с преобразованием длительности в секунды. Добавил int gemsplay_get_elapsed_time(void);, возвращает переменную PlayingTimer в кадрах (60 в секунде), которая используется для вывода времени в консоли.
Интересно, что в коде есть LoopStartSignal() и LoopEndSignal() для подсчёта повторов и даже их вывод, только эти функции не используются и повторы никогда не выведутся.
--------
Треки только с DAC сэмплами будут заканчиваться раньше, как я уже говорил.
SeregaZ:
эээ неее... не пойдет :) рассказываю: в последовательности, то есть в мелодии, может быть переменная темп в любом месте. и её может быть несколько в течении трека. получается формула по расчету будет более сложная. типа от 0 до 124 делея темп был 100bpm, от 125 то 342 темп 120, а конце 150 bpm. например в Dune финальная песня, когда идет покраска планеты в тот цвет дома, за который играл игрок и победил в последней миссии. там изменяющийся темп. хотя это конечно больше исключение из правил. в основном темп в количестве 1 штука на весь трек в самом начале. а спецэффекты с флагом sfx всегда 150bpm и он не изменяются. а так с формулой я в старой версии проигрывателя что-то мудрил мудрил... вывел какой-то там коэфциент 16.6666 сколько-то... но он не точный, так как у меня миллисекунды в моем языке программирования. то есть 16.66666 миллисекунд, а чтоб было точнее нужно микросекунды 16 тыщ 666 микросекунд. поэтому если отслеживание тиков было бы в коде, который в цикле крутится внутри dll - было бы гораздо точнее, и не зависело бы от изменения темпа. а второй момент - помимо счетчика "сколько уже проиграло" - хотелось бы примерную логику понять отслеживания этого указателя "где играть" в коде, чтобы можно было понять можно ли им управлять - я в том плане, чтобы можно было передвигать ползунок прогресс бара и перематывать трек двигая мышкой. понятно что у дорожек может быть разная длительность без лупов, и каждая дорожка должна иметь свой указатель (или может быть счетчик точнее). ну это так... в порядке бреда. там будет очень сложно предусмотреть все нюансы.

Добавлено позже:

--- Цитата: Sharpnull от 10 Апрель 2020, 15:04:07 ---Треки только с DAC сэмплами будут заканчиваться раньше, как я уже говорил.
--- Конец цитаты ---
тут просто. (размер сэмпла - SKIP - END) / частота сэмпла = реальное время проигрывания. в случае если нет loop. если есть, то тогда получается оно будет слушаться duration и пока duration еще есть - крутить loop. впрочем если duration уже кончилось, а сам сэмпл хоть и имеет loop, но еще не проиграл первую часть до loop - видимо все-таки доиграет эту первую часть до конца, просто не будет делать loop.

Добавлено позже:
проверка тикнул ли 1 delay происходит тут?

--- Код: ---static void CHECKTICK(void)
--- Конец кода ---

то есть я о чем:

--- Код: ---глобальная переменная скажем DelayCounter. 32 бита наверное.

в CHECKTICK(void) : DelayCounter + 1
хотя нет. нужна проверка а не лупнутая ли на 127 эта песня? иначе бесконечность превысит лимит переменной даже 32 битную.
просто час если будет играть скажем один трек. переменную луп посылать в библиотеку из вне.
if GEMSLoop = 0
  DelayCounter + 1
endif


в Gems play : DelayCounter = 0


функция GetDelayCounter()
ProcedureReturn DelayCounter
то есть при посылании в библиотеку этой функции - возвращает текущий таймер в единицах Delay, что прошло после старта.

--- Конец кода ---

вобщем я тут насумбурил :) воспаленная фантазия разыгралась... делать не нужно, просто общий замысел о прогресс баре для проигрывания и замысел на тему перемотки трека путем елозивания мышкой по прогресс бару.
SeregaZ:
по поводу тарахтения один товарищ подал интересную мыль - по окончании проигрывания брать и отсылать в этот регистр 0х27 значение с нулем. в теории прокатит - отрубит этот спецрежим так сказать. но на практике может быть доля секунды щелчка в конце проигрывания именно этого случая. в других по идее щелчка не будет. хотя еще не известно как это повлияет на звук соник танка. ведь по идее окончание проигрывания - это не совсем окончание. типа если пауза между событиями - delay и длительность звучания ноты - duration - одинаковые и сразу после этой ноты трек заканчивается, то нота как-бы оборвется не доиграв до конца, то есть фаза Relise Rate не сработает. потому что она начинает работу после окончания звучания ноты. то есть этот релиз рейт - параметр, так сказать, затухания после того, как клавиша синтезатора была отпущена.
Sharpnull:
Я уже говорил, можно снимать биты (лучше просто 0x00), если оба бита установлены (маска 0xC0) при передаче. Тогда шум будет только когда кто-то реально используется CSM режим, а таких должно быть мало.

--- Цитата: SeregaZ от 11 Апрель 2020, 04:28:19 ---хотя еще не известно как это повлияет на звук соник танка.
--- Конец цитаты ---
А там тоже используется 7-й бит или 0xFF? Узнали как часто встречается реальное использование CSM режима, а не 0xFF, и сколько неправильных 0xFF (0xC0)? Хотя бы примерно, кроме Nightmare Circus.

Про тики, перемотку не понял. Вы наверно хотите полноценный редактор GEMS сделать. Если бы я делал графический плеер GEMS на основе этого (не редактор), то для промотки (seeking) загружал трек заново и в цикле пропускал нужное количество кадров:

--- Код: --- for (int i = 0; i < frames_skip; i++) {
VBLINT();
gems_loop();
vgm_update();
for (loop = 0; loop < rateDACUpdate; loop++)
{
DACME();
}
PlayingTimer ++;
}
--- Конец кода ---
Это работает более менее быстро (не больше секунды для 2 минут перемотки), но возможно не точно из-за отсутствия ym2612_stream_update(), который заполняет буфер, с ним медленнее.
Для выяснения длины трека просто проматывал бы до конца, при этом пришлось бы учитывать зацикливание.
Кстати, заметил, что один и тот же короткий трек играл по-разному при разных запусках. Может там проблемы с потоком (с ними всегда проблемы, если не быть крайне осторожным и опытным), который отдельно играет музыку, или где-то используется неинициализированная память.
По-хорошему, для такого рода библиотеки должна быть возможность самому вызывать sound_update() с передачей буфера, тогда забота по воспроизведения ложится на пользователя библиотеки, зато можно лучше контролировать процесса.
SeregaZ:
ошибка проигрывания чуть по разному может заключается в ошибке музыкантов, что пилили трек. например сейчас у нас mastervolume сбрасывается только при инициализации. и этот мастерволум по идее должен быть идти практически первой командой в мелодии. но если мастер волум почему-то выставляется чуть позже старта нот в других дорожках, то первый запуск будет громкий - в смысле начальные ноты, повторные запуски - уже громкость будет одинаковая и не будет этого громкого вступления в начале.

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

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

по поводу проверки где этот бит используется еще - собираюсь собираюсь :) сделаю обязательно.

Добавлено позже:
Ariel the Little Mermaid\030\patch_17.raw
Ariel the Little Mermaid\031\patch_19.raw
Ariel the Little Mermaid\034\patch_2D.raw
Ariel the Little Mermaid\037\patch_0A.raw
Ariel the Little Mermaid\039\patch_76.raw
Ballz\054\patch_77.raw
Bonkers\022\patch_4D.raw
Bonkers\030\patch_4C.raw
Desert Demolition\089\patch_7C.raw
Dick Vitale's Awesome Baby! College Hoops\051\patch_3D.raw
Dick Vitale's Awesome Baby! College Hoops\053\patch_3A.raw
Dick Vitale's Awesome Baby! College Hoops\054\patch_32.raw
Dick Vitale's Awesome Baby! College Hoops\054\patch_34.raw
Dick Vitale's Awesome Baby! College Hoops\059\patch_3C.raw
Dick Vitale's Awesome Baby! College Hoops\062\patch_39.raw
Dinosaurs for Hire\053\patch_28.raw
Dinosaurs for Hire\061\patch_2D.raw
Eternal Champions\082\patch_4A.raw
Home Alone 2\021\patch_2D.raw
Home Alone 2\058\patch_76.raw
Jurassic Park\038\patch_0E.raw
Kid Chameleon\011\patch_5E.raw
Marsupilami\009\patch_30.raw
Marsupilami\013\patch_28.raw
Marsupilami\015\patch_1E.raw
Marsupilami\022\patch_25.raw
Marsupilami\026\patch_2D.raw
Marsupilami\044\patch_37.raw
Marsupilami\065\patch_53.raw
Marsupilami\065\patch_54.raw
Marsupilami\070\patch_59.raw
Normy's Beach Babe-O-Rama\015\patch_10.raw
Normy's Beach Babe-O-Rama\050\patch_46.raw
Pink Goes to Hollywood\056\patch_56.raw
Pink Goes to Hollywood\061\patch_53.raw
Pink Goes to Hollywood\066\patch_44.raw
Prince of Persia\000\patch_12.raw
Prince of Persia\001\patch_04.raw
Prince of Persia\005\patch_03.raw
Prince of Persia\007\patch_11.raw
Prince of Persia\009\patch_06.raw
Prince of Persia\014\patch_13.raw
RBI Baseball 94\078\patch_63.raw
RBI Baseball 94\079\patch_64.raw
Sylvester & Tweety in Cagey Capers\085\patch_7A.raw
Tale Spin\025\patch_36.raw
Tale Spin\049\patch_35.raw
Tale Spin\050\patch_37.raw
Techno Clash\018\patch_14.raw
Techno Clash\019\patch_20.raw
Techno Clash\036\patch_2D.raw
Techno Clash\052\patch_46.raw
Techno Clash\052\patch_47.raw
Techno Clash\086\patch_28.raw
Techno Clash\102\patch_24.raw
Toe Jam & Earl in Panic on Funkotron\031\patch_71.raw
Toe Jam & Earl in Panic on Funkotron\036\patch_60.raw
Vectorman\053\patch_43.raw
Vectorman\054\patch_2C.raw
Vectorman\075\patch_71.raw
Vectorman 2\027\patch_71.raw
Vectorman 2\041\patch_43.raw
Virtual Pinball\013\patch_37.raw
Virtual Pinball\038\patch_5C.raw
Warlock\055\patch_2D.raw
Warlock\088\patch_2C.raw
Wild Snake\047\patch_7D.raw
X-Men 2\009\patch_0B.raw
X-Men 2\115\patch_41.raw
X-Men 2\136\patch_F7.raw
X-Men 2\163\patch_A5.raw
SeregaZ:
по тому специальному режиму товарищ нашел статью:
http://alyjameslab.blogspot.com/search/label/CSM%20Mode

Добавлено позже:
еще ссылку скинули:
http://gendev.spritesmind.net/forum/viewtopic.php?f=24&t=386&start=75
SeregaZ:
библиотека вылетает при проигрывании этой "мелодии". точнее не так. старт этой мелодии, после старт любой другой и произойдет вылет. сама эта мелодия не играет. тишина. однако если собрать в ром и запустить в эмуляторе - звук есть.

в коде мелодии в принципе есть косяк:

--- Код: --- duration 24
 note $33
 delay 24
--- Конец кода ---

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

--- Код: --- duration 24
 delay 24
 note $33

--- Конец кода ---

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

сама игра: Super Battle Tank - War in the Gulf. трек номер 038
SeregaZ:
Sharpnull, тут еще момент. есть ли какой-то нюанс в коде библиотеки, по которому инициализация gemsplay_init должна происходить в родительском окне программы? по замыслу у меня открывается не совсем модальное - обычное окошко, просто парент у него - основное окно, но само основное выключается. фокус на втором. то есть на первое таким образом не переключится - оно всегда снизу. при инициализации в коде этого модального окна все к черту вылетает :) ежели делать инициализацию в основном окне - никаких проблем.

DisableWindow(#Window, 1) - эту убрал и поет, но вылетает при закрытии этого "модального" окна. вобщем как-то gemsplay_init привязывается к окну программы?
Навигация
Главная страница сообщений
Следующая страница
Предыдущая страница

Перейти к полной версии