Вид для печати
Попробуйте все показатели движения умножить, например, на 32. Далее вести расчёты в целых числах, и только перед передачей значений графическим процедурам делить их на 32...Цитата:
Сообщение от S_V_B
Тогда, скорее всего, акромя целочисленной таблицы синусов ничего и не понадобиться из монструозного :)
Насколько я понимаю в этом смысл арифметики с фиксированной точкой, хотя я поступил проще и сделал s15.16 что гораздо быстрее но все равно очень медленно :(Цитата:
Сообщение от TheGWBV
Смысл в том, что УКНЦ ни при каких раскладах не потянет такое количество параметров (с тормозной графикой.. и медленным рисованием линий).
Я про векторный дисплей не просто упомянул:)
- - - Добавлено - - -
Если вы заметили в примере программы который я привел выше, размеры кораблика несколько гуляют.. не хватает точности.. и это при 16ти бит после запятой.. ,а вы говорите раздели на 32.
Сначала умножить на 32 :)
Потом считать в целых числах (без потери точности).
И уже затем, на самой последней стадии, подготовить реальные координаты графического примитива, поделив относительные (и более точные, в другом масштабе) целочисленные координаты на 32. Погрешность, в любом случае не меньше +-1 пиксель :) Вдруг, при таком способе и не больше ;)
Просто представьте, что у вас (виртуальный) экран размером (640*32)х(350*32), а не 640х350, например. И доступны только целочисленные вычисления.
А в самом конце, вы всё это масштабируете в окно 640х350, простым делением координат точек на 32...
- - - Добавлено - - -
Да, кстати, подобрать масштабную сетку, и отработать целочисленную математику векторов, может быть проще в Бейсике? :)
И уже потом мучать себя ассемблерами))
И получается какка :)Цитата:
Сообщение от TheGWBV
Я о чем выше распинался?... У меня вся арифметика s15.16 и то огромная потеря точности. Вы мне глаза хотите открыть что 5 бит лучше 16ти?Цитата:
Сообщение от TheGWBV
- - - Добавлено - - -
Если вы такой знаток Васика, пожалуйста изобразите, что хотели сказать.. плавное вращение (без скачков пикселей) в пять бит :)Цитата:
Сообщение от TheGWBV
Лучше, чем когда фиксированная точка используется влоб, без учёта потери точности вычислений на каждой из операций расчёта :)Цитата:
Сообщение от S_V_B
- - - Добавлено - - -
Чего там такого нужно знать в Васике?
Просто указываете, что переменные целочисленные явным образом))
Всё остальное - чистая начертательная геометрия))
Пока сам не споткнешься о проблему все кажется элементарно.. (попробуйте - рекомендую :)
И Васик тут не самый лучший помошщик.. копайте глубже :)
Сейчас есть время только на советы :)
Когда-нибудь изображу, если останется в этом необходимость =)
Ссылку в студию на решение этого элементарного вопроса..Цитата:
Сообщение от TheGWBV
- - - Добавлено - - -
Проблема как вы могли видеть ВЫШЕ не в арифметике, а в общей тормознутости видеосистемы УКНЦ.
От арифметики все равно никуда не денешься, а вот скорость отрисовки - проблема.
Чукча не читатель, чукча - писатель! (это я про себя)Цитата:
Сообщение от S_V_B
Просто поделилась своими мыслями вслух.
Вдруг, они окажутся разумными :)
По отрисовке в точности не подскажу. Если какой-то из двух ЦПУ имеет прямой доступ к грОЗУ, нужно стараться, чтобы он рисовал графику спец процедурами. Я не знаю, насколько хороший и быстрый код в ПЗУ УК-НЦ для векторной графики.
Выше по теме мысли по ускорению я уже высказал.Цитата:
Сообщение от TheGWBV
А когда тему открывал.. думал тоже все элементарно. Двадцать лет назад уже в OpenGL рисовал, ан нет.. чем дальше в лес тем толще партизаны..
ВДРУГ не получится:)
- - - Добавлено - - -
Вот в этом вся проблема форума, никто его не читает, а пишет "умные" ответы только на последний пост :)Цитата:
Сообщение от TheGWBV
- - - Добавлено - - -
С этим вышел великий облом.. спец. процедуры даже быстрее рисуют (и даже мысль глупая была.. 8цветов, работают в ПП.. живи и радуйся).. но не работают по 100му (поскольку общаются по "телеграфу").. и в "графическом" режиме у меня не получилось стандартную графику выводить.. поправьте если я не прав.Цитата:
Сообщение от S_V_B