Спрайты

[ivagor]

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

[Advertiser]

[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. Надо ли писать пример?

[svofski]

ivagor, а как учитывается скорость мячика?

[tnt23]

Для позиционирования при отрисовке используем только целую часть, т.е. старший байт. Единственная 16-битная операция, которая требуется - сложение. И так удачно получилось, что у 8080 есть команда dad. Надо ли писать пример?

Я б взглянул.

[ivagor]

Вот эти 0.75 или 12.345 - это и есть скорость шарика по одной из координат.

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

Подумал, что возможно ты разделяешь угол и скорость и про скорость спросил в этом смысле. Фактически я про это уже написал раньше, когда перечислял косинусы и синусы, которые <=1, а разные скорости можно получить масштабируя (делением или умножением или даже по таблице) эти коэффициенты.

[svofski]

То есть масштабируя, внося таким образом скорость в коэффициенты.

У моего третьего варианта с псевдокодом по-моему есть пара важных преимуществ по сравнению с более "прямолинейными" подходами: все предварительные расчеты делаются на этапе компиляции, все сложения 8-битные + перенос. Очевидный недостаток - итеративность. Может быть например получится слишком много итераций в среднем, тогда 16-битный FP и сложные предварительные расчеты окажутся более практичными.

[ivagor]

svofski, у тебя фактически тоже арифметика с фиксированной точкой, но частный случай, когда коэффициенты <1. И масштабирование ты делаешь сложением вместо умножения или набора таблиц (я бы сам скорее всего сделал набором таблиц, по крайней мере в ротозумере именно так делал). В сухом остатке одно значимое отличие - 8-битное сложение вместо 16-битного. На мой взгляд оно того не стоит - некоторое усложнение и замедление (когда скорость>1) программы в обмен на 8-битные таблицы, но это только мое мнение.

[svofski]

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

Таблицы это не обязательно, просто с ними получается короче путь до первого осязаемого результата.