ФлеймФорумПрограммирование

Фиксики против флоутов или fixed vs float point (2 стр)

Страницы: 1 2 3 48 Следующая »
#15
19:26, 10 июля 2024

Zab
16.16 что, не хватало чтоль?

#16
20:21, 10 июля 2024

Dmitry_Milk
Численные методы знаешь ?

#17
(Правка: 22:03) 21:32, 10 июля 2024

Zab
Разве не было fpu отдельного ? Ладно, как деление делал ? Насколько оно медленное , вот в чем вопрос

#18
23:34, 10 июля 2024

чем болльше разность чисел, тем деление дороже

#19
23:48, 10 июля 2024

innuendo
> Ладно, как деление делал ? Насколько оно медленное , вот в чем вопрос
щас хз, но в стародавние времена, когда все было лучше, замена деления умножением, было признаком хорошего тона.
а щас даже по шейдеру иф-элсе норм пашут)))

#20
2:34, 11 июля 2024

innuendo
> Фиксики против флоутов или fixed vs float
> Тоже интересная тема ..есть плюсы минусы, опытом делимся
Вот этот софтрендер сделан на 99% целочисленными вычислениями, и на 1% флоатами: https://gamedev.ru/code/forum/?id=283134

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

#21
(Правка: 3:27) 3:15, 11 июля 2024

innuendo
> Разве не было fpu отдельного ? Ладно, как деление делал ? Насколько оно медленное , вот в чем вопрос
fpu и до пентиумов был, но он был медленнее в невообразимое число раз. Ни о каком умножении за один тик речь не шла. Целые числа на 486 были уже очень быстрые.

Деления надо было избегать и там, и там, оно везде было медленным. Не помню уже точных цифр, кроме одной, на первых пеньках целочисленное деление занимало порядка 40 тиков, умножение 1-2-3 тика, как повезет. На вторых пеньках уже можно было говорить об одном тике, в среднем, там дикое распараллеливание пошло, алу перестало быть единым.

На fpu можно вручную оптимизировать на скорость раз в пять-десять более быструю, чем это делают компиляторы, знаешь? Медленная операция - загрузка в регистры и выгрузка из них, но можно же не выгружать промежуточные данные. Регистров 8, но компиляторы не используют больше 4 обычно. Операции работать могут и в стековом режиме на этих 8 регистрах. Переводишь свои выражения в польскую инверсную запись - и ву а ля. Плюс, избегаешь констант, они медленные, если не встроены в фпу. Плюс, работу фпу можно распараллелить с цп.
Я оптимизацией на ассемблере не баловался, но на соседних рабочих местах люди это делали у меня на глазах.

#22
3:24, 11 июля 2024

Battle Angel Alita
> 16.16 что, не хватало чтоль?
Для физики? Конечно не хватит. Почти никогда. Оптимальное положение точки приходится высчитывать для каждого числа, включая промежуточные результаты. И оно не будет оптимальным всегда, приходится жертвовать точностью в нетиповых случаях или программировать для них отдельные ветки.

#23
5:22, 11 июля 2024

barnes
Если на константу делишь то можно заменить

#24
7:41, 11 июля 2024

122
Ну сложение одинаковое это я  верю , а вот умножение деление не очень:)

#25
(Правка: 8:26) 8:09, 11 июля 2024

Как сказали в #2, что хочет обсудить ТС - непонятно. Но попытаемся предположить.
Как и любая приличная технология, не поставленная индусами на поток, рендеринг в целых числах никем толком не описан, и как его делать по существу никто не рассказывает, только обрывками по всему интернету. Лично я уже около года активно слоняюсь по всяким помойкам в этой и смежных тематиках, а ТС видимо желает чтоб ему все ноухау вывалили по запросу на русскоязычном, не особо специализирующемуся на этом, форуме. Ну ладно, сегодня ему повезло.
1) Выбирая фиксированную точку - ты получаешь детерминизм, отсутствие необходимости разбираться со всякими отрицательными нулями, нанами, прочим бредом описанным в спецификации, а также что-то типа некоего единообразия кодобазы, взамен ты обязан бдить за переполнениями и частично расплачиваешься читаемостью - нужно постоянно следить что и в каком формате у тебя находится, иначе объекты могут улететь на Луну, либо сжаться в субатомы.
2) 16.16 хватает только для дума, потому как там не было комплексной математики, а вся тригонометрия впихнута в таблицы. Меньше 16 бит точности брать сильно не рекомендуется, это приводит к артефактам с z-буффером и/или дребезжанию полигонов как на первой плойке. Больше 16 бит на практике не нужно, если, конечно, ты не моделируешь солнечную систему 1:1. Для физики может быть 16 и не хватит, но я эту область еще не разбирал. Оптимальным решением для настольных компьютеров, без учета графических извращений, является формат 48.16, но тогда потенциально могут возникнуть проблемы с запуском на железе уровня спресованного песочка, а это добрая часть любителей целочисленного рендеринга.
3) Все статьи в интернете, описывающие работу с арифметикой чисел с фиксированной запятой, описывают тривиальные вещи типа умножение/деление, и на этом останавливаются. Как делать дальше - не ясно, квадратные корни и тригонометрия это реальный мрак, найти вменяемую реализацию этих рутин заняло очень много времени, их можно посмотреть по ссылкам далее. Все вот говорят: "Раньше игоры писали в фиксированных запятых!", допустим, но деды нихрена нам не оставили по этой теме, большинство трехмерных игр той эпохи имеет закрытые исходники, или написаны на каком-нибудь ассемблере для кофеварок, пойди разбери что там и где. Есть готовые библиотеки для работы с такими числами, типа libfixmath, но у них лицензии навроде MIT, в работах выпускаемых в общественное достояние хрен воспользуешься, они громоздки, а используемые там алгоритмы неочевидны.
4) Как и воксели, или любую другую не обсосанную до дыр технологию, целочисленный рендеринг двигают вперед из своих подвалов полтора гения-атланта, типа местного 122, которые хрен с кем своими достижениями поделятся, и когда они в своих подвалах скорчатся от асфиксии или сердечных приступов - их работы будут утеряны для общества навсегда. После них идет сравнимое количество гениев аутистического толка, которые с общественностью таки делятся, потому на них все и держится. Потом уже идет всякий плебс типа меня и остальных интересующихся мимокрокодилов. Итак, чего достигли последние две категории? Немногого.
4.1) https://github.com/LMP88959/PL3D-KC
Это вырезки из рендера вот этой игрушки -> https://kingscrook.itch.io/kings-crook
Данный двиг написан мутновато, непереиспользуемо, а еще жрет в сцене из двух объектов 10-20% ЦПУ. Сам автор признает кривость, но делать пока с этим ничего не хочет.
4.2) https://codeberg.org/drummyfish/small3dlib
Пока что лучшее из доступного. Запускается на сжатом песочке, но математика написана кривовато. Использует 9 битов точности, что приводит к дребезжанию полигонов (а может и не приводит, зависит от настроек). Функция вывода пикселя на экран может быть довольно громоздка, если использовать текстурирование. С кучей моделей работать может быть также неудобно.
4.3) https://github.com/Ilya3point999K/RAL

+ Показать

Это уже мое (ну как мое, это порт другого рендерера на фиксированные запятые). Я склоняюсь к тому, что игры использующие целочисленный рендеринг должны иметь примерно такую графику, это могут позволить себе нищие, не имеющие в рабстве художников, а также такой рендеринг болиелимения понятен, не нужно склеивать треугольники в модели, натягивать там кого-то. Проблемы, конечно же, есть, в первую очередь это ориентация на 64 битные числа, как я уже говорил, 16.16 вызывает очень много артефактов при переполнении, а меньше 16 не хватает для z-буффера. Здесь же можно посмотреть РАБОЧИЕ функции для квадратного корня и тригонометрии, которые при этом не сжирают 20% ЦПУ. Вполне может быть что я что-то написал криво в умножении/делении/самом рендеринге, поэтому и не могу обойтись 32-битными интами, но вспоминаем пункт №4 - я плебей-дурачок, который хоть как-то пытается разобраться и структурировать тему, люди поумнее в основном не желают делиться практиками с такой аудиторией.

#26
8:29, 11 июля 2024

Ilya3000
Спасибо , шедевр ...война и мир Фиксиков флоутов :)

#27
9:41, 11 июля 2024

Вас тупо тралят :)

#28
11:11, 11 июля 2024

122
> Проводил для себя тесты, они показали что на современном железе скорость инты\флоаты приблизительно равна, но на интах меньше нагрев проца и уровень загрузки в диспетчере задач.

Как так получается, может у железки нет встроенных int?

#29
11:13, 11 июля 2024

Ребята, усбагойтесь! На float можно программировать для создания игр, не сильно медленнее!

Страницы: 1 2 3 48 Следующая »
ФлеймФорумПрограммирование