ЭТЮДЫ

[Reobne]

спасибо всем откликнувшимся - задача для меня решена )

Ещё, на всякий случай, озвучу такую мысль:
Можно попробовать оптимизировать. Перед тем как вычислять сумму квадратов разностей, то есть попадание в окружность, можно сразу отсеять то, что не попадает в описанный квадрат. Как бы:
DX:=abs(x1-x2);
IF DX>R THEN EXIT;
DY:=abs(y1-y2);
IF DY>R THEN EXIT;
IF SQR(DX)+SQR(DY)>R2 THEN EXIT;

[shurik-ua]

да про это я подумал

function in_range(x1,y1,x2,y2,range: dword):boolean;
var
  dx,dy: dword;
begin
  result:=false;
  if x1>x2 then dx:=x1-x2
  else dx:=x2-x1;
  if dx > range then exit;
  if y1>y2 then dy:=y1-y2
  else dy:=y2-y1;
  if dy > range then exit;
  if (range*range) > dx*dx + dy*dy then result:=true;
end;

[LW]

забыл добавить - всё это нужно для целых чисел
существует ли такая формула без извлечения корня ?

для таких задач можно использовать алгоритм приближенного вычисления гипотенузы

гипотенуза = maxКатет + 0.41 * minКатет (насколько помню, погрешность около 5%)

либо другой вариант, точнее, но и затратнее по тактам

гипотенуза = maxКатет + 0.428 * minКатет * minКатет / maxКатет (погрешность около 1%)

[ALKO]

Хотел спросить по табличкам SIN-COS вращения относительно игрока.



В каком виде их оптимальнее всего хранить? Ну, в смысле, неужели надо множество окружностей диаметром с итерацией от центра к краю хранить ? Или можно как-то более экономно. Знаю, что можно ещё на четвертинке сэкономить.

[blackmirror]

Окружности скорее всего рисуются вообще без всяких таблиц. А если синусов и косинусов считать нужно много, значит в табличках должны быть указатели на функции которые будут выполнять умножение радиуса на константу соответствующую синусу заданного угла. Это как таблица из 256 функций выполняющих умножения на всевозможные значения байта, только ячейки вне заполнены так, чтобы умножение происходило на значения синуса.

[ALKO]

Окружности скорее всего рисуются вообще без всяких таблиц.

Я имею ввиду окружности позиционирования объектов относительно игрока.

[LW]

А собственно зачем их хранить?
В игровом пространстве объекты перемещаются согласно своему алгоритму, игрок перемещается так вообще непредсказуемо.
Всё это рассчитывается из координат объекта и игрока.

[ALKO]

Решился наконец-то на покорение 128к формата.
По крайней мере теневой экран удалось заюзать.
Но в итоге доступной памяти стало на 16кб меньше, ибо переключаемую банку только для экрана и использую каждый кадр. Поэтому пришлось и стэк переместить, и своих данных туда уже не затолкать (разве что дублировать на обе банки)
И вот назрел вопрос, как затолкать графику в виде DEFB массивов хотя бы в остальные банки?
Org ведь не может превышать 65535
Да и как её потом оттуда извлекать?

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

А собственно зачем их хранить?
В игровом пространстве объекты перемещаются согласно своему алгоритму, игрок перемещается так вообще непредсказуемо.
Всё это рассчитывается из координат объекта и игрока.

В игровом пространстве многое предсказуемо, даже псевдо-рандом.

Зачем их хранить? Во благо скорости, разумеется.

перемещаются согласно своему алгоритму

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

[Destr]

И вот назрел вопрос, как затолкать графику в виде DEFB массивов хотя бы в остальные банки?
Org ведь не может превышать 65535

Обычно компилятор понимает такое:

Page n                      ; n=номер нужной страницы
org #c000                   ; начало страничной области
incbin "graphic.scr"        ; ну или твои DEFB

Потом или вернуть страницу (и ORG) куда надо или просто ставить эту конструкцию в конце листинга кода...

[ALKO]

Чем больше представляю себе грядущий гемор, тем больше хочется вернуться в блаженные 48к.
Тут же в распоряжении лишь одно активное окно, которое и в роли фрейм-буфера, и в роли хранилища данных... Ух. Сложновато.
Наверное погорячился я с тем, что сунулся в эти дебри.