Как стать автором
Обновить

Комментарии 9

Пару замечаний:
1. Вручную совсем не обязательно увеличивать объекты, в экспортере есть опция «scale factor».
2. Собственно, про саму математику с фиксированной точкой и ее особенности вы так и не рассказали. Например о том, что склаывать-вычитать можно и так, а умножать-делить надо через соответствующие функции (напр. IW_FIXED_MUL), которые нормализирует результат. Причем лучше использовать вариант IW_FIXED_*_SAFE так как он использует промежуточной результат с большей разрядностью чем операнды и позволяет избежать переполнений, которые часто случаются с этими числами.
3. Вообще это немного дурной тон — пользоваться напрямую 0x1000. Есть константы IW_GEOM_ONE и IW_GEOM_POINT (IW_GEOM_ONE == 1<<IW_GEOM_POINT). Тем более что там ипользуется несколько форматов, например iwqfixed с большей разрядностью дробной части (используется например в кватернионах). Кстати, анекдот насчет последнего — я обнаружил у них баг (вроде уже профиксили), когда умножение двух единиц (IW_GEOM_QFIXED_MUL(IW_GEOM_QONE,IW_GEOM_QONE) ) вызывало переполнение (надо было использовать IW_GEOM_QFIXED_MUL_SAFE)

Вообще Мармелад хорошая библиотека, но нельзя сказать что уж очень стабильная и надежная. Я понимаю, что вручную писать под такую кучу платформ, как они поддерживают было бы в миллион раз геморройнее, чем изредка натыкаться на баги в мармеладе. Я не так давно потратил почти неделю на поиск причины визуального глюка в своей программе, пока не обнаружил баг в их имплементации умножение кватерниона на вектор, который при некоторых значениях кватерниона (!) выдавал неправильный результат.
У меня почему-то scale из плагина не работал. Хотя очевидно именно для этого он и сделан, чтоб готовую сцену не переделывать.
Спасибо за напоминание о функциях умножения, деления. Добавил в статью.
P.S. Я никого не призываю использовать 0x1000 напрямую, лишь заметил, что полезно знать сколько это IW_GEOM_ONE — можно быстро прикидывать нормализован ли вектор.
Это да, хотя прикинуть в уме нормализирован ли вектор, не так-то просто даже с обыкновенными флоатами, если, конечно, он не совпадает более или менее с одной из осей :)
Вообще, отлаживать фиксированную точку действительно не очень удобно. В gdb я бы себе скрипт написал бы, который сразу бы переводил значение в человеческий вид — жаль я понятия не имею, как это делается в вижуал студии :(
Если длина вектора далека от единичной, то это достаточно просто. Вот, например, тот же (0xFF, 0xFF, 0xFF) из примера. Понятно, что его длина меньше, чем 2 * 0xFF, что намного меньше 0х1000.
У меня, кстати, scale работал без проблем. Правда я успел порядком помучится прежде чем его нашел — в самом первом тесте я экспортировал маленькую модель (будучи уверенным, что экпортер масштабирует ее в родные единицы) и долго не мог понять, почему модель так криво выглядит — оказалось точности не хватает на таком размере.
Да уж :D Забавное описание «FOV»а. Спасибо за хорошее настроение с утра :)
Я вот все не могу понять — это ограничение самого Мармелада такое — использовать fixedpoint? Ведь многие мобильные платформы позволяют использовать float, да еще и с векторными расширениями.
Мармелад бежит на куче железа, включая и такое, на котором floating point работает медленно. Впрочем они уже давно обещают добавить полноценный пайплайн с плавающей точкой.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории