Посмотри как на вектор портировали, там есть компиляторСообщение от svofski
Посмотри как на вектор портировали, там есть компилятор
Насколько я понял, компилятором там называется программа, которая из текстового файла делает бинарник для плеера.
Больше игр нет
Примерно так, если грубо. Спектрумовские редакторы сохраняют музыку в двух вариантах: "исходник" (нечто вроде текста с нотами, плюс данные орнаментов и сэмплов), всё это запаковано своими встроенными паковщиками в подобие архива, а второй вариант - компилировпнный модуль с плеером/без плеера, где данные уже идут в максимально оптимизированном для вывода формате. И вот разработка этого компиленного формата, а также плеера - самая ответственная задача для кодера. Каждый лепил, на что хватало мозгов, ну и с течением времени оптимизировались сами плееры компиленных модулей. Компилеры, как правило, были встроены прямо в редактор.
Мой формат модуля (для STPro) не был оптимален по размеру компилируемых модулей, но в плане быстродействия и формат, и плеер близки к идеалу. В нём один "поток данных" для нот всех каналов, плюс своя процедура обработки каждого канала, что прилично раздуло код, но по итогу плеер вышел довольно быстрым и относительно компактным, 1868 байт, насколько помню. Вот архив с редактором на vtrd https://vtrd.in/system/STPROFIX.ZIP
Если не изменяет память, внутри трдшника есть отдельно демонстрационный Бейсик-плеер с замером на бордюре, и видно, что времянки почти не дергаются, настолько ровно подогнан код. Пардон за неВекторную тематику, но кому-то, возможно, будет интересно.
svofski(03.08.2022)
Кстати, раз уж вектор, то задачу выравнивания (если не нужна точность до такта) можно решить с использованием таймера.
reddie, очень даже интересно. И приблизительно понятно. Мое предложение делать дополнительное промежуточное пережовывание общепринятых трекерных форматов для удобства плеера по-моему совпадает по духу с этой идеей.
Я не закапывался глубоко в форматы трекерных модулей, но чуть чуть удивлялся тому, как там все высокоуровнево для такой низкоуровневой штуки. Имеющиеся плееры выходит совсем неплохо справляются с такой сложной задачей. А ведь по идее на целевой платформе нам не нужны ни паттерны, ни ноты и даже не частоты, а нужны уже просчитанные значения регистров. Орнаменты итд это для музыканта, а для плеера-чипа это все просто меняющиеся параметры. Но так легко дойти до того, что выходит, что регистровый дамп -- это лучшее, что можно придумать.
В общем вывод такой: для того, чтобы получить плеер лучше тех, что уже есть, придется включить голову и найти в ней мозг.
Больше игр нет
да. вопрос лишь в степени пережеванности =) тут прямая зависимость: чем сильнее пережевать, тем, по идее, быстрее плеер.
именно, однако в те далекие времена кодерские технологии не дошли до PSG, вернее, до упакованного в разумные размеры формата. Отдельные кусочки дампа регистров использовались в критичных местах (одновременная загрузка с дискеты, например), но чтоб весь трек в PSG загнать, понадобилось много лет. Так-то да, дамп по скорости воспроизведения - лучший вариант. Но упаковать его в те годы подобным образом не представлялось возможным, особенно сразу на целевых платформах. Поэтому треки компилировались в некую смесь из дампа паттернов и сэмплов-орнаментов по отдельности, а на плеер возлагалась задача все это выкидывать в регистры чипа, и желательно побыстрее. Тут уже решала квалификация кодера, суметь провести оптимизацию по скорости (или, что намного реже, размеру). В ход шли всякие трюки и учет особенностей AY. Например, слайд сэмпла вверх-вниз в редакторе изображен как в плюс, так и в минус, но плеер делает только сложение регистровых пар, старшие незначащие биты высоты звука при этом игнорируются чипом, и т.д.
Абсолютно верно. И лучше писать с нуля сразу под 8080 - в теории это даст наилучший результат, если программист хорошо разбирается в своем деле.
svofski(03.08.2022)
Подскажите пожалуйста быстрый RND. я пока использую байтовый счетчик в прерывании, но хочется иметь чтото получше. Может можно читать из какогото порта какойнить мусор или часто меняющиеся данные?
Я использовал вот такой: https://github.com/nzeemin/vector06c...lcoda.asm#L797
На порты полагаться сложно, тем более в эмуляторах.
Можно инкрементировать seed, пока игрок не нажмёт Старт в меню - даст хорошее начальное значение.
Oleg N. Cher(08.08.2022), parallelno(08.08.2022)
Спасибо, nzeemin!
Покопавщись в интернетах нашел чуть более быстрый. но конечно не факт что качественее. Но для моих нужд самое то.
Код:; 8-bit Xor-Shift random number generator. ; Created by Patrik Rak in 2008 and revised in 2011/2012. ; See http://www.worldofspectrum.org/forums/showthread.php?t=23070 ; period 2^32-1. ; out: ; a - 8-bit pseudo-random number Rnd8: push h push d @rnd: lxi h, 0xA280 ; seed must not be 0 lxi d, 0xC0DE ; xz -> yw shld @rnd+4 ; x = y, z = w mov a, l ; w = w ^ ( w << 3 ) add a add a add a xra l mov l, a mov a, d ; t = x ^ (x << 1) add a xra d mov h,a rar ; t = t ^ (t >> 1) ^ w xra h xra l mov h, e ; y = z mov l, a ; w = t shld @rnd+1 pop d pop h ; 204 ret
Последний раз редактировалось parallelno; 09.08.2022 в 11:29.
push b ... pop b - может push d ... pop d?
- - - Добавлено - - -
И, кстати, если оставить push h ... pop h, то не будет hl - 16-bit pseudo-random number
- - - Добавлено - - -
Хотя лучше убрать комментарий про "hl - 16-bit pseudo-random number", эта процедура рассчитана на генерацию 8 битных случайных чисел.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием