мы принесем их в жертву?
  • avatar Shiru
  • 9
Есть две разных процедуры с очень похожим по коду циклом генерации звука, и собственно звуком. Наиболее явно они отличаются звучанием ударных.

Одна скорее всего впервые появилась в первом Dizzy, 1987 год. Кто её написал — непонятно. Среди авторов, помимо братьев Оливеров, фигурирует Jon Paul Eldridge — может быть он. Далее она регулярно встречается в играх Code Masters, и автор музыки там практически всегда David Whittaker. Возможно, процедура всё же его (и музыка в первом Dizzy), так как известно, что он писал свои плееры. Он на контакт не идёт. Может быть, можно узнать что-то у братьев Оливеров, но они тоже не очень открыты для общения.

Вторую написал Jonathan 'Joffa' Smith. Впервые замечена в 1988 году. Она называется Fuzz Click, но в биперных кругах её часто называют Special FX Engine, так как оригинальное имя долгое время было неизвестно, и она регулярно применялась в играх Special FX, с музыкой Keith Tinman'а (известно, что он писал её вручную в виде текста, но сам программировать не умел). В 1990 её выдернули чехи и сделали редактор Orfeus Music Assembler, там минимальные отличия в наборе ударных. В 2010 версия процедуры из Fire Fly стала первым движком в Beepola. К сожалению, Jonathan умер тогда же, в 2010, и мы не узнали у него, почему такое сходство. Но он говорил на форуме WoS (сообщения утеряны при обновлении форума), что написал движок сам, и не возражал против его использования.

Обе процедуры довольно похожи по устройству на движки Tim Follin'а. Возможно, уши растут оттуда. А может, Jonathan подсмотрел код в Dizzy и сделал аналог по мотивам. А может, в порядке безумной теории, был какой-нибудь древний компьютерный журнал, где рассматривался подобный способ генерации звука, например для Apple II — ведь там тоже был только бипер, и были многоканальные движки, а платформа заметно более старая.

Ещё надо добавить, что у Jonathan'а до Fuzz Click был одноканальный движок Plip Plop, похожий на одноканальный движок Follin'а. Его использовали в куче игр Ocean, а потом, судя по всему, взяли и доработали испанцы из Topo Soft. Испанцы же часто использовали доработанный движок Wham The Music Box. Так что версия с подглядыванием-заимствованием наиболее вероятна, это было в порядке вещей.
  • avatar tsl
  • 4
Да, большое спасибо, я напрочь забыл про CALL/RET/JUMP! Добавлю в текст. На самом деле, я и собирался их использовать. Кроме них есть ещё другие приёмы. Стек графического контекста, например.

Матрицы относятся только к битмапам, они и называются BitmapTransformХ.

Есть ещё команда трансляции, проще говоря — Х и У скроллка для всех последующих объектов. Фактически, можно получать «неограниченное» количество пиксельных (и не только) плоскостей с индивидуальными «регистрами сдвига».
  • avatar TmK
  • 0
P.S.: Кто из приезжающих/имеющих представителя на патиплейс не приготовил первоместные проды сам виноват, чур потом не жалеть )))
Пользуясь моментом, спрошу.
А чья двухголосая процедура в Dizzy1, Trantor, Hyper Active, Batman, и многих других игрухах? Где/как отыскать следы ее авторства и историю?
В свое время, году в 91-92м я ее изучал, она очень часто встречается.
В дисплейлистах есть CALL/RET, а это значит что они могут быть древовидные.
Отсюда, не обязательно формировать весь дисплейлист заново, достаточно патчить в основном дисплейлисте команды CALL, подключая уже готовые дисплейлисты. Немного неясно, матрицы относятся только к битмэпам, или нет. Если матрицы способны двигать всё, то в начале дисплейлиста можно располагать матрицу и, таким образом, получать сложные иерархические трансформации сцены, с которыми легко справится Z80.
Profit!
Стоит добавить, что дела обстояли ровно так же лет 10-12 назад.
Причина по которой я испугался, была такой же — постоянные манипуляции с регистром IX, когда надо, и когда не надо.
Отсюда вывод, пилить надо свое. По словам z80 gcc patch в groups.google.com отыскивается что-то интересное, к сожалению, дальше я не продвинулся.
Также, на github'е валяются всевозможные форки LLVM в разной степени допиленности.
  • avatar VBI
  • 0
Ну наконец-то становится понятно что оно, и с чем его есть)
А эта азиаточка на CSP будет?
  • avatar TmK
  • 2
Вообще конечно надо в пятницу до дождя поставить палатки и при себе иметь дождевик, хоть самый простой, хоть крутой — можно в пределах 300руб найти в гипермаркете на любой вкус. и комплект запасной сухой одежды и теплую одежду.
  • avatar TmK
  • 3
По поводу погоды:
Перед экраном будет натянут тент с пологими краями.
думаю 6х6 метров мы сможем накрыть точно, а может и больше
  • avatar tsl
  • 0
А сорри, не на то ответил =)
Не забудьте ознакомиться с ориентировочным графиком проведения демопати. Возможно погода по факту внесёт коррективы.

Обратите внимание, что некоторые конкурсы реального времени начинаются уже в пятницу 30 июня.
  • avatar tsl
  • 1
Не бесконечные, но более чем приличные.
  • avatar VBI
  • 1
Какое-то ощущение «бесконечных мощностей» от твоих слов
Тогда в субботу ночью будет лить. Главное успеть поставить палатку до трех часов.
  • avatar Nuts_
  • 0
два года назад все было четко по прогнозу
в пятницу дождь
в субботу как выключили — все прошло на ура
в воскресенье чуть до прайзгивинга не дотянули — полил
  • avatar tsl
  • 0
Многие мне говорят, что я хам, и я согласен с их мнением.
Чо добавить?.. Да, ты прав во всём.
Что, вот прям ни разу такого не было, что начинали глючить старые демки после добавления новых фич, если что-нибудь по таймингам не сошлось? Надо быть ну очень уж осторожным. С блиттером вообще об этом можно не думать. Как однопоточность против многопоточности.

А зачем мне фон читать при выводе спрайтов (если нет каких-нибудь эффектов полупрозрачности)? Фон я буду восстанавливать одним махом в начале цикла отрисовки нового кадра. Кэш тогда сработает эффективно.

Память блиттеру действительно желательна побыстрее, но вот размер не обязательно нужен больше. Можно ведь и распаковывать на лету (а скорость распаковки непостоянна, что для блиттера значения не имеет). Да и просто собирать из кусочков, особо спрайты, часть которых в разных фазах анимации совпадает.

По решениям имею твёрдое мнение, что сперва удобство, потом изящество. В современной обстановке, само собой, и при проектировании нового (втиснуться в старое железо — особый случай).
Что делать, что делать…
Мокнуть! Проходили уже )