ОК, например, линия Dark^X-Trade, прекрасная статья, никаких вопросов вообще. Но много ты знаешь реально быстрых линий, спроектированных иначе чем у него?
В коде каждого из нас зарыт злостный гоблин… :)
Я про то, что какой бы ужастик в коде не был, интересен путь, а также проблемы и нюансы решаемые и возникающие в процессе.
Мне, кстати, кажется, что твоя точка зрения про таблицы весьма экстремальна. Мне прекалк в 30 секунд не кажется нормальным, а уж особенно в середине трекмо. Ты напомнил мне, как кодер ротозумера в Batman Forever на амстраде вместо традиционного расчета вектора для шагания по текстуре сделал просто таблицу готовых векторов для каждого нужного ему угла и его обвиняли его в том, что у него не ротозумер, а анимация.
С моей точки зрения, это какие-то бессмысленные ограничения, которые портят впечатление с т.зр. зрителя. Т.к. я стараюсь делать демы для зрителей, я не считаю принципиальным кто и где считал таблицы и, даже больше, я уже неоднократно задействовал кодогенераторы написанные на PC. Это позволяет при прочих равных условиях повысить качество сгенерированного кода (качество в плане объёма и/или скорости), даёт сопоставимую скорость распаковки, а так же в разы упрощает отладку.
Я бы рассказал с удовольствием, если бы у меня не было чёткого ощущения, что должен быть какой-то способ лучше чем то, что я наделал в запарке. Итоговый эффект вышел в 3 фрейма на пентагоне; но концовка самую малость тормозит на классике, т.е. слегка вылезает из 3х фреймов. Исходно подразумевался рендер в 3 прохода (1. линии -> чанки 2х2, 2. чанки 2х2 -> чанки 1х1, 3. вывод чанков 1х1), но в первом проходе я накосячил и времени переделать его ещё раз не оставалось, поэтому сделан второй проход, который чинит недостатки первого, потом третий проход, который частично красит кадр и переводит всё в чанки 8х8 и только потом 4й проход с выводом чанков.
Первые 2 прохода, невзирая на недостатки того, как я их сделал, довольно эффективны. Третий проход писался последним и на него не было времени, он фактически не оптимизирован…
Короче, ты прав, может и нужно написать ужастик, хоть кодеры поржут.
Авторы 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 секунд. Что вполне нормально.
Конечно можно было заранее сгенерить массив координат в текстуре, заархивировать его, и подсасывать с диска при загрузке интры. Но вы все сами понимаете, что следующий шаг — запилятор (который в некоторых случаях может оказаться даже эффективнее предыдущего метода).
Долго смеялся :) Самое главное демы не забывайте делать, а то в теории то все крутые и принципиальные!
Я про то, что какой бы ужастик в коде не был, интересен путь, а также проблемы и нюансы решаемые и возникающие в процессе.
Вот тут есть пример выкладок: www.javaworld.com/article/2076696/learn-java/draw-textured-spheres.html
С моей точки зрения, это какие-то бессмысленные ограничения, которые портят впечатление с т.зр. зрителя. Т.к. я стараюсь делать демы для зрителей, я не считаю принципиальным кто и где считал таблицы и, даже больше, я уже неоднократно задействовал кодогенераторы написанные на PC. Это позволяет при прочих равных условиях повысить качество сгенерированного кода (качество в плане объёма и/или скорости), даёт сопоставимую скорость распаковки, а так же в разы упрощает отладку.
Первые 2 прохода, невзирая на недостатки того, как я их сделал, довольно эффективны. Третий проход писался последним и на него не было времени, он фактически не оптимизирован…
Короче, ты прав, может и нужно написать ужастик, хоть кодеры поржут.
Вот таблица из Википедии: 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 секунд. Что вполне нормально.
Конечно можно было заранее сгенерить массив координат в текстуре, заархивировать его, и подсасывать с диска при загрузке интры. Но вы все сами понимаете, что следующий шаг — запилятор (который в некоторых случаях может оказаться даже эффективнее предыдущего метода).