Просмотр полной версии : Вращение спрайта на произвольный угол
Чтобы не плодить лишние темы решил написать сюда. В демомейкерстве я совсем ничего не знаю. Даже банально с синусами никогда не работал (хотя Витамин дал наводку по этой теме, спасибо!). Но вот есть у меня вопрос, ответ на который толком найти не могу. Нужно описание алгоритма поворота спрайта. Ужэе была тут когда- подобная тема и там даже есть отсылка на статейки на zxpress. Но статейки бестолковые, если честно. Толком ничего не описывается, есть пара процедур без особых комментариев. А мне бы в целом понять как работает поворот. Тогда можно будет посидеть и самому чё-нить закодить. Расскажите кто что знает по этому вопросу? а ещё, хотелось бы знать, как делается эффект туннеля.
Sayman, Поворот спрайта на произвольный угол или по 90градусов?
Поворот в редакторе спрайтов (относительно медленно), при подготовке уровня/сцены..ситуации/рождения в памяти, или прям на лету, при выводе спрайта?
Sayman, Поворот спрайта на произвольный угол или по 90градусов?
Поворот в редакторе спрайтов (относительно медленно), при подготовке уровня/сцены..ситуации/рождения в памяти, или прям на лету, при выводе спрайта?
Поворот на произвольный градус на лету. Немного в фотожабе и гимпе посидел, поэкспериментировал. Взял спрайт 32х цветный и начал его там крутить. Если каждый раз поворот спрайта производить из прошлого результата поворота, то качество с каждым разом ухудшается. Т.е. видимо, поворот нужно делать всегда от начального шаблона погруженного в память при старте программы. Да, забыл сказать, что поворот не на 128м экране. а на экране Спринтера. Соответственно спрайт цветной.
denpopov
06.08.2015, 10:00
насчет поворота - сам не занимался, но видел, что используются формулы:
x1=x*cos(f)-y*sin(f)
y1=x*sin(f)+y*cos(f)
Насчет туннеля - какой нужен туннель - точечный или другой?
насчет поворота - сам не занимался, но видел, что используются формулы:
x1=x*cos(f)-y*sin(f)
y1=x*sin(f)+y*cos(f)
Насчет туннеля - какой нужен туннель - точечный или другой?
Про туннель, видимо пиксельный. Там где текстурку на него натянуть можно. А какие ещё туннели бывают?
Из формулы - f видимо градус на который нужно повернуть?
x и y - координаты внутри спрайта?
x1 и y1 - координаты на экране?
denpopov
06.08.2015, 10:25
Из формулы - f видимо градус на который нужно повернуть?
x и y - координаты внутри спрайта?
x1 и y1 - координаты на экране?
Да, f-угол поворота, x1,y1 - результат
А какие ещё туннели бывают?
multidirectional например.
Sayman, если собрался поворачивать пиксельарт, то советую не терять ни одного пикселя при этом. Для этого можно поворачивать спрайт в 3 линейных сдвига. (линейные сдвиги, это как заставка уезжает в Comando Tracer).
Вот, значит. Сдвигаешь по горизонтали, потом по вертикали, потом опять точно так-же по горизонтали, и получается поворот, с сохранением цветовой плотности. При сдвигах пиксели не теряются. То есть операция обратима, и можно сдвинуть всё обратно как было.
denpopov
06.08.2015, 10:46
короче, rotozoomer ;)
denpopov, Ну, зума при этом не происходит. При сдвигах масштаб не меняется.
Sayman, Если заинтересует, то посчитаю таблицу коэффициентов сдвига. Может даже прототипчик напишу, если надо.
Reobne, если я верно понял, то в спрайте сдвигать нужно пиксельную карту. в зависимости от направления, двигаем в нужную сторону. сначала 3 раза по гор-ли. потом по вер-ли так? тогда как рассчитывается точность? 1 градус или 2 градуса это сколько сдвигов?
Вот, значит. Сдвигаешь по горизонтали, потом по вертикали, потом опять точно так-же по горизонтали, и получается поворот, с сохранением цветовой плотности. При сдвигах пиксели не теряются. То есть операция обратима, и можно сдвинуть всё обратно как было.
Не уверен, что это хорошая идея) По этому принципу работает chaos zoomer (классический амижный эффект). При этом:
1) Пиксели теряются
2) Нет возможности поворачивать на произвольный угол, только на некоторые фиксированные достаточно грубые углы.
вот такую статейку нашёл про поворот изображения:
http://softwarebydefault.com/2013/06/16/image-transform-rotate/
повернутость выводится процедурой, рисующей горизонтальные линии на экран, в которой расчитан путь этой линии по исходнику спрайта в памяти/текстуре (путь получается один и тот же, но разной длины и от разных начальных точек), или даже на лету генерится целая процедура вывода горизонтальной экранной линии спрайта именно под этот угол ;)
и ещё наскрёб:
http://eab.abime.net/showthread.php?t=29492
char, про линии по исходнику чуть не понял...
возьми листок бумаги/картинку, поверни на любой угол перед собой, справа на столе у тебя пусть лежит не повернутая листок-копия изображения, имитирующая исходник-спрайт в памяти компа, далее, поверх повернутого, - обычную деревянную линейку иль плашку и т.д., расположенную горизонтально, двигай сверху-вниз, перед тобой будут появляться линии изображения, которые необходимо отрисовать, отмечай начало и конец каждой линии на обоих листках...
сидеть, много думать :)
denpopov
06.08.2015, 15:25
с простыми линиями не попадешь в растр для поворота. /Инфа 146%
char, а ты пробовал это вариант?
я пробовал всё )
+ можно через fixed.point вычисления
+ можно увеличить спрайт в памяти и генерить процедуру движения по памяти прямо по целым байтам
Цель в результате или в искусстве кодинга (который большинство и не увидит)? Нарисуйте все фазы да выводите какую надо. В спринтере памяти много. :)
туннель:
газпром прокладывает рядом с твоим домом трубу, ты подходишь к трубе, заглядываешь в нее и фоткаешь, отпечатав фото, приходит понимание, что каждой точке на фото, всегда соответствует, другая уже физическая точка на трубе, независимо от того, какие перемещаемые вкладыши-текстуры в трубе будут куда-либо двигаться, однажды расчитанное соответствие точки на фотографии (экране) - точке в трубе всегда будет иметь место. для туннеля расчитывается массив таких точек-смещений (look up таблица, стретч, как варианты названий), при выводе туннеля к каждой точке из такого массива добавляется текущая одна и та же для всех константа смещения в текстуре.
creator, цель и то и другое. У спринтера не так много памяти, чтобы кидать 360 спрайтов одного объекта. если объектов несколько, да ещё и по габаритам нормальные, то и 4х метров не хватит.
---------- Post added at 19:52 ---------- Previous post was at 19:51 ----------
char, а где можно посмотреть на то. как работает твой метод? интересно, в отличие от методов с синусами и косинусами, должно работать значительно быстрее. опять-таки вопрос в качестве, как говорит денпопов - потери гарантированы?
Sayman, 360 фаз, да куда столько нужно? 12 (часы) хватит по уши.
да в любой деме с 3d-текстурированием... кубик в Spirius'е, та же вращалка в Illusion как пример процедурогенерации "на лету" под нужный угол...
creator, это для battle city хорошо делать повороты по 90, может даже 45 градусов. а мне нужно минимум точность в 2 градуса, чтобы точнее передать технику. возможности маневрирования и т.д.
и у меня есть ещё один корыстный замысел (в техническом смысле), о котором говорить не буду, но спрайтами делать не стоит.[COLOR="Silver"]
кубик в Spirius'е
посмотрел. жутко тормозит.
denpopov
06.08.2015, 19:10
а чё хаха?
Ты игру сам пишешь, или велосипед изобретаешь? проще найти утилитку и попробовать повертеть спрайты.
denpopov, спрайты вертеть можно и в фотожабе и в гимпе и в RotSprite (http://info.sonicretro.org/RotSprite), это всё не проблема. давно бы уже так сделал, если бы мне нужно было именно так.
Поворот спрайта Deja Vu #05
http://zxpress.ru/article.php?id=7903
Sayman, В WIN-PAINT есть функция "растянуть-наклрнить", так вот наклонить, это то о чём я говорю. Там-же можно и поэксперементировать.
Как посчитать коэффициенты.
K1=(cos(A)-1)/sin(A); K2=sin(A)
В паинт надо подставлять углы, значит нужно ещё взять арктангенс.
И за направлением наклона следить, есть два варианта, из них только один правильный.
Например, для поворота на 90 градусов, нужно сделать:
1. К1=-1; Наклон по горизонтали на -45 град.
2. К2=1;Наклон по вертикали на 45 град.
3. То-же что и 1. (К1=-1; Наклон по горизонтали на -45 град.)
Для поворота на 30 градусов:
1. К1=-0.268; Наклон по горизонтали на -15 град.
2. К2=0.5;Наклон по вертикали на 26.565 град.
Попробовал сам, и вижу, что, конечно, пиксели не теряются, но они немного тусуются с ближайшими соседями, и пиксельарт(на это не рассчитанный) сильно страдает.
Можно попробовать варьировать начало наклона, и подобрать наилучшее.
То есть наклонять можно по разному, с одним и тем-же углом. По разному округлять.
Прикрепил КВ, и он-же повёрнутый на 30 градусов.
Reobne, то как работает поворот в виндовых рисовалках - жаба, пайнт, гимп и другие, мне не ведомо. Скорей всего там жуткие формулы для улучшения качества. Некоторые мысли по этой теме уже есть благодаря ответам и собственным поискам. Однако, приведённые тобой скрины немного не ко мне, мне для цветных спрайтов, где цвет на точку, под спринтера. Кстати, вариант с линиями по идее должен на спринтере летать, т.к. линии-то тут аппаратные. Но тут другая заморочка связанная с тем, что при повороте линии уже не прямые, их нужно тоже наклонять, т.е. если наклоняем на сколько то градусов (не кратно 90), то получается нужно отрисовать часть линии на одной горизонтали, потом ниже и т.д., т.е. тоже нужно вычислять. хотя, надо как-то заготовить чтоли табличку этих преломлений, чтоли...
а чб спрайты это Вадиму на профика, но там ему и 45 и 90гр готовые спрайты пойдут.
Паинт - примитивная программа, она всё делает в лоб, как надо.
Цвет или не цвет особой разницы не играет. Только если не вычислять цвет пикселя взвешанным суммированием четырёх ближайших... :)
На спринтере я не умею, так что не буду приставать и мешать. :)
Паинт - примитивная программа, она всё делает в лоб, как надо.
Цвет или не цвет особой разницы не играет. Только если не вычислять цвет пикселя взвешанным суммированием четырёх ближайших... :)
На спринтере я не умею, так что не буду приставать и мешать. :)
да там уметь нечего. там графику выводить проще даже чем на 128м или на тсконфе.
creator, это для battle city хорошо делать повороты по 90, может даже 45 градусов. а мне нужно минимум точность в 2 градуса, чтобы точнее передать технику. возможности маневрирования и т.д.
и у меня есть ещё один корыстный замысел (в техническом смысле), о котором говорить не буду, но спрайтами делать не стоит.[COLOR="Silver"]
посмотрел. жутко тормозит.
ммм есть нюанс
без 3д железа ты быстро спрайты вертеть не сможешь
а с учетом того что ты хочешь
нагенерить кучу спрайтов тебе выйдет дешевле по памяти
чем вращать в реалтайме даже 2 объекта
кроме того каков размер 1го спрайта?
ммм есть нюанс
без 3д железа ты быстро спрайты вертеть не сможешь
а с учетом того что ты хочешь
нагенерить кучу спрайтов тебе выйдет дешевле по памяти
чем вращать в реалтайме даже 2 объекта
кроме того каков размер 1го спрайта?
размер одного спрайта около 2.8 - 3.5 кб. это пока примерно. я тут карту накидываю. всё идёт медленно т.к. я не художник и рисовать не умею. ищу где могу графику подходящую, конверчу прикидываю, подрисовываю и т.д. но по некоторым прикидкам - я взял несколько 128х дем где есть всякое вращение (кубики, ротозумеры и т.д.) и придавал эмулю ускорение примерно равную спринтеру. да там быстрее фрейма всё рисуется. а если ещё учесть, что есть аксель, то ну не медленнее должно быть. тем более, что вращение не всего экрана, а небольших спрайтов. получается, пока предварительно, спрайт корпуса для игрока, спрайт башни для игрока, и тоже самое для противника.
размер одного спрайта около 28 - 3.5 кб. это пока примерно. я тут карту накидываю. всё идёт медленно т.к. я не художник и рисовать не умею. ищу где могу графику подходящую, конверчу прикидываю, подрисовываю и т.д. но по некоторым прикидкам - я взял несколько 128х дем где есть всякое вращение (кубики, ротозумеры и т.д.) и придавал эмулю ускорение примерно равную спринтеру. да там быстрее фрейма всё рисуется. а если ещё учесть, что есть аксель, то ну не медленнее должно быть. тем более, что вращение не всего экрана, а небольших спрайтов. получается, пока предварительно, спрайт корпуса для игрока, спрайт башни для игрока, и тоже самое для противника.
не не
я про размер в точках
при размере спрайта меньше 32х32 повороты меньше чем на 11 градусов визуально не будут сильно отличаться друг от друга.
и сам повернутый спрайт в 60% случаев требует дорисовку.
так что поворот ты можешь делать какой хочешь
а спрайтов больше 32 тебе не нужно
не не
я про размер в точках
при размере спрайта меньше 32х32 повороты меньше чем на 11 градусов визуально не будут сильно отличаться друг от друга.
и сам повернутый спрайт в 60% случаев требует дорисовку.
так что поворот ты можешь делать какой хочешь
а спрайтов больше 32 тебе не нужно
ну вот ближайший вариант - 34ка с размерами 48на64. может ещё порежу чутка, но пока в таком виде. всякие тигры и ИСы чуть больше, более древние танки меньше (тот же пазик 2 или т-26).
Andrew771
07.08.2015, 16:21
Сделай спрайты из векторных линий и крути только два конца этих линий, а линию рисуй по этим двум точкам.
ну вот ближайший вариант - 34ка с размерами 48на64. может ещё порежу чутка, но пока в таком виде. всякие тигры и ИСы чуть больше, более древние танки меньше (тот же пазик 2 или т-26).
ты неправильно думаешь
не 48 на 64
а 64 на 64 а с учетом поворота на 45 градусов
даже 80х80
сколько по времени займет поворот спрайта 80х80?
ты неправильно думаешь
не 48 на 64
а 64 на 64 а с учетом поворота на 45 градусов
даже 80х80
сколько по времени займет поворот спрайта 80х80?
исходное состояние спрайта 48на64. изменение габаритов возможно в процессе разворота, но это не имеет отношение к его исходному состоянию. при повороте используется исходный спрайт, а не его изменённая (развёрнутая) копия.
хотя возможно для удобства можно сделать спрайт квадратным (пустое пространство заливать цветом прозрачности).
исходное состояние спрайта 48на64. изменение габаритов возможно в процессе разворота, но это не имеет отношение к его исходному состоянию. при повороте используется исходный спрайт, а не его изменённая (развёрнутая) копия.
хотя возможно для удобства можно сделать спрайт квадратным (пустое пространство заливать цветом прозрачности).
какой ты нудный а :)
ты под чо пишешь? под I7 core quatro?
или под спек с его 3.5/7/14 мгц
http://zx-pk.ru/attachment.php?attachmentid=53070&stc=1&d=1438961660
пофиг насколько ты поворачиваешь
сортирование 3072 точек займет определенное время
а максимальное искажение размера спрайта появляется когда он повернут на 45 градусов
кстати если интересно посмотри как сделан быстрый поворот в демке Refresh
раскранченая картинка 64*28 освежается примерно 60000 тактов и
весит соответсвенно
твое же натягивание совы на глобус займет минимум вдвое дольше.
shurik-ua
07.08.2015, 22:11
можно почитать про матчасть, а именно про аффинные преобразования - вот например небольшая статейка в тему:
http://robocraft.ru/blog/computervision/581.html
можно почитать про матчасть
Про матчасть лучше читать у Ла Мота (Андрэ Ла Мот "Секреты программирования игр". Ну да, конкретные реализации там на C на PC для DOS, но теоретические вопросы там объясняются очень подробно.
Сделай спрайты из векторных линий и крути только два конца этих линий, а линию рисуй по этим двум точкам.
Зачем это?
Andrew771
10.08.2015, 12:42
Зачем это?
Спрайт будет состоять из линий. У тебя расчет для поворотов будет только для концов линий, а сами линии будешь рисовать по этим рассчитанным двум точкам. Промежуточные точки на линии не надо рассчитывать.
Andrew771,
Я имел ввиду -- зачем считать каждую линию, да ещё дважды? Давай представим спрайт в виде параллельных линий. Тогда мы можем его рисовать линия за линией. Каждая линия, естественно, состоит из точек. Каждая последующая смещена относительно предыдущей, следовательно, чтобы поставить следующую точку достаточно знать на сколько нужно сместиться по у при смещении по х на 1 пиксель. Это смещение равно тангенсу угла наклона линии к горизонтали. Поскольку все линии параллельны, то у них один и тот же угол наклона, мы можем его посчитать один-единственный раз. А дальше прибавлять смещение, и если результат получится больше 1, уменьшать его на 1. Угол наклона -- это и есть угол поворота спрайта относительно начального положения. Он известен, берём тангенс из таблицы.
Для перехода к следующей строке нужно знать смещение её начала относительно предыдушей линии. Это есть котангенс нашего угла поворота. Тоже берём из таблицы (быстрее если у нас две таблицы, но можно обойтись и одной, сэкономив немного памяти).
Т. е. сложность - 2 извлечения из таблицы + суммирование и проверка для каждого пикселя.
Хранить, всё-таки, готовые спрайты для каждой фазы, но в пакованном виде. Не думаю, что распаковка займет больше времени, чем поворот.
Хранить, всё-таки, готовые спрайты для каждой фазы, но в пакованном виде. Не думаю, что распаковка займет больше времени, чем поворот.
Стандартные спрайты упакуются ну максимум в 2 раза. Выигрыш небольшой.
Стандартные спрайты упакуются ну максимум в 2 раза. Выигрыш небольшой.
а если вращать? насколько выгоднее будет?
я считаю что больше 16 фаз поворота смысла нет
автор хочет поворот на 1 градус
а ты как считаешь сколько займет по времени поворот чернобелого спрайта на произвольный угол?
ты как считаешь сколько займет по времени поворот чернобелого спрайта на произвольный угол?
вообще говоря, речь была про цветные спрайты. 8bpp...
вообще говоря, речь была про цветные спрайты. 8bpp...
ну тогда вообще вопросов нет
60000 тактов на спрайт размером 64х28
плюс процедура настройки ротатора
пошаговую стратегию делаешь? :)
а если вращать? насколько выгоднее будет?
а ты как считаешь сколько займет по времени поворот чернобелого спрайта на произвольный угол?
На Спеке по любому будет медленно)
пошаговую стратегию делаешь?
для начала надо просто их настроить для поворотов и вапще с графикой засада.
для начала надо просто их настроить для поворотов и вапще с графикой засада.
возьми картинку (любую) 64х64 и вращай
вернее тебе не вращать надо
а брать точки с одной плоскости и укладывать их в нужные места
на другой плоскости
http://zx-pk.ru/attachment.php?attachmentid=53134&stc=1&d=1439320847
на рисунке слева находится твой спрайт
далее ты вычисляешь точку куда будешь рисовать
и заодно приращения для координат Х и У
ну и рисуешь.
возьми картинку (любую) 64х64 и вращай
вернее тебе не вращать надо
а брать точки с одной плоскости и укладывать их в нужные места
на другой плоскости
http://zx-pk.ru/attachment.php?attachmentid=53134&stc=1&d=1439320847
на рисунке слева находится твой спрайт
далее ты вычисляешь точку куда будешь рисовать
и заодно приращения для координат Х и У
ну и рисуешь.
Школа ,по моему шестой класс - система полярных координат ,изменение угла... http://www.mathprofi.ru/poljarnye_koordinaty.html , в OVER THE TOP мы это делали в real time
https://youtu.be/WwD3SJDnPe4?t=200
https://zxaaa.untergrund.net/view_demo.php?id=8805
Andrew771,
Я имел ввиду -- зачем считать каждую линию, да ещё дважды? Давай представим спрайт в виде параллельных линий. Тогда мы можем его рисовать линия за линией. Каждая линия, естественно, состоит из точек. Каждая последующая смещена относительно предыдущей, следовательно, чтобы поставить следующую точку достаточно знать на сколько нужно сместиться по у при смещении по х на 1 пиксель.
Примерно, также мыслю.
Спрайт - прямоугольник с геометрическим центром в точке вращения. Впишем его в окружность. Таким образом, точка ЛВУ спрайта в в каждой позиции поворота будет принадлежать данной окружности.
Для каждого значения угла поворота строим таблицу, которая содержит:
1) координаты ЛВУ спрайта,
2) приращения по оси ординат для начальной левой точки каждой последующей горизонтальной линии спрайта относительно вышележащей линии,
3) приращения по оси ординат для каждой последующей точки горизонтальной линии спрайта,
4) Значение шага - число точек, после отрисовки которых пропускается точка в иходном спрайте.
Для чего нужен это шаг? - Пиксели в мониторе квадратные, а гипотенуза всегда длиннее любого из катетов. Поэтому во избежании искажения размеров спрайта при повороте придётся "прорежать" линии, чтобы их длина по диагонали визуально соответствовала горизонтальной линии. При этом изображение спрайта, конечно, пострадает. Хотя, наверное, можно пойти по другому: добавлять точки по мере приближения к горизонтали.
Углов поворота, кстати, не может быть больше, чем число пикселей, лежащих на окружности, в которую вписан спрайт.
А выбор оси приращений и направления рисования в зависимости от положения ЛВУ, думаю, сходен с таковым для рисования окружностей.
Тут быстрее будет показать на примере
надо будет подумать.
наверное позже
под ТС конфу сделаю.
Тут быстрее будет показать на примере
надо будет подумать.
наверное позже
под ТС конфу сделаю.
Тут главная рутина таблички состряпать.
Тут главная рутина таблички состряпать.
какие там таблички?
синусоида?
какие там таблички?
синусоида?
1) координаты ЛВУ спрайта,
2) приращения по оси ординат для начальной левой точки каждой последующей горизонтальной линии спрайта относительно вышележащей линии,
3) приращения по оси ординат для каждой последующей точки горизонтальной линии спрайта,
4) Значение шага - число точек, после отрисовки которых пропускается точка в исходном спрайте.
Кстати о синусоиде - вспомни свою козявилку для Inferno. Мож, покатит?
Sergey
это все вычисляется, хотя да можно использовать и предрассчитанные данные
4 это лишнее
1 координаты угла
2 смещение при отрисовке
3 смещение при переходе на новую линию
а дальше берем точки и укладываем по порядку.
соответственно шагу.
на тему того, что быстро или нет может быть на спринтере, вот тут (http://zx-pk.ru/showpost.php?p=822007&postcount=1498) как пример, хотя там типа 3д...
ещё на это (http://zx-pk.ru/showpost.php?p=816786&postcount=1494)можно посмотреть...
Sayman, во первых тот Вулф который нарисован добивается спецконфой железа. и рисуется акселератором
тем есть какието спецкоманды в том числе рисование вертикальных линий.
а вот насчет 3д спрайтов я уже не уверен
jerri, там спецпрошивка под doom (а не Вулф) отличается только одной командой в акселе - растяжение пикселя на заданный масштаб. Алгоритм там простой - в порт растяжения указывается масштаб, включается команда акселя и делается вывод. Кроме того, в стоке у спринтера и без этой спецпрошивки есть команды для работы с линиями (вертикальные и горизонтальные). Т.е. всё остальное в демке дума производится стоковыми средствами, только масштабирование там добавлено было и всё.
про 3д, а в чём не уверенность? исходника этой демки (3д) у меня нет, сказать как там оно работает не могу.
Тут быстрее будет показать на примере
надо будет подумать.
наверное позже
под ТС конфу сделаю.
Блииин. Прикинул, для ТС-Конфы только расчет адреса по координатам займёт тактов 80. Т.е. на точку будет не менее 200 тактов. А при размере 64x64 - 819200 тактов на спрайт. Даже при реальных 14МГц - 280 тыс.тактов за фрейм, на отрисовку поворота уйдёт 3 фрейма. :(
для ТС-Конфы только расчет адреса по координатам займёт тактов 80
расчёт всмысле в экране? в этом плане у спринтера всё в порядке. расчёты не нужны. если нужна координата по X, скажем 100, то это будет адрес начала строки + нужная координата. Для Y достаточно сделать in a,(port_y).
расчёт всмысле в экране? в этом плане у спринтера всё в порядке. расчёты не нужны. если нужна координата по X, скажем 100, то это будет адрес начала строки + нужная координата. Для Y достаточно сделать in a,(port_y).
Ну, тогда имеет смысл попробовать.
jerri, там спецпрошивка под doom (а не Вулф) отличается только одной командой в акселе - растяжение пикселя на заданный масштаб. Алгоритм там простой - в порт растяжения указывается масштаб, включается команда акселя и делается вывод. Кроме того, в стоке у спринтера и без этой спецпрошивки есть команды для работы с линиями (вертикальные и горизонтальные). Т.е. всё остальное в демке дума производится стоковыми средствами, только масштабирование там добавлено было и всё.
про 3д, а в чём не уверенность? исходника этой демки (3д) у меня нет, сказать как там оно работает не могу.
ну прошивка то может и под дум. а в ролике Вульф галимый :)
а рисуется все акселем.
И те демки что я видел растягивают пикселя по вертикали.
с поворотом ничего не видел.
---------- Post added at 19:35 ---------- Previous post was at 19:34 ----------
Блииин. Прикинул, для ТС-Конфы только расчет адреса по координатам займёт тактов 80. Т.е. на точку будет не менее 200 тактов. А при размере 64x64 - 819200 тактов на спрайт. Даже при реальных 14МГц - 280 тыс.тактов за фрейм, на отрисовку поворота уйдёт 3 фрейма. :(
тебе надо поворачивать не точку а спрайт. а это уже совершенно другой процесс.
ну прошивка то может и под дум. а в ролике Вульф галимый :)
а рисуется все акселем.
и где ты там вульфа увидел?
http://www.youtube.com/watch?v=HtmqkuazNaE&feature=player_detailpage[/url]]http://www.youtube.com
Акселем там в любом случае любая графика на вывод. хоть дум, хоть не дум. при повороте спрайта меня только математика смущает. вывод же самих точек пока не напрягает.
и где ты там вульфа увидел?
http://www.youtube.com
в вулфе карта состоит из текстурированных кубиков.
в думе карта состоит из плоскостей.
в думе были стены не под 90 градусов.
Акселем там в любом случае любая графика на вывод. хоть дум, хоть не дум. при повороте спрайта меня только математика смущает. вывод же самих точек пока не напрягает.
хмм вывод акселем это как раз самое главное.
в вулфе карта состоит из текстурированных кубиков.
в думе карта состоит из плоскостей.
в думе были стены не под 90 градусов.
вот где собака порылась. ну чисто теоретически - в вульфе тоже плоскости, только стоят под 90гр все))) как никрути, но "кубы" мы видим там редко. да и представление в игре не кубиеское, а "плоское". по другому не могу выразится. Собственно говоря, я думаю что в нашем думе можно тоже делать стены не только под 90гр. вопрос только в том, что нужно залезать в исходники и смотреть что там и как. я особо пока не горю желанием это делать. попробовал тут в начале года, понял. что там нужно много времени потратить. Если есть желание у кого-то ещё, могу расшарить всё что есть по думу, может кто доведёт его до играбельного вида?
касательно сабжа (разворот спрайта) как ту говорили - "система полярных координат". такими темами я не могу пока оперировать. если с точки зрения бы кода, скажем на сях или подобном, я бы наверно смог понять. А так, читаю, что-то понимаю, но как применить к графике, к пикселям. не могу сообразить что-то.
... если с точки зрения бы кода, скажем на сях или подобном, я бы наверно смог понять.
Если на сях, вот, скачай исходники Делюкс Пэнт. там есть процедура ROTATE. ;)
http://www.computerhistory.org/atchm/electronic-arts-deluxepaint-early-source-code/
CodeMaster
13.08.2015, 08:59
касательно сабжа (разворот спрайта)
А по памяти там сильно критично, может просто подготовленные спрайты с поворотами по 5 градусов? Посмотрел я спрайт танка в графредакторе, при такой пикселизации, эти произвольные повороты выглядят не очень (хотя, может быть в динамике и никто внимания не обратит) и спрайты надо бы "причесать" было. А небольшие фиксированные углы не заметны на глаз, да и к тому же не далеко от реальности, танк не машина, он так плавно не поворачивает.
А по памяти там сильно критично, может просто подготовленные спрайты с поворотами по 5 градусов? Посмотрел я спрайт танка в графредакторе, при такой пикселизации, эти произвольные повороты выглядят не очень (хотя, может быть в динамике и никто внимания не обратит) и спрайты надо бы "причесать" было. А небольшие фиксированные углы не заметны на глаз, да и к тому же не далеко от реальности, танк не машина, он так плавно не поворачивает.
360 гр/5 = 72 спрайта. 72*на размер одного (в мреднем) спрайта = 258048байт на описание одного танка. и это только корпус. ещё башня. она конечно будет меньше занимать, но всё ровно, плюсуем ещё половину. итого на 1 танк в целом нужно 390 - 400кб. в целом не плохо. можно подумать про 5гр. просто хотелось бы именно реалтайм, типа, технологично и всё такое.
---------- Post added at 12:34 ---------- Previous post was at 12:30 ----------
кстати, ближайший пример игры со спрайтами повёрнутыми на толи 5 толи 15 градусов - стратегия Противостояние.
CodeMaster
13.08.2015, 13:44
итого на 1 танк в целом нужно 390 - 400кб.
Это несжатое, плюс надо разделить на 4, т.к. зеркалирование одной четверти в остальные три делается быстро.
хотелось бы именно реалтайм, типа, технологично и всё такое.
Только если не пострадает геймплей. Если это начнёт лагать, то всю технологию заплюют, а если это будет интересный геймплей с хорошей управляемостью, то на разницу между 1 или 5 градусами никто не заметит.
360 гр/5 = 72 спрайта.
Зачем так много? Достаточно 90 градусов, остальное просто зеркалить.
кстати, ближайший пример игры со спрайтами повёрнутыми на толи 5 толи 15 градусов - стратегия Противостояние.
Заметь, что даже на персоналке, которая явно побыстрее Спринтера, все спрайты прорисованы заранее и никто ничего не поворачивает. Я вообще не припомню ни одной игры с произвольным поворотом спрайтов.
16 заранее отрисованных спрайтов - более чем достаточно для Спектрума. Поворот в реальном времени невозможен в приемлемое время.
Да зачем крутить,лучше такты оставить на гемплей и музыку. обычных готовых спрайтов наделать и по мере необходимости подгружать с винта .типа один левел немцев мочишь,другой левел совок. короче фантазия заменит нехватку озу и тактов.
... зеркалирование одной четверти в остальные три делается быстро.
Изображения танков в спрайте АССИМЕТРИЧНЫ. :)
CodeMaster
13.08.2015, 14:39
Изображения танков в спрайте АССИМЕТРИЧНЫ.
Да, это будет не чистое зеркалирование в одно действие, но всё-равно достаточно простые вычисления.
Это несжатое, плюс надо разделить на 4, т.к. зеркалирование одной четверти в остальные три делается быстро.
Зачем так много? Достаточно 90 градусов, остальное просто зеркалить.
С танками зеркалирование не катит. Во-1х, крайне не красиво выглядит момент. когда пулемёт был слева, а потом вдруг он стал справа. Или ещё хуже, когда их будет два и всего остального тоже по 2. не, не годится. Есть игрушка такая - Генералы Второй Мировой на РБК Гамес. Посмотрите ка ктам работает. Игра на Флэше. Там как раз зеркалирование. Глупо выглядит.
Я согласен с тем, что по 5 гр. может хватить. 72 спрайта для поворота корпуса и столько же для башни. башня отдельно. Нужно обозначить опорные точки для крепления башни. Пусть даже 512кб (округляем на всякий случай) будет весь танк со всеми поворотами корпуса и башни. Тогда получается, что на уровне можно разместить 1 танк для игрока и 2 или 3 разных танка для противника. Противников может быть больше, просто некоторые из них будут на одинаковых танках. Можно и больше, тут подумать надо да методом проб и ошибок смотреть как оно будет. Самая проблема для меня - графика. Приходиться извращаться с блендером, дёргать из разных источников модели да извращаться с рендером. Я с блендером плохо дружу, мне бы под макса или майку, давно бы уже наделал. Или дайте мне кто-нить художника умеющего рисовать в цвете (цвет на точку).
---------- Post added at 17:53 ---------- Previous post was at 17:47 ----------
Блин, противостояние плохой пример, там же изометрия
если делать спрайтами, тогда изометрия тоже пойдёт. Изначально я предполагал делать именно в изометрии и спрайтами. Даже наброски некоторые делал. Но потом подумал, вид сверху (top down) и реалтайм. Скатит за техдему как раз. Но сейчас возвращаюсь к теме изометрии. Только получаестя один вопрос - вопрос жанра. Изначальный вариант - пошаговая стратегия. Потом осознав, что с графикой совсем всё плохо (всмысле не мог достать нужные спрайты в изометрии) решил, то top down тоже не плохо. Тогда не стратегия, а управляем одним танком. Управление корпусом от клавы, мыша башня. Набросков не делал. Но графику нашёл кой какую, хоть и статичную, но от того и решил, что найду статичные спрайты top down и делать в реалтайме повороты. Но раз вы все настаиваете на тормозах, хорошо. соглашусь (пока что). Тогда возвращаясь к изометрии - или это аналог Генералов (стратегия пошаговая с элементами рпг) или управляем одним танком от клавы и мыши. Я пока к этому варианту склонен. Тут хоть танковать можно)))
Но сейчас возвращаюсь к теме изометрии.
Если изометрия, то тогда в любом случае спрайты нельзя вращать. Только отрисовка кадров.
Ну вот что я имел ввиду
под вращением в реалтайме
спрайт размером 64х48
максимально быстрое вращение
потому и артефакты.
~120 000 тактов.
Ну вот что я имел ввиду
под вращением в реалтайме
а можно спросить - под какую конфу написано? под тс или baseconf (atm3)?
и если можно, исходник?
а можно спросить - под какую конфу написано? под тс или baseconf (atm3)?
и если можно, исходник?
TSconf разумеется.
исходник можно но он не очень читабельный
jerri, по какому алгоритму делаешь там вращение?
jerri, по какому алгоритму делаешь там вращение?
предрассчитанные координаты для 224 позиций
беру 3 точки на круге
и рисую тектурированные линии.
алгоритм линии самый быстрый
Не уверен, что это хорошая идея) По этому принципу работает chaos zoomer (классический амижный эффект). При этом:
1) Пиксели теряются
2) Нет возможности поворачивать на произвольный угол, только на некоторые фиксированные достаточно грубые углы.
Ну, это-же хаос:)
А если этот принцип применить для вращения, то:
1) Пиксели не теряются.
2) Можно поворачивать на любой угол.
Матрица поворота:((c,s),(-s,c)), где: c==cos(alpha), s==sin(alpha)
Матрица сдвига по x:((1,k),(0,1))
Матрица сдвига по y:((1,0),(k,1)), где: k - коэффициент сдвига, он-же тангенс угла сдвига.
Три матрицы сдвига, которые обеспечивают поворот на угол:
((1,0) , (k1,1))*
((1,k2) , (0,1))*
((1,0) , (k1,1)), где k1==(c-1)/s, k2==s
Звёздочки - матричное умножение :), перемножьте эти 3 матрицы, и получите матрицу поворота.
Ну а сдвиг-то сделать легко, и пиксели никуда не теряются и ниоткуда не берутся (размер для пикселей обеспечить надо). Просто сдвигаем столбики/строчки.
Это только математика, вариантов её применения - масса.
denpopov
20.08.2015, 10:28
chaos zoomer основан на другом алгоритме и он неуместен к повороту спрайта.
В 3д играх на пц используются матричные преобразования, а для вращения используются кватернионы. С помощью них можно удобно складывать углы вращения и потом одним кватернионом производить сразу все повороты.
ZXMAK, ты это... пальцем покажи.
Кватерионы это же в трёхмерном пространстве, где 3 оси вращения. А разговор о 2d-движке, где одна ось. Зачем тут кватерионы?
Barmaley_m
29.09.2015, 00:54
Вращение битмапа на произвольный угол - это задача интерполяции функции от двух переменных. И она не имеет "правильного" решения, потому как значения исходной функции не заданы между пикселями исходного битмапа. Любой метод интерполяции будет исходить не из "настоящего" изображения, которое должно быть, а из каких-то допущений о том, каким оно могло бы быть. Отсюда неоднозначность.
Во-вторых, пиксельная графика обычно оптимизирована под конкретную сетку пикселей, так что, даже если бы непрерывная функция, соответствующая изображению, была известна во всех точках - попытка взять ее отсчеты после поворота приведет, как правило, лишь к посредственному результату, если речь идет о спрайтах с низким разрешением.
Поэтому вращать спрайты лучше вручную. Можно попытаться сначала их повернуть на PC с помощью фотошопа или другой аналогичной программы, и использовать результат такого поворота как ориентир для ручной прорисовки.
Powered by vBulletin® Version 4.2.5 Copyright © 2026 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot