Нормальная игровая музыка там. Демо-треки и конкурсные нельзя в игры вставлять. В игру человек играет несколько часов, и от сложной музыки мозг очень быстро устаёт. В играх должно быть что-то максимально простое и незатейливое, плюс ещё и позволяющее играть эффекты поверх
Класс, ждем!
Только вот не пойму, этой суеты с Next.
Тогда если уж поддерживаем буржуйский фпга денди-спектрум,
то почему бы не поддержать и возможности отечественной пентевы.
Почему-то мне кажется что количество наших, которые купят Next будет исчисляться единицами, а пентев много у народа
Не знаю как насчет портит или нет мероприятие. По мне так совсем не портит — по крайней мере музей уж точно. Но вот если некоторые орги хотят обратно с этим бороться — то им стоит подумать о том, чем тогда они будут развлекать два дня людей. Ревижен, когда у них демопоказ длится несколько часов, вполне может себе позволить убрать все кроме этого. А вот в наших реалиях, когда у нас в среднем 1.5 демы — ну я не знаю, если только орги сами демы начнут писать)
Ну вот и ответ на мой вопрос — оказывается там прекалькулированная заранее, и тупо загруженная таблица смещений. Понятно что методы ее вычисления — это скорее, тема отдельной статьи. а насчет методов — думаю авторы иллюзион слыхом не слыхивали ни об одном из перечисленных. Посчитали по формуле сферы с проекцией на ортогональную плоскость да и все, тупо из бейсика, поками.
Рискну предположить, что непосредственно в теле демы по этой таблице генерится статичный развернутый цикл.
Денис, тот факт что у меня нет времени на написание полноценных дем, не отменяет того факта, что тема программирования демоэффектов мне крайне интересна. Но мне больше в демах интересны не «флоу», а программистские этюды. Как свободный человек, я имею право выбирать чем мне интересоваться.
Тут надо разделять понятие демы и интры. Понятно что в деме такой ход неприменим. А вот интра она на то и интра, чтобы все генерить «в себе», с минимальным объемом загружаемого исходного кода, в этом и состоит ее прелесть.
Ну, во-первых мне искренне жаль, что своим безобидным вопросом, с просьбой раскрыть для меня некоторые интересующие меня, но не раскрытые в статье аспекты я вызывал твое раздражение, мне правда стыдно.В оправдание, хотелось бы пояснить: Если я что-то спрашиваю, то я спрашиваю именно то что я спрашиваю, без скрытых смыслов и двойного дна. Если я обращаюсь не конкретно к тебе, а ко многим, или пространному «кому-то», то это значит лишь то, что я прочитал много статей на хайпе по программированию, и, по моему скромному разумению, чуть более во всех из них вышеописанные аспекты игнорируются. А коммент, именно под твоей статьей я написал, так как доселе я считал, что именно ты можешь адекватно воспринять вопрос, и, возможно, если не лень ответить. Я прекрасно отдавал себе отчет, что достопочтенный Интроспек не будет переписывать ради меня эту статью, но, т.к., эта статья заявляется как первой в цикле подобных – то, возможно, если будет желание, в какой-то из следующих статей, он учтет и мое пожелание, а также, возможно, его учтет и КТО-ТО ДРУГОЙ. На твоем месте, я бы был удовлетворен, так как подобные вопросы (в отличие от бездумного тыкания плюсиков) свидетельствуют как минимум о том, что статью прочитали, заинтересовались, т.е. работа проделана не зря. Задавая эти вопросы, я ожидал услышать ответы по существу, или на худой конец, что-то вроде: «Извиняй чувак, мне было в лом в этом разбираться, да и вообще я хотел написать о другом». Вместо этого я в очередной раз, вижу, как у автора, говоря современным слэнгом, начинает «подгорать», причем буквально с «пол-оборота». Причем ладно бы я сказал статья Г. и автор М., так нет, в целом выразил благодарность за поднятую интересную тему, просто попросил раскрыть тему еще полнее. Насчет «клешней»: адекватная реакция на вопрос, который не понятен – просьба разъяснить точнее, что имелось ввиду, а не злость.
Насчет понтований: тут понтов никаких, я действительно знал эти методы, и видел синус в мувинг шите, я спрашивал не про него. Но их реализации в конкретной деме, тем не менее, интересны, ибо всегда полезно иметь ввиду чужой успешный опыт, ибо свои представления могут быть ошибчно и неэффективны.
Было и такое. Вообще, в частности по сферам была такая история:
Один мой товарищ Joker делал вращающуюся сферу размером в пол экрана. в районе 8 фаз анимации.
Так вот, сначала он считал сферу (естественно по формуле сферы) вызовами пзу-шного калькулятора. И считалось все это дело добрых 15 минут.
Потом он переделал на собственные процедуры арифметических операций и табличный синус — и о чудо, 30 секунд. Что вполне нормально.
Конечно можно было заранее сгенерить массив координат в текстуре, заархивировать его, и подсасывать с диска при загрузке интры. Но вы все сами понимаете, что следующий шаг — запилятор (который в некоторых случаях может оказаться даже эффективнее предыдущего метода).
В дополнение к вышесказанному:
Сейчас мы конечно же можем на писюке посчитать матрицу и вогнать ее на спек, более того, можно на писюке сгенерить
сразу ассемблерный код развернутого цикла. Но тогда ведь считали все прямо на спеке? или я не прав?
«В HL — наша исходная картинка (байт на пиксель), в DE — буфер для результата, а в А накапливаются пиксели. Т.е. мы идём слева направо, умножаем А на 2 и добавляем в А текущий пиксель. Теперь фокус, почему я написал DUP? — потому что следующий пиксель может быть тем же, может быть действительно следующим, через 1, или даже, когда мы рисуем самый верх или самый низ сферы, через несколько пикселей от предыдущего. Т.е. программа генерирует такой код для вывода сферы заранее, и кол-во INC L вообще говоря всё время меняется, во время движения по сфере.»
Лично мне интересно, как сформировали этот развернутый цикл. Например в разбираемой деме ILLUSION. чтобы в DUB стоял не знак вопроса а описание формулы и ее реализация, поскольку ЛИЧНО ДЛЯ МЕНЯ, это наиболее интересная часть эффекта. Конечно, твое личное дело как автора писать это или нет, а мое как комментатора — написать свое пожелание. Возможно в будущих статьях кто-то учтет мое пожелание и расскажет об этом. Иначе зачем вообще тогда комментарии? достаточно кнопки +
Поверь, мне понятны как работают эти эффекты целиком и полностью. Вопрос мой гипотетический. и используемый «матан» часто сложнее и интереснее стандартного алгоритма меппинга текстуры.
То что в данном случае это синус это понятно. Но это, во-первых, лишь малая часть моего вопроса.
Интересно как авторы в каждом случае устраивают матрицы этих кривуль, как их лучше хранить
для каждого кадра (при прекалькуляции), или где-то выгодно считать на лету по таблицам того же исходного синуса — тогда
какие используются алгоритмы для быстрых вычислений.
во вторых, часто дело синусом не ограничивается, и идет в ход матан пожощще. А вот авторы
статей про демо эффекты, почему-то стараются всегда этот вопрос обходить стороной.
Отличное начинание! Полностью поддерживаю.
Почерпнул для себя некоторые идеи
Мое личное пожелание:
Вообще циклы выводящие текстуру, лично мне и так понятны, равно как и ухищрения со стеком и т.п.
А вот мне как раз интересно, как это оно «идет по кривуле», как эту «кривулю» посчитать. И считают ли они
ее в теле демы, или тупо загружают координаты? В каком виде удобно хранить именно эти данные?
Только вот не пойму, этой суеты с Next.
Тогда если уж поддерживаем буржуйский фпга денди-спектрум,
то почему бы не поддержать и возможности отечественной пентевы.
Почему-то мне кажется что количество наших, которые купят Next будет исчисляться единицами, а пентев много у народа
Рискну предположить, что непосредственно в теле демы по этой таблице генерится статичный развернутый цикл.
Насчет понтований: тут понтов никаких, я действительно знал эти методы, и видел синус в мувинг шите, я спрашивал не про него. Но их реализации в конкретной деме, тем не менее, интересны, ибо всегда полезно иметь ввиду чужой успешный опыт, ибо свои представления могут быть ошибчно и неэффективны.
Один мой товарищ Joker делал вращающуюся сферу размером в пол экрана. в районе 8 фаз анимации.
Так вот, сначала он считал сферу (естественно по формуле сферы) вызовами пзу-шного калькулятора. И считалось все это дело добрых 15 минут.
Потом он переделал на собственные процедуры арифметических операций и табличный синус — и о чудо, 30 секунд. Что вполне нормально.
Конечно можно было заранее сгенерить массив координат в текстуре, заархивировать его, и подсасывать с диска при загрузке интры. Но вы все сами понимаете, что следующий шаг — запилятор (который в некоторых случаях может оказаться даже эффективнее предыдущего метода).
Сейчас мы конечно же можем на писюке посчитать матрицу и вогнать ее на спек, более того, можно на писюке сгенерить
сразу ассемблерный код развернутого цикла. Но тогда ведь считали все прямо на спеке? или я не прав?
«В HL — наша исходная картинка (байт на пиксель), в DE — буфер для результата, а в А накапливаются пиксели. Т.е. мы идём слева направо, умножаем А на 2 и добавляем в А текущий пиксель. Теперь фокус, почему я написал DUP? — потому что следующий пиксель может быть тем же, может быть действительно следующим, через 1, или даже, когда мы рисуем самый верх или самый низ сферы, через несколько пикселей от предыдущего. Т.е. программа генерирует такой код для вывода сферы заранее, и кол-во INC L вообще говоря всё время меняется, во время движения по сфере.»
Лично мне интересно, как сформировали этот развернутый цикл. Например в разбираемой деме ILLUSION. чтобы в DUB стоял не знак вопроса а описание формулы и ее реализация, поскольку ЛИЧНО ДЛЯ МЕНЯ, это наиболее интересная часть эффекта. Конечно, твое личное дело как автора писать это или нет, а мое как комментатора — написать свое пожелание. Возможно в будущих статьях кто-то учтет мое пожелание и расскажет об этом. Иначе зачем вообще тогда комментарии? достаточно кнопки +
Интересно как авторы в каждом случае устраивают матрицы этих кривуль, как их лучше хранить
для каждого кадра (при прекалькуляции), или где-то выгодно считать на лету по таблицам того же исходного синуса — тогда
какие используются алгоритмы для быстрых вычислений.
во вторых, часто дело синусом не ограничивается, и идет в ход матан пожощще. А вот авторы
статей про демо эффекты, почему-то стараются всегда этот вопрос обходить стороной.
Почерпнул для себя некоторые идеи
Мое личное пожелание:
Вообще циклы выводящие текстуру, лично мне и так понятны, равно как и ухищрения со стеком и т.п.
А вот мне как раз интересно, как это оно «идет по кривуле», как эту «кривулю» посчитать. И считают ли они
ее в теле демы, или тупо загружают координаты? В каком виде удобно хранить именно эти данные?