Спрайты

[ivagor]

В продолжение закадровой дискуссии про новую обработку приращений по X и Y. Все же вариант с "задержками" на мой взгляд менее гибкий и плавный по сравнению с фиксированной точкой. Например приращение 1.25 (5/4) в варианте с задержками будет приводить к рывкам на 5 точек с заметными паузами между ними, а при использовании фиксированной точки будут 3 приращения на 1 и одно приращение на 2, т.е. заметно плавнее.

[tnt23]

Мне представлялось оправданным использовать набор фиксированных углов вместо произвольных. Вырожденный вариант, понятно, только 1 к 1 (45 градусов), более играбельный - наборы 1/2, 1/3, 1/4 и 1/5. Можно подобрать максимально точно аппроксимирующие углы, кратные 15 градусам.

Вопрос плавности движения остается открытым.

[ivagor]

В данном случае лучше оперировать конкретными цифрами. Прикинул на матлабе.
Углы от 0 до 90 градусов с шагом 15: 0 15 30 45 60 75 90
Синусы этих углов: 0 0.2588 0.5000 0.7071 0.8660 0.9659 1.0000
Косинусы: 1.0000 0.9659 0.8660 0.7071 0.5000 0.2588 0.0000
Приблизительные аппроксимации дробями (для синусов, для косинусов, понятное дело, аналогично, но в другом порядке): [0 1/4 1/2 8/11 19/22 1 1]
Хочу обратить внимание, что 8/11 и 19/22 будут плохо (и очень плохо) обрабатываться с "задержками" и вполне приемлемо с фиксированной точкой, по крайней мере с точностью дробной части в байт. Для такой точности можно даже и получше аппроксимировать.

- - - Добавлено - - -

Вместо 8/11 и 19/22 можно использовать 3/4 и 4/5, но это все равно плохо.

[tnt23]

По-моему, это интуитивно все то же рисование по Брезенхему, иносказательно.

Почему вариант с задержками будет тормозить, не пойму.

(16-битная арифметика в 8080 так себе)

[ivagor]

Это скорее DDA
Про тормоза я не говорил, но я писал про рывки с паузами в случае использования "задержек" для дробей вида 3/4, 4/5 и тем более 8/11 и 19/22, т.е. у которых числитель (величина "рывка") много больше единицы (знаменатель, который фактически "задержка", конечно еще больше, т.к. мы говорим о дробях <=1, а дроби >1 легко получить масштабированием).

[tnt23]

ivagor, спасибо за ссылку на DDA, почитаю-подумаю.

Будучи выраженным аудиовизуалом, накликал пикселей в graf (https://github.com/timtashpulatov/ok...aster/graf.asm), чтобы лучше осмыслялось:



Я правильно понимаю, что других способов растеризации траектории мячика, движущегося равномерно и прямолинейно, кроме приведенных на картинке исчезающе мало? И вопрос только в том, нужны ли здесь операции с фиксированной точкой (я вовсе не против их попробовать) или, поскольку результат один фиг растровый, можно сразу обойтись восьмибитными целыми.

[Advertiser]

[ivagor]

tnt23, я не понял, что ты нарисовал. Можно визуализировать лучи с шагом 15 градусов по вышеприведенным приращениям, только программировать не хочется.

[tnt23]

Я нарисовал траектории движения объекта (пикселя или спрайта) для разных соотношений dx/dy. Снизу вверх: 2/1, 3/1, 4/1 и 5/1.

- - - Добавлено - - -

Пришлось полезть в гугл за воспоминаниями об арктангенсе. Соответствующие вышеприведенным соотношениям углы вышли 26, 18, 14 и 11 градусов. Набор более живенький, чем просто 45

[svofski]

Мячик отлетает как шальной, поэтому может быть есть смысл сделать какой-то разумный минимум и сфокусироваться на других аспектах игры. А детализацию углов оставить на потом, если хватит сил.

Есть важный аспект, он вроде как-то всеми подразумевается, но я не уверен, что все было проговорено вслух. Шарик имеет широкий диапазон скоростей. От вообще чуть ли не пиксель на кадр (если объесться (-S-) ) до омгвтфbbq что это было. Это усложняет использование алгоритма Брезенхема, хотя не запрещает: вместо интервала времени между шагами равного единице берем дробный интервал (насколько я понимаю, это то, что ivagor называет вариантом с задержками). Если шарик делает больше пикселя за кадр, что по-моему очень часто случается, понадобится по нескольку итераций на кадр.

DDA может быть предпочтительней, потому что можно учесть все сразу в коэффициентах и считать координаты за одну итерацию на кадр. Это немного невосьмибитно, но 16-битное сложение не такое уж страшное у 8080.

Я думаю, что взвесив все, я бы сделал что-то среднее. DDA рассчитывать для минимальной скорости, а скорость -- это будет число итераций DDA на кадр. В этом случае коэффициенты должны поместиться в 8 бит и вообще вся арифметика 8-битная. При том, что углы наклона дискретные, все коэффициенты могут быть просчитаны заранее и забиты в код уже в виде готовых констант.

Псевдокод, совсем не похожий на Си. Входные данные: x_direction, y_direction ∈ [-1,1], dda_table_x[], dda_table_y[] - коэффициенты приращений такие, что [0,1) -> [0,255). angle_index - индекс угла в табличке коэффициентов. Подразумевается, что строго горизонтальные и строго вертикальные полеты мяча невозможны. ball_x, ball_y - координаты мяча.

for (int i = 0; i < speed; ++i) {
    x_accu += dda_table_x[angle_index];
    if (x_accu & 0x100) { /* carry */
        ball_x += x_direction;
        x_accu &= 0xff; /* clear carry */
    }

    y_accu += dda_table_y[angle_index];
    if (y_accu & 0x100) { /* carry */
        ball_y += y_direction;
        y_accu &= 0xff; /* clear carry */
    }
}

Я практически уверен, что вместо dda_table_x[] и dda_table_y[] и одного индекса угла, можно сделать dda_table[] и два индекса угла. Но это будет оптимизация шкуры неубитого медведя, поэтому пока в сторону.

[ivagor]

Озвучу, то что я предлагал tnt23 - использовать арифметику с фиксированной точкой в варианте байт целый и байт дробный, т.е. фактически дробные числа для перевода в этот формат нужно умножить на 256. Например .75*256=192, 12.345=примерно 3160 и т.д. Для позиционирования при отрисовке используем только целую часть, т.е. старший байт. Единственная 16-битная операция, которая требуется - сложение. И так удачно получилось, что у 8080 есть команда dad. Надо ли писать пример?