Comments 19
Но ведь
Можно так же использовать int64_t для координат, а для имитации плавности в субпикселях можно делить координаты на 100.
и есть, по сути, представление чисел с фиксированной точкой. Только точка зафиксирована неоптимальным, для двоичных чисел, образом.
Зато очень удобно в работе. Вместо условных метров используем миллиметры, и можно даже не относиться к ним как к фиксед-поинтам. Вычисления становятся молниеносными, и гудбай все проблемы с флоатами. Для простых 2D-игр отличное решение (если на этом остановиться, и не использовать физические движки, которым обычно флоаты всё-же нужны).
Ну под числами с фиксированной точкой я имел ввиду всякие библиотеки где это сделано посложнее чем деление инта и можно выбирать длинну дробной части и есть всякие стандарты типа Q16.16
Вычисления с float еще и медленные по сравнению с int.
На современных системах благодаря различным оптимизациям, инструкциям и векторизации разницы уже нет, а зачастую float даже быстрее при умножении/делении, чем int.
На моём ведре floatы всё же медленнее
Основная проблема в оптимизации, начиная с момента, когда скорость процессоров перерасла скорость доступа в памяти, это собственно скорость доступа к памяти. Тупо менять float на int, когда части матрицы разбросаны по разным частям памяти. Вы не получите серьезного прироста к fps и просто усложните себе жизнь.
это надо запускать Юнити и проверять ), так на словах скептично звучит ), я к тому что чтобы это всё продемонстрировать всё надо показывать на примерах), почему к примеру Юнити так будет понятно какая математика, что где и прочее ), потом болячки движков еще окажется разные, у Майнкрафта может быть своя математика, движок, в самой математике еще есть нюансы поидее, плюс тут база математика, она вляет на физику а там нюансы тоже, потом не понятно какой должен быть мир чтобы с этим столкнуться, на поверхности хорошо, но будет ли мир 1 милион размера это даже представить не возможно тоже нюанс, потом почему - + , может у кого будет ++ или --, по ощущениям в том же Ухты не 1 милион в калимдоре, и на берегах некоторых прогрузка+люа что-нибудь, вообщем нюансов больше, потом если сетевая игра, и может на других устройствах точность побольше чем на стационаре
можно уйти от ухты и ТЕСО, и посмотреть на Скайрим, Морровинд, и где тоже есть глитеффект - дагерфол вроде или арена, в ультиме например, которая онлайн тоже бесполезно смотреть потомучто локальную точность может пофиксить сервер поидее, в фалаут76 например не 1 миллион мир, ну Старфилд получается может подпадать, но поидее они с этим сталкивались на одной из первых игр и теперь локальные игры либо прогрузка+мир, либо как мороввинд либо как фолыч, тут всё очевидно по решениях балансируем между прогрузкой и точностью ну поидее
а как же фракталы работают тогда, там мондельброт какой-нибудь, визуально бесконечность.
простите может я чтото не понимаю проверил у себя, (vec3){1000000.0f, 0.0f, 1000000.0f} и камера и кусочек террейна (800,50,800 - масштаб 40к вершин), камера крутиться и летает, террейн не трясёт в -+ трясёт террейн и камера локается толи из-за эпсилоны(проверка) толи не знаю почему, (так же проверил масштаб (800х3)х(800х3) - это очень много, там можно на таком масштабе чтото сделать, плюс хитрость в том, что минимизировать потери же можно если центр 0 0 0 будет в центре тоесть раскрыть 9 тайлов и туда и туда, или только в +, тоесть можно заползти террейнами на минусы и планомерно уходить в +, там на любую игру хватит
А не работают, если брать стандартные алгоритмы вычисления и даже использовать для них long double, то при глубоком увеличении картинка становится квадратной кашей. Посмотре на ютюбе несколько видосов с увеличением внутрь фрактала, перемотайте все 10 часов видео до конца и вы увидите как картинка превращается в однообразную заливку. Вообще это тоже фиксится специальным алгоритмом, который показывает фракталы детально на любом увеличении
Тоже недавно заинтересовала подобная тема. Оказывается на en-вики есть целая статья по различным способам оптимизации отрисовки Мандельброта: https://en.wikipedia.org/wiki/Plotting_algorithms_for_the_Mandelbrot_set#Perturbation_theory_and_series_approximation. Судя по всему, наиболее интересный способ связан с теорией возмущений.
А в чём Профит 3 способа?
Я знаю что такой подход использовали когда нужно перемещать персонажа другими объектами (к примеру лифт)
Т.е. явно 3 способ включает не только инверсию манипуляции координат, но и ещё что-то, ведь если у вас есть вероятность выхода за пределы точности персонажа, то есть и вероятность выхода за пределы точности окружающего мира?
Или у нас получается так, что окружающий мир будет находится так далеко при достижении пределов точности, что мы его не заметим? Т.е. перекладываем этот момент на движок?
Сталкивался с таким в шейдерах на мобильниках, там float вообще может быть 16 бит. Делал процедурный фон, анимировался параметром через время в float секундах. На компе норм, на мобилках через несколько минут начинало всё дёргаться. Пришлось этот параметр на мобилках зацикливать, крутил от 0 до 30, потом обратно от 30 до 0.
Точность позиционирования объектов в играх: возможные ошибки