Вид для печати
В продолжение закадровой дискуссии про новую обработку приращений по X и Y. Все же вариант с "задержками" на мой взгляд менее гибкий и плавный по сравнению с фиксированной точкой. Например приращение 1.25 (5/4) в варианте с задержками будет приводить к рывкам на 5 точек с заметными паузами между ними, а при использовании фиксированной точки будут 3 приращения на 1 и одно приращение на 2, т.е. заметно плавнее.
Мне представлялось оправданным использовать набор фиксированных углов вместо произвольных. Вырожденный вариант, понятно, только 1 к 1 (45 градусов), более играбельный - наборы 1/2, 1/3, 1/4 и 1/5. Можно подобрать максимально точно аппроксимирующие углы, кратные 15 градусам.
Вопрос плавности движения остается открытым.
В данном случае лучше оперировать конкретными цифрами. Прикинул на матлабе.
Углы от 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, но это все равно плохо.
По-моему, это интуитивно все то же рисование по Брезенхему, иносказательно.
Почему вариант с задержками будет тормозить, не пойму.
(16-битная арифметика в 8080 так себе)
Это скорее DDA
Про тормоза я не говорил, но я писал про рывки с паузами в случае использования "задержек" для дробей вида 3/4, 4/5 и тем более 8/11 и 19/22, т.е. у которых числитель (величина "рывка") много больше единицы (знаменатель, который фактически "задержка", конечно еще больше, т.к. мы говорим о дробях <=1, а дроби >1 легко получить масштабированием).
ivagor, спасибо за ссылку на DDA, почитаю-подумаю.
Будучи выраженным аудиовизуалом, накликал пикселей в graf (https://github.com/timtashpulatov/ok...aster/graf.asm), чтобы лучше осмыслялось:
Вложение 68719
Я правильно понимаю, что других способов растеризации траектории мячика, движущегося равномерно и прямолинейно, кроме приведенных на картинке исчезающе мало? И вопрос только в том, нужны ли здесь операции с фиксированной точкой (я вовсе не против их попробовать) или, поскольку результат один фиг растровый, можно сразу обойтись восьмибитными целыми.
tnt23, я не понял, что ты нарисовал. Можно визуализировать лучи с шагом 15 градусов по вышеприведенным приращениям, только программировать не хочется.
Я нарисовал траектории движения объекта (пикселя или спрайта) для разных соотношений dx/dy. Снизу вверх: 2/1, 3/1, 4/1 и 5/1.
- - - Добавлено - - -
Пришлось полезть в гугл за воспоминаниями об арктангенсе. Соответствующие вышеприведенным соотношениям углы вышли 26, 18, 14 и 11 градусов. Набор более живенький, чем просто 45 :)
Мячик отлетает как шальной, поэтому может быть есть смысл сделать какой-то разумный минимум и сфокусироваться на других аспектах игры. А детализацию углов оставить на потом, если хватит сил.
Есть важный аспект, он вроде как-то всеми подразумевается, но я не уверен, что все было проговорено вслух. Шарик имеет широкий диапазон скоростей. От вообще чуть ли не пиксель на кадр (если объесться (-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 - координаты мяча.
Я практически уверен, что вместо dda_table_x[] и dda_table_y[] и одного индекса угла, можно сделать dda_table[] и два индекса угла. Но это будет оптимизация шкуры неубитого медведя, поэтому пока в сторону.Код: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 */
}
}
Озвучу, то что я предлагал tnt23 - использовать арифметику с фиксированной точкой в варианте байт целый и байт дробный, т.е. фактически дробные числа для перевода в этот формат нужно умножить на 256. Например .75*256=192, 12.345=примерно 3160 и т.д. Для позиционирования при отрисовке используем только целую часть, т.е. старший байт. Единственная 16-битная операция, которая требуется - сложение. И так удачно получилось, что у 8080 есть команда dad. Надо ли писать пример?