Авторы Illusion приложили только таблицу, поэтому можно потратить несколько дней исследуя, какую именно из проекций они применили. Я этим заниматься не буду. Наиболее вероятные кандидаты — Equirectangular, Mercator, Gall stereographic, Miller, Lambert cylindrical equal-area, Gall–Peters, т.е. различные «старые» проекции.
Собственно, это одна из причин почему мне кажется бессмысленным давать рецепты такого рода. kotsoft прав, что самые интересные секреты — это вычисления в этом роде. Но какой смысл научить сейчас всех, допустим, Ламберту, чтобы потом все как попугаи шпарили шары с одними и теми же искажениями?
Давай уже пиши статью как сделал линии в Break Space, от момента возникновения идеи, попыток раскраски знакомест и понимания закономерностей до конечной модели их поведения и внутреннего устройства кода :) Распарсить код и понять алгоритмы можно, а вот процесс зарождения идеи и путей его реализации — думаю это самое интересное, в готовой реализации всего этого нету)
Вот в этом твоём «кто-то учтёт моё пожелание» и заключается причина моего раздражения. Ты пишешь вопрос под моей статьёй, но адресуешь свои призывы «кому-то». Этот неведомый «кто-то» должен по-твоему написать эту же самую статью по-другому. Влезть в код и что-то там рассмотреть не так как я, а так, как хотелось бы тебе. Или что-то ещё в том же роде.
И меня это злит. Потому что этот «кто-то» — это ведь подразумеваюсь я, но задать мне прямой вопрос тебе видимо не позволила гордость или х.з. даже что. В итоге сначала я должен тянуть из тебя клещами информацию о том, чего же тебе собственно хочется (ну, за пределами очевидного понтования о том, как тебе всё это кажется тривиальным). И после всего этого я же и оказываюсь виноватым, потому что ты, якобы, меня покритиковал, а я, якобы, адекватно воспринимаю только плюсики. Твой комментарий — это типичнейшее в стиле zx-pk.ru потребительство, где ты полон мыслей, что всё нужно делать не так, а лучше, но сам явно ничего делать не собираешься; тебе оказалось лень сформулировать даже прямой вопрос.
Генератор развёрнутого кода начинается с адреса #6133. Данные о пропусках хранятся в таблице с адреса #6944.
Формат таблицы такой:
6944: db 0c ; ширина в пикселях этой строки сферы (+1 или +2, это какой-то подгон под кодогенератор)
6945: db 0c,06,04,04,04,03,04,04,04,06,0c ; 11 пропусков для пикселей первой строки
и т.д.
Мне было лень сейчас разбираться, как там согласовано то, что ширина хранится не точно, а +1 или +2. Непосредственно число в начале строки преобразовывается в число пикселей на половину рисунка, потом пересчитывается в сдвиг в байтах (для вывода на экран) и там возня не интересная, приспособленная к конкретному коду.
Ошибочка. Дима не пытается выглядеть умней всех, Дима делиться своими соображениями основанными на его опытах и задает реальные вопросы. Тоже самое в статье сделал и Introspec. Другое дело что уровень начальной подготовки читателя и/или язык повествования могут сказаться негативным образом на понимании. Но никто же не мешает задавать вопросы касающиеся подробностей.
introspec, и правда. Как сделать табличку искажений битмап->шар?
Я помню для Chaos Reconstruction мне помогал Alex Rider, но… на шар оно так и не было похоже.
Было и такое. Вообще, в частности по сферам была такая история:
Один мой товарищ Joker делал вращающуюся сферу размером в пол экрана. в районе 8 фаз анимации.
Так вот, сначала он считал сферу (естественно по формуле сферы) вызовами пзу-шного калькулятора. И считалось все это дело добрых 15 минут.
Потом он переделал на собственные процедуры арифметических операций и табличный синус — и о чудо, 30 секунд. Что вполне нормально.
Конечно можно было заранее сгенерить массив координат в текстуре, заархивировать его, и подсасывать с диска при загрузке интры. Но вы все сами понимаете, что следующий шаг — запилятор (который в некоторых случаях может оказаться даже эффективнее предыдущего метода).
В дополнение к вышесказанному:
Сейчас мы конечно же можем на писюке посчитать матрицу и вогнать ее на спек, более того, можно на писюке сгенерить
сразу ассемблерный код развернутого цикла. Но тогда ведь считали все прямо на спеке? или я не прав?
«В HL — наша исходная картинка (байт на пиксель), в DE — буфер для результата, а в А накапливаются пиксели. Т.е. мы идём слева направо, умножаем А на 2 и добавляем в А текущий пиксель. Теперь фокус, почему я написал DUP? — потому что следующий пиксель может быть тем же, может быть действительно следующим, через 1, или даже, когда мы рисуем самый верх или самый низ сферы, через несколько пикселей от предыдущего. Т.е. программа генерирует такой код для вывода сферы заранее, и кол-во INC L вообще говоря всё время меняется, во время движения по сфере.»
Лично мне интересно, как сформировали этот развернутый цикл. Например в разбираемой деме ILLUSION. чтобы в DUB стоял не знак вопроса а описание формулы и ее реализация, поскольку ЛИЧНО ДЛЯ МЕНЯ, это наиболее интересная часть эффекта. Конечно, твое личное дело как автора писать это или нет, а мое как комментатора — написать свое пожелание. Возможно в будущих статьях кто-то учтет мое пожелание и расскажет об этом. Иначе зачем вообще тогда комментарии? достаточно кнопки +
Ты с кем сейчас разговариваешь, поясни пожалуйста. Если понятно что синус, зачем спрашиваешь. Если тебе интересно, как люди, вообще, считают и хранят разные, вообще, математические функции? ну, по-разному, и считают, и хранят. Как можно ответить на такой широкий вопрос? Только так же широко. Учи математику. Придумывай, как все остальные придумывают. Но какое отношение это всё имеет к демо «Illusion»?
Какие-то авторы статей про демо-эффекты тебя не удовлетворяют…
Ну вот скажу тебе симметрично, что комментаторы у статей про демо-эффекты тоже бывают весьма замысловатые.
Поверь, мне понятны как работают эти эффекты целиком и полностью. Вопрос мой гипотетический. и используемый «матан» часто сложнее и интереснее стандартного алгоритма меппинга текстуры.
То что в данном случае это синус это понятно. Но это, во-первых, лишь малая часть моего вопроса.
Интересно как авторы в каждом случае устраивают матрицы этих кривуль, как их лучше хранить
для каждого кадра (при прекалькуляции), или где-то выгодно считать на лету по таблицам того же исходного синуса — тогда
какие используются алгоритмы для быстрых вычислений.
во вторых, часто дело синусом не ограничивается, и идет в ход матан пожощще. А вот авторы
статей про демо эффекты, почему-то стараются всегда этот вопрос обходить стороной.
Вот таблица из Википедии: en.wikipedia.org/wiki/List_of_map_projections#Cylindrical
Авторы Illusion приложили только таблицу, поэтому можно потратить несколько дней исследуя, какую именно из проекций они применили. Я этим заниматься не буду. Наиболее вероятные кандидаты — Equirectangular, Mercator, Gall stereographic, Miller, Lambert cylindrical equal-area, Gall–Peters, т.е. различные «старые» проекции.
Собственно, это одна из причин почему мне кажется бессмысленным давать рецепты такого рода. kotsoft прав, что самые интересные секреты — это вычисления в этом роде. Но какой смысл научить сейчас всех, допустим, Ламберту, чтобы потом все как попугаи шпарили шары с одними и теми же искажениями?
И меня это злит. Потому что этот «кто-то» — это ведь подразумеваюсь я, но задать мне прямой вопрос тебе видимо не позволила гордость или х.з. даже что. В итоге сначала я должен тянуть из тебя клещами информацию о том, чего же тебе собственно хочется (ну, за пределами очевидного понтования о том, как тебе всё это кажется тривиальным). И после всего этого я же и оказываюсь виноватым, потому что ты, якобы, меня покритиковал, а я, якобы, адекватно воспринимаю только плюсики. Твой комментарий — это типичнейшее в стиле zx-pk.ru потребительство, где ты полон мыслей, что всё нужно делать не так, а лучше, но сам явно ничего делать не собираешься; тебе оказалось лень сформулировать даже прямой вопрос.
Генератор развёрнутого кода начинается с адреса #6133. Данные о пропусках хранятся в таблице с адреса #6944.
Формат таблицы такой:
Мне было лень сейчас разбираться, как там согласовано то, что ширина хранится не точно, а +1 или +2. Непосредственно число в начале строки преобразовывается в число пикселей на половину рисунка, потом пересчитывается в сдвиг в байтах (для вывода на экран) и там возня не интересная, приспособленная к конкретному коду.
Я помню для Chaos Reconstruction мне помогал Alex Rider, но… на шар оно так и не было похоже.
надо покопаться по старым запасам, где-то у меня валялся sphere texture mapping.
Один мой товарищ Joker делал вращающуюся сферу размером в пол экрана. в районе 8 фаз анимации.
Так вот, сначала он считал сферу (естественно по формуле сферы) вызовами пзу-шного калькулятора. И считалось все это дело добрых 15 минут.
Потом он переделал на собственные процедуры арифметических операций и табличный синус — и о чудо, 30 секунд. Что вполне нормально.
Конечно можно было заранее сгенерить массив координат в текстуре, заархивировать его, и подсасывать с диска при загрузке интры. Но вы все сами понимаете, что следующий шаг — запилятор (который в некоторых случаях может оказаться даже эффективнее предыдущего метода).
Сейчас мы конечно же можем на писюке посчитать матрицу и вогнать ее на спек, более того, можно на писюке сгенерить
сразу ассемблерный код развернутого цикла. Но тогда ведь считали все прямо на спеке? или я не прав?
«В HL — наша исходная картинка (байт на пиксель), в DE — буфер для результата, а в А накапливаются пиксели. Т.е. мы идём слева направо, умножаем А на 2 и добавляем в А текущий пиксель. Теперь фокус, почему я написал DUP? — потому что следующий пиксель может быть тем же, может быть действительно следующим, через 1, или даже, когда мы рисуем самый верх или самый низ сферы, через несколько пикселей от предыдущего. Т.е. программа генерирует такой код для вывода сферы заранее, и кол-во INC L вообще говоря всё время меняется, во время движения по сфере.»
Лично мне интересно, как сформировали этот развернутый цикл. Например в разбираемой деме ILLUSION. чтобы в DUB стоял не знак вопроса а описание формулы и ее реализация, поскольку ЛИЧНО ДЛЯ МЕНЯ, это наиболее интересная часть эффекта. Конечно, твое личное дело как автора писать это или нет, а мое как комментатора — написать свое пожелание. Возможно в будущих статьях кто-то учтет мое пожелание и расскажет об этом. Иначе зачем вообще тогда комментарии? достаточно кнопки +
Подойдут вот такие: 2017, basic, game, compo, конкурсы, бейсик, игры
Какие-то авторы статей про демо-эффекты тебя не удовлетворяют…
Ну вот скажу тебе симметрично, что комментаторы у статей про демо-эффекты тоже бывают весьма замысловатые.
Интересно как авторы в каждом случае устраивают матрицы этих кривуль, как их лучше хранить
для каждого кадра (при прекалькуляции), или где-то выгодно считать на лету по таблицам того же исходного синуса — тогда
какие используются алгоритмы для быстрых вычислений.
во вторых, часто дело синусом не ограничивается, и идет в ход матан пожощще. А вот авторы
статей про демо эффекты, почему-то стараются всегда этот вопрос обходить стороной.