Среди звуков нет плохих и хороших, чем больше красок в звуковой палитре, тем лучше, место найдётся любым. Это ещё ерунда по сравнению с тем скрежетом, который извлекают из модульных синтезаторов, похожих на взрыв на телефонной станции и стоящих безумных денег. Звуки, напоминающие работу дисковода синтезируют с нуля в жанре дабстепа, который мэйнстрим уже лет 10. Тут интерес в более характерном звуке, т.к. синтезированный звук всё же довольно плоский, а у механизма на каждой ноте свой резонанс, звучит повеселее. Я не один такой чудной, люди давно экспериментируют. Например, soundcloud.com/theectocosm/rise-of-the-floppy-men
По второму вопросу — если говорить серьёзно, то вообще-то да, я знаю немало людей, реально монетизирующих целый спектр похожих хобби, и значительная часть оных из стран бывшего СНГ. Это просто конкретно у ZX такая специфика, что кажется, что ничего не взлетит. На других платформах ситуация получше. В данном случае это, конечно, больше социальный эксперимент и шутка юмора, монетизировать надо целенаправленно, и для этого нужны несколько другие навыки, чем писать коды.
Касательно восьми бит, это свойство конкретно ранних микропроцессоров, возникшее из ограничений технологии того времени. До них были архитектуры с самым разным количеством бит в слове, и вовсе не обязательно это была степень двойки или чётное число. Примеры: en.wikipedia.org/wiki/Word_(computer_architecture)#Table_of_word_sizes
Вопрос в том, что у Unreal с поддержкой конфы насчёт лицензии. С другими платформами постоянно возникают проблемы, т.к. эмуляторы с открытым кодом часто пишутся всем миром на протяжении десятилетий, а внятными открытыми лицензиями в начале проекта, разумеется, никто особо не озаботился. Получается, что концов просто не найти (одни авторы дают разрешение, другие нет), зато при релизе на Steam исправно набегают борцы за лицензионную чистоту и создают весьма неприятный шум. А некоторые авторы эмуляторов осознанно делают полузакрытую лицензию — исходники открыты, использование в коммерческих целях запрещено — и заряжают приличные суммы за разрешение. Ну и есть такое усложняющее жизнь явление, что у платформ посложнее 8-битных по сути есть всего 2-3 ветки 'исконных' эмуляторов, а все остальные растут из них.
Касательно конкретно Unreal, там как минимум будут небольшие проблемы с добавленной когда-то поддержкой TFM (MAME имел свою полузакрытую лицензию, сейчас перешёл GPL), и вроде с SAA1099. Это поверхностный взгляд, я давно не смотрел в исходники и не знаю реальную ситуацию.
Пока единственный реальный путь для наполнения конфы софтом, который я вижу — делать игры для других сопоставимых платформ, но худо-бедно портабельные (главным образом, писать на C), и открывать исходники для желающих сделать порт. Делать что-то с нуля специально, тем более крупное — неэффективное вложение сил, нет ни надежды на профит, ни даже толком аудитории. Не говоря уже про известные настроения в этой самой аудитории. Как бы даже если уж делать совсем-совсем как хобби и отдых и для себя, имеющийся расклад — 'десять человек глянут, и всё, игры как будто не было', либо 'поиграют тысячи человек, обзоры в видео и журналах, донаты, физические копии в коллекциях любителей, чужие порты, выход на Steam и телефоны, и так далее' — невольно заставит призадуматься.
Падение скорости конечно есть, но gcc действительно работает очень хорошо, и главное стабильно. Genesis и Neo-Geo в этом плане в самом выгодном положении среди всех приставок, современный надёжный компилятор. NES на втором месте, хотя cc65 очень ругают за 'плохой код' все, кому не лень (но это не помешало написать несколько десятков игр). SNES в полной глубокой и беспросветной жпечали, у неё просто какие-то компилятор-диверсант и компилятор-ниндзя — один крайне глючный и тормозной, другой хороший, только его невозможно достать и даже купить, хотя он продаётся.
Да, это широко известный в узких кругах сайт. Нередко пригождается, чтобы убедиться, что на самом деле было в конкретной игре, т.к. эмуляторы иногда смешивают конфигурации и по данным в заголовке iNES непонятно, какая именно подразумевалась (поэтому сейчас есть iNES 2.0 и прочие форматы образов). Также там можно накопать интересное, например, 'капли' на родном картридже (официальная двухигровка Super Mario Bros. + Duck Hunt):
TLROM — это не терминология создателей эмуляторов, а официальное название платы, написано на ней. Каждая плата картриджей производства Nintendo имеет свои названия. NROM, CNROM, UNROM — это всё оттуда. MMC3B тоже официальное название, только уже самого чипа, устанавливаемого на разные платы.
Кстати, хочу заметить, что такой примитивный формат — байт ожидания и два байта периода — пока что оказывается самым эффективным конкретно для этих треков. Видимо в них настолько часто и далеко меняется период, что никакие статистические сокращения (типа тех, что я делал в Planet X3) не помогают. Т.е. введение раздельных тегов ожидания + слово, ожидания + только младший байт и т.п. только увеличивает объём данных. Обратные ссылки конечно помогут, но встаёт вопрос написания оптимального пакера (в PX3 было проще, там был доступ к исходным паттернам и данные шли строками), и опять же это наверняка помешает последующему LZ-сжатию. Это к вопросу по утрамбовке в 48K, чего конечно хотелось бы добиться.
Да, всё правильно. Занятно, как одна и та же квадратная волна и одна и та же аранжировка воспринимаются по разному при проигрывании на разных устройствах.
Фориат очень прост, т.к. даже на XT много ОЗУ, а усложнения формата сказываются на сжимаемости файлов, и неизвестно, будет ли в итоге выигрыш. Да, он почти как в примере на Бейсике, с парой мелочей.
Первый байт файла — частота кадров-обновлений в Гц, в альбоме всегда 120.
Далее по три байта — один байт количество кадров и два байта (lsb/msb) период, который будет звучать в течении этих кадров. Период измеряется в 1193180/Гц, 0 выключает звук.
Также вместо количества кадров может встретиться два вида маркера. В конце трека всегда 0. 255 кадров — это специальный маркер для указания точки начала цикла и точки конца цикла. Трек имеет структуру вступление-тело-концовка, тело повторяется выбранное пользователем количество раз. Когда 255 встречается первый раз — это точка начала цикла, второй — точка конца цикла. Если цикл включен пользователем, при втором появлении 255 происходит переход на запомненное при первом появлении место, иначе просто играет дальше, там концовка и заканчивается трек.
Я не задумывался о возможности релиза на ZX, кроме применимости самой техники к 16K для чистого звука. Но BEEP в ПЗУ не сильно гибкий для обновлений на 120 Гц без сброса фазы, видимо не вариант.
Вообще да, кому-то может быть интересно, так что, учитывая минимум трудозатрат, сделать стоило бы. Но в 48К без раздельной загрузки не влезет, самый большой трек 15K, все треки в MegaLZ 37.5K.
Это правда. Но теперь они вот так измельчали, а я хотел, чтобы современная аудитория поняла, о чём вообще речь. Ну и вставил, что первым попалось из свободных фоток — у меня на руках всё равно только ноуты либо такие пищалки.
Написание фреймовых скроллеров было типичной забавой во времена популярности электронной прессы на ZX — каждый старался сделать фреймовую читалку. См., например, BornDead, где к последним номерам появилась плавная попиксельная цветная листалка на весь экран (на Pentagon). Правда, в подобных листалках часто хитрили, не выводя пустые строки пикселей между строками текста.
Примерно так же работает горизонтальный скролл на MSX2. Вертикальный там нормальный, а горизонтальный через 'центрирование растра', которое позволяет двигать растр по экрану на 8 пикселей влево-вправо.
По второму вопросу — если говорить серьёзно, то вообще-то да, я знаю немало людей, реально монетизирующих целый спектр похожих хобби, и значительная часть оных из стран бывшего СНГ. Это просто конкретно у ZX такая специфика, что кажется, что ничего не взлетит. На других платформах ситуация получше. В данном случае это, конечно, больше социальный эксперимент и шутка юмора, монетизировать надо целенаправленно, и для этого нужны несколько другие навыки, чем писать коды.
Касательно восьми бит, это свойство конкретно ранних микропроцессоров, возникшее из ограничений технологии того времени. До них были архитектуры с самым разным количеством бит в слове, и вовсе не обязательно это была степень двойки или чётное число. Примеры: en.wikipedia.org/wiki/Word_(computer_architecture)#Table_of_word_sizes
www.kvraudio.com/product/kmath-synthesizer-by-kmusicsoftware
www.kvraudio.com/product/wave-designer-by-dnr-collaborative
В Wavosaur нужно нажимать Apply VST, чтобы результат обработки применился к редактируемой копии звука, а не просто пошёл на выход звуковой карты.
Также есть полезный плагин Smexoscope, позволяющий посмотреть на форму волны: bram.smartelectronix.com/plugins.php?id=4
Касательно конкретно Unreal, там как минимум будут небольшие проблемы с добавленной когда-то поддержкой TFM (MAME имел свою полузакрытую лицензию, сейчас перешёл GPL), и вроде с SAA1099. Это поверхностный взгляд, я давно не смотрел в исходники и не знаю реальную ситуацию.
Первый байт файла — частота кадров-обновлений в Гц, в альбоме всегда 120.
Далее по три байта — один байт количество кадров и два байта (lsb/msb) период, который будет звучать в течении этих кадров. Период измеряется в 1193180/Гц, 0 выключает звук.
Также вместо количества кадров может встретиться два вида маркера. В конце трека всегда 0. 255 кадров — это специальный маркер для указания точки начала цикла и точки конца цикла. Трек имеет структуру вступление-тело-концовка, тело повторяется выбранное пользователем количество раз. Когда 255 встречается первый раз — это точка начала цикла, второй — точка конца цикла. Если цикл включен пользователем, при втором появлении 255 происходит переход на запомненное при первом появлении место, иначе просто играет дальше, там концовка и заканчивается трек.
Вообще да, кому-то может быть интересно, так что, учитывая минимум трудозатрат, сделать стоило бы. Но в 48К без раздельной загрузки не влезет, самый большой трек 15K, все треки в MegaLZ 37.5K.