Handy Math Library v0.61 beta (2 стр)

avost
>если ты говоришь о разных компиляторах то align в aligned_float4 соблюдать через __m128 нехорошо :))
>может как нить через #pragma pack(16)
это тоже учтенно :)

>я про это место:
а что не так там? я же объяснял, msvc натыкается на #pragma once и больше не парсит файл. а те кто не знают об этой директиве, натыкаются на стандартные гварды

#if	defined(_MSC_VER) && defined(MTL_USE_SSE_SPECIALISATIONS)
	#include	<xmmintrin.h>
	#include	"basic_types.h"
#else
	#include	"basic_types_non_sse.h"
#endif

а #pragma pack не катит. так как мне нужно выравнивание, а не padding.

Если вам кажется, что CyberZX или tav что-то сделали неправильно, учите програмиирование или пейте йад. Ветка, закиданная дурацкими наездами не по делу выглядит довольно жалко.

tav
На VC7.1 не компилируется (этот компилятор уже считается устаревшим..?)

На ICC8.1 в дебаге всё хорошо (видимо, это не показатель :), вылетает в релизе:

bvec3(HMtrue,HMfalse,HMtrue)[2]                 - BUG!!! (line: 68)
bvec3(HMtrue,HMfalse,HMtrue)!=bvec3(HMtrue,HMfalse,HMtrue)- ok
bv3=bvec3(HMtrue,HMtrue,HMfalse)                - ok
bvec2(bvec3(HMfalse,HMtrue,HMfalse))            - ok
vec3(vec3(-2,1,4))                              - ok
vec3(12)                                        - ok
(v3=vec3(3,-1,4))[2]                            - ok
vec3(2,0,-1)!=vec3(2,0,0)                       - ok
v3=vec3(5,8,6)                                  - ok
ldvec3(10,-20,4)+2.0l                           - ok
vec3(10,-20,4)-2.0f                             - ok
dvec3(10,-20,4)*-2.0                            - ok
ivec3(10,-20,4)/2                               - ok
ldvec3(1,-2,3)+ldvec3(-2,1,0)                   - ok
vec3(1,-2,3)- vec3(-2,1,0)                      - ok
dvec3(1,-2,3)* dvec3(-2,1,0)                    - ok
ivec3(1,-2,0)/ ivec3(-2,1,3)                    - ok
ldvec3(10,-20,4)+=2.0l                          - ok
vec3(10,-20,4)-=2.0f                            - ok
dvec3(10,-20,4)*=-2.0                           - ok
ivec3(10,-20,4)/=2                              - ok
ldvec3(1,-2,3)+=ldvec3(-2,1,0)                  - ok
vec3(1,-2,3)-= vec3(-2,1,0)                     - ok
dvec3(1,-2,3)*= dvec3(-2,1,0)                   - ok
ivec3(1,-2,0)/= ivec3(-2,1,3)                   - ok
2.0l+ldvec3(10,-20,4)                           - ok
2.0f- vec3(10,-20,4)                            - ok
-2.0* dvec3(10,-20,4)                           - ok
200/ ivec3(10,-20,4)                            - ok
-dvec3(1,-2,-3)                                 - ok
++ldvec3(1,-2,-3)                               - ok
-- vec3(1,-2,-3)                                - ok
(v3++)==vec3(5,8,6) && v3==vec3(6,9,7)          - ok
(v3--)==vec3(5,8,6) && v3==vec3(4,7,5)          - ok
vec2(vec3(1,2,3))                               - ok
bvec4(bvec4(HMtrue,HMfalse,HMfalse,HMtrue))     - ok
bvec4(HMtrue)                                   - ok
bvec4(HMtrue,HMfalse,HMtrue,HMfalse)[2]         - BUG!!! (line: 109)
bvec4(HMtrue,HMfalse,HMtrue,HMtrue)!=bvec4(HMtrue,HMfalse,HMtrue,HMf
bv4=bvec4(HMtrue,HMtrue,HMfalse,HMfalse)        - ok
bvec2(bvec4(HMfalse,HMtrue,HMfalse,HMtrue))     - ok
bvec3(bvec4(HMfalse,HMtrue,HMfalse,HMtrue))     - ok
vec4(vec4(-2,1,4,3))                            - BUG!!! (line: 115)
vec4(12)                                        - ok
(v4=vec4(3,-1,4,5))[2]                          - BUG!!! (line: 117)
vec4(2,0,-1,-2)!=vec4(0,2,-1,-2)                - ok
v4=vec4(5,8,6,-7)                               - BUG!!! (line: 119)
ldvec4(10,-20,4,8)+2.0l                         - BUG!!! (line: 120)
vec4(10,-20,4,8)-2.0f                           - BUG!!! (line: 121)
dvec4(10,-20,4,8)*-2.0                          - BUG!!! (line: 122)
ivec4(10,-20,4,8)/2                             - BUG!!! (line: 123)
ldvec4(1,-2,3,4)+ldvec4(-2,1,0,-1)              - BUG!!! (line: 124)
vec4(1,-2,3,4)- vec4(-2,1,0,-1)                 - BUG!!! (line: 125)
dvec4(1,-2,3,4)* dvec4(-2,1,0,-1)               - BUG!!! (line: 126)
ivec4(1,-2,0,4)/ ivec4(-2,1,3,-1)

-- в последнем тесте падает по делению на ноль.

all
Вообще, хочу сразу сказать, либу я выложил не для того, что бы похвастаться (хотя так может показаться на первый взгляд :-) ). Она вышла под лиценцией LGPL, и я, в принципе, могу рассмотреть любые предложения по её совершенствованию. И теперь эта либа не моя, а уже общая, и в неё запросто могут попасть имена авторов существенных добавлений/изменений.

zerg34
>ИМХО надо писать код так, чтобы юзерам (да и тебе самому) понятнее было. В твоем коде без поллитры не разобраться.
Ну, в код заглядывать было не обязательно :-). Да и сравни код slerp из статьи на gamasutra (ссылка у меня приведена в func.h) и то, во что я его переделал на скорую руку (slerp() в func.h).
А если имеешь в виду реализацию векторов/матриц, то такая туча дефайнов сделана для повышенной ошибкоустойчивости и сверхкраткости кода, и пока такой способ себя оправдывает, хотя... можно было получше задефайнить, но и так уже ошибки искать легче -- проверил один оперетор vector+vector и уже ясно, что остальные (-,*,/) будут работать, хотя в тест-системе всё-равно проверяются все. :-)

CyberZX
>умножение матриц у меня 81 такт занимает :)
it depends.
Во-первых, всё зависит от проца. Код от интел был заточен под P-III, я свой код тоже тестил на P-III и тем же способом измерял, что и интел, причём даже установка ключа /G7 (для P-4) приводила к ухудшению результата. На другом процессоре результат работы моего же кода и на других ключах компилятора будет другой.
А во-вторых, вообще-то это было из области "С++ vs asm". Задача была просто показать, что код под стандарт С++ (ведь он использовал только циклы и мог компилироваться на чём угодно) может работать не хуже, чем asm от профи.

cppguru
>На VC7.1 не компилируется (этот компилятор уже считается устаревшим..?)
Скорее наоборот, это у меня устаревший. Ну я по старинке VC++6 -ым пользуйюсь. А нафиг мне 7-ая студия? Visual Assist есть. Компилю только IC++. Что там так много нового добавилось? А если нет, тогда зачем оно надо? А насчёт мелкомягкого компилятора, то про его глюки на тривиальном коде я уже наслышан (и не только в 7.1, даже в более ранних есть), ещё и поэтому ставить не хочу.

А вообще почему не компилится, что выдаёт-то?

>На ICC8.1 в дебаге всё хорошо (видимо, это не показатель :), вылетает в релизе:
У меня в IC++7.1 абсолютно тоже самое. :-(

Ну ладно, покопался я немного. Ситуация значит такая. Если определить DISABLE_SWIZZLING, то тест-система компилиться не будет, т.к. кое-где используется Plane.xyz, где Plane - 4D-вектор. Если поменять Plane.xyz на vec3(Plane), и определить DISABLE_SWIZZLING, то в релизе IC++ ВСЁ работает нормально, без "багов".
С другой стороны, плясать можно и от другого. Определить DISABLE_VECTORIZATION (после этого ошибок станет меньше) и (!!!) в typedef.h вместо __forceinline константе INLINE назначить просто __inline, тогда тоже всё работает нормально без ошибок.
В последнем случае, можно вместо DISABLE_VECTORIZATION определить SUBVECTORS_SWIZZLING (казалось бы, ну какая тут связь), тогда тоже всё-работает и даже векторизуется, правда компилиться чуть подольше и... нихрена не инлайнится.
В общем, выбирай одно из трёх. В принципе, все три варианта одинаково хреновые, но... ничё больше я придумать не смог, IC++ категорически отказывается воспринимать код с циклами for(int i=0;i<4;i++) в сложных структурах данных.
Ладно, потом наверное заменю эти циклы на интринсики... а так не хотелось.

P.S. Хм. Я уже не знаю, то ли это я туплю, то ли компилятор. Только что скомпилил без #define DISABLE_VECTORIZATION (т.е. с включённой векторизацией). Всё прекрасно работает в релизе, да ещё и векторизуется + свиззлинг (неужели дело было только в __forceinline). Короче, если всё же это я опять туплю и нормально работать не будет, ставь #define DISABLE_VECTORIZATION. Так вроде должно работать... по крайней мере в IC++.

И ещё, скачай "новую" версию. Ссылка та же. Изменился лишь typedef.h, но в IC++ теперь работает в релизе (у меня).

tav
>А насчёт мелкомягкого компилятора, то про его глюки на тривиальном коде я уже наслышан (и не только в 7.1, даже в более ранних есть), ещё и поэтому ставить не >хочу.
можно поподробнее о глюках при компиляции тривиального кода через msvc7.1? сейчас этот компилятор считается промышленным стандартом. качество генерируемого им кода не сильно отличается от ICC(так как его тоже разрабатывали инженеры Intel), зато скорость компиляции выше на порядок.
если твоя либа будет работать исключительно на ICC то проку от нее мало. так как вести разработку используя интеловский компилятор сложно

tav
Что умеет твоя либа такого чего не умеет к примету моя, его и ... ??
С каой целью она создана??

Я к примету вполне удовлетворен вектором 3-Д, если надо чтото зделать в 2-д занулить одну координату.
Говорить для оптимальной скорости при 2-д совсем не приходиться поскольку для таких игрушек использование векторов происходит на мин-ом уровне.
Зачем эта универсальность? В большинстве случаев это токо оболочка.

Хотя...
Что у тебя есть для определения столкновений?

all
В документацию добавлены описания конструкторов и выражения с типами библиотеки (сложение/вычитание/умножение векторов/матриц/кватернионов и т.д.).

CyberZX
>можно поподробнее о глюках при компиляции тривиального кода через msvc7.1?
Ну, к примеру есть совсем уж известная бага (и ты о ней прекрасно знаешь). И между прочим, сам же советовал использовать IC++. Или твоё отношение в нему изменилось?
И вообще, не надо говорить, что таких баг в VC7.1 по пальцам пересчитать, я про это услышал и мне этого достаточно, чтобы в подкорке сделались некие выводы. Человеку вообще свойственно рассуждать субъективно. И мне как-то накласть, что эту багу (я правда не уверен) MS давно уже исправило, а в IC++ тоже наверняка не всё без ошибок и т.д. и т.п. MS облажалась, так? Первое впечатление осталось? Ну и всё, и выбор "VC7.1 vs IC++7.1" я делаю в пользу известно какого компилятора.
>если твоя либа будет работать исключительно на ICC то проку от нее мало.
Ну так пусть хоть кто-нибудь объяснит мне русским языком, почему на VC7 либа не компилится!
>так как вести разработку используя интеловский компилятор сложно
Почему?

Breezy
>С каой целью она создана??
Упростить жизнь разработчиков. Повысить надёжность их кода (ведь если либа "принуждает" писать понятный и краткий код, ошибок будет меньше).
Я тоже пользовался своей прошлой либой, пока не понял, что это что-то... не то.
>Что умеет твоя либа такого чего не умеет к примету моя, его и ... ??
Ну, привожу на вскидку список функций (или их аналогов), которых наверняка у тебя нет:
wrap(x,minVal,maxVal)
reflect(V,Plane)
crossMat(n)
<все функции сравнения (isZero, lessThan, notEqual, any и т.д.)>
noise#
translatePlane(Plane,V)
reflectPlane(Plane,PlaneR)
lookAtMat(eye,center)
lookAtDirnMat(eye,dirn)
lookAtDirnMat(dirn)
rotate(angle,axis,vec)
projectionMat(Plane)
squad(p,a,b,q,t)

К тому же в либе есть документация. А ты знаешь много мат. либ. с полной документацией? У той же GMTL её читать довольно проблематично особенно касательно операций над типами данных, и дело не в языковом барьере, а в том, что в gmtlProgrammersGuide-0.0.5.pdf к примеру написано довольно мало, а в gmtlReferenceGuide-0.0.5.pdf просто перечисление всех функций, конструкторов и операторов. От перечисления функций, конечно никуда не деться, но вот конструкторы и операторы ИМХО у меня лучше описаны (по крайней мере в английской версии :-) ). А ведь главных барьеров при использовании чужих либ по сути два: документация (никто ведь не хочет копаться в чужом некомментированном коде) и надёжность, а точнее её отсутсвие. Вот сниму второй барьер, тогда может дело пойдёт. :-)

>Что у тебя есть для определения столкновений?
Это слишком специфичная задача чтобы выносить её в общую либу.

tav
>А ты знаешь много мат. либ. с полной документацией?
Весомый аргумент :). Не знаю даже, но, допустим, я никогда не встречался с проблемой непонимания исходного кода математической библиотеки при отстутствии документаций. Хватало нескольких коментариев.

>писать понятный и краткий код
Увидел код и ужаснулся. Пролистал код Tmat2 и ужаснулся дважды :). С такими дефайнами я ещё не встречался.

tav
>И вообще, не надо говорить, что таких баг в VC7.1 по пальцам пересчитать, я про это услышал и мне этого достаточно, чтобы в подкорке сделались некие выводы
я исхожу из практических соображений. я очень плотно работаю с MSVC7.1 и могу сказать тебе точно таких багов действительно можно посчитать по пальцам лично я на практике с ними вообще не встречался. а вот с багами и глюками ICC7.1 приходилось частенько встречатся. особенно задолбал это zombie state :E
msvc7.1 это современный компилятор, который является промышленным стандартом в разработке программ на С++. поэтому если пишешь либу, то надо в первую очередь сделать так, что бы она работала на этом компиляторе. если придется отказатся от каких-то крутых фич ICC, то юзай условное компилирование, благо у С++ очень богатые возможности в этом плане.
а про подкорку ты зря. программист должен оценивать инструментарий объективно. и знать какие плюсы и минусы ждут его при работе с тем или иным инструментом, а не полагаться на эмоции, основаных от первых впечателний. это не профессионально.

tav
Советую не спорить с людьми (все равно это бесполезно), а доводить до ума свою библиотеку. Избавишься от глюков, проверишь все алгоритмы, протестируешь и все будет ок. Люди будут юзать.

all
Ну, что сказать. Качайте новую версию. Исправил аж две строчки кода.

CyberZX
М-да...
Потратил тучу времени, поставил VS .NET.
В VC++7.0 всё прекрасно компилится и работает, но вот от VC++7.1 я такого не ожидал. Они там что, с ума посходили в MS. Такое чувство, будто весь код компилятора с нуля переписали. Никакой обратной совместимости. Вот в VC++7.0 -- правильный компилятор, даже warning-ов столько же по сравнению с VC++6 -- и там и там 18 (в 7.1 - 3 штуки), а вот 7.1.... отличается от 7.0 гораздо больше, чем 7.0 от 6.0, даже стандартные хидеры переписаны, ибо предыдущие их версии на 7.1 просто не компилятся...

Кстати о той баге "при компиляции тривиального кода". Она есть и в 7.0, и в 7.1. Странно, неужели в 7.0 её ещё не обнаружили, что и за год MS её так и не исправила...
>а вот с багами и глюками ICC7.1 приходилось частенько встречатся.
Можно поподробнее о глюках компиляции кода IC++. Чтобы он что-то компилировал и это работало бы неправильно.

zerg34
>Избавишься от глюков,
Какие глюки? О чём ты? :-)

cppguru
>На VC7.1 не компилируется (этот компилятор уже считается устаревшим..?)
Ага, можешь его считать устаревшим. :-)
Такой простой хак (даже в 7.0 всё работает), а 7.1 уже так постарел, что забыл как надо ето компилить. :-)

all
Новая версия. Качать, as always, по ссылке из 0-го поста.
Переизобрёл кватернионы. Ох, не представляю как до них Гамильтон вообще додумался, особенно с этим половинным углом, ну да ладно.
А уж код для работы с ними из nebuladevice вообще стоит отдельного упоминания. Кто его писал интересно, ну просто какие-то монстры в математике. Я доолго тупил, пытаясь доказать почему же (ахтунг!) прибавление длины кватерниона к его компоненте w уменьшает угол его поворота ровно в два раза. Но, тем не менее во всем разобрался. Сначала даже сам написал свою реализацию, но потом как начал сравнивать с тем, что было в nebuladevice... короче, посмотрел, а потом заново переписал и в принципе в некоторых местах (напр. в shortestArcUnitQuat) получилось вроде даже лучше, чем в небуле.
И ещё. Доработал тест-систему. Теперь вектора/матрицы/кватернионы тестируются практически полностью, остаются только функции.
Ну и проверил на 5 компиляторах (см. 0-й пост).

all
Не понимаю, почему все так равнодушно к этому относятся. Как будто есть лучшие альтернативы. Тогда чем "лучшие"? И почему я о них ничего до сих пор не знаю? :-)

Я эту либу, между прочим, не просто так стал делать. Я действительно искал удобный, переносимый, надёжный вариант. Но таковых не нашёл. Всегда что-то... не нравилось в архитектуре других либ. Ведь мат. либа - это не просто набор поддерживаемых функций и классов с перегруженными операторами. Важна ещё и их организация.
Архитектура HandyML основана на GLSL. И таким образом, основу HandyML составляют:
1. Жесткий контроль приведения типов. Запрещены все неявные преобразования типов. Все преобразования должны быть заданы явно через конструкторы.
Таким образом, нельзя писать vec4 v=0; А нужно так: vec4 v=vec4(0); Так же не происходит автоматических преобразований в функциях и операторах, что исключает неоднозначности, ведь "mat4 m2=5+m;" не равносильно "mat4 m2=mat(5)+m;".
2. Унифицированность арифметических операторов. Большинство операторов работают покомпонентно, за небольшим исключением, что упрощает их запоминание и наглядность кода. В частности, все бинарные операторы с одинаковыми операндами дают результат, имеющий тот же тип, что и операнды, без исключения.
3. Отсутствие функций-членов в классах-типах библиотеки (за исключением методов доступа к множеству компонентов, напр. xyz()). ИМХО, free-функции (вроде length()) улучшают восприятие кода.
4. Результат своей работы функции всегда выдают в виде возвращаемого значения (void-функций в либе вообще нет). Это даёт более гибкий механизм для работы с функциями. Напр. функции интерполяции (lerp, slerp или squad). Простая задача - найти интерполированное значение цвета для точки (x,y) внутри квадрата с цветами в его вершинах (a,b,c,d). В HandyML это делается просто: lerp(lerp(a,b,y),lerp(d,c,y),x). А теперь реализуйте её в GMTL например, где lerp принимает 4 аргумента: lerp(result,t,from,to). Удобно?

И ещё. По поводу пункта 2. Простой пример - расчёт освещения вершины/пикселя (напр. для текселя лайтмепа или пикселя
при рейтрейсинге) с использованием HandyML:

CyberZX
>msvc7.1 это современный компилятор, который является промышленным стандартом в разработке программ на С++. поэтому если пишешь либу, то надо в первую очередь сделать так, что бы она работала на этом компиляторе.
Посмотрим, что будет с выходом скажем VC++9.0. Тогда уж сразу говори не о 7.1. а о "последней" (или "наиболее распространённой") версии компилятора, а то насчёт "промышленного стандарта" я сильно сомневаюсь, и особенно насчёт совместимости старого кода на новых компиляторах от MS.

>качество генерируемого им кода не сильно отличается от ICC(так как его тоже разрабатывали инженеры Intel), зато скорость компиляции выше на порядок.
Кстати нифига. Замерил время компиляции тест-системы (через Build Timing -> Yes). И для 6-ой вижалки через опцию "/y3".
Вот 6-я вижалка компилирует код как раз на порядок быстрее VC++7.1. VC++7.0 компилирует немного быстрее VC++7.1, а вот IC++7.1 компилит даже быстрее VC++7.0, и фору VC++7.1 может дать довольно существенную и это притом (!!!), что IC++ векторизовал тучу кода с 4D-векторами и матрцами. В логе билда просто куча сообщений LOOP WAS VECTORIZED.
>так как его тоже разрабатывали инженеры Intel
Видимо Intel их уволила, а MS подобрала подешёвке.
Шутки шутками, конечно, но в разработке харда такие люди сидят, что нам софтовикам до них, как до Луны пешком, и если обнаружится ошибочка в стомиллионно-транзисторном кристалле, там не то что голову, а яйца оторвут со всеми потрохами кому надо и кому не надо. А MS такой, извиняюсь, "ширпотрёб" выпускает, как будто на распродажу, а средств у них уж поболе чем у Intel. Вот что значит монополия, совсем распустились.

tav
Если тебя интерисует вот список ф-й которые я использую для векторов

Breezy
Перенеси, please, длинные строки в своём коде на несколько строк, а то всё форматирование съехало -- страница расширилась.

Вообще конечно, у тебя удобством как-то не пахнет. Почему решил без операторов делать? ИМХО, очень не удобно.

all
Сделал новый класс Taabb, а по сути даже два новых типа: aabb и rect. Никто не смотрел ещё в новой версии либы? Ну как вам дизайн?
Только вот не знаю что делать с типами aabb, а то "ldaabb" выглядит как-то странно.