Re: [osg-users] Vec{2,3,4}{b,s,i,f,d,ub,us,ui} harmonisation

2013-06-13 Thread Aurelien Albert
Hi, Those implementations are truly ugly. Yes, the C++ code is realy ugly. But the C++ interface (which is what developpers realy use) is ok, and the generated asm is great. Maybe there are some interesting ideas to take from that. Thank you! Cheers, Aurelien -- Read

Re: [osg-users] Vec{2,3,4}{b,s,i,f,d,ub,us,ui} harmonisation

2013-06-13 Thread Robert Osfield
Hi David et. al, On 12 June 2013 18:52, David Callu led...@gmail.com wrote: About Vec{2,3,4]{b,s,i,ub,us,ub}, I think we need to do a code harmonisation of all this header to provide - operator + - * / += -= *= /= (value_type) - operator + - += -= (vec_type) - operator -() for signed type -

Re: [osg-users] Vec{2,3,4}{b,s,i,f,d,ub,us,ui} harmonisation

2013-06-13 Thread David Callu
Hi all Aurelien : GML is effectively the library i regularly look/use when a mathematics feature is missing in osg, so take idea from it, specially the half float, will save a lot of work from me. Thanks Robert: About what we could add this is really usefull, - operator + - * / += -= *= /=

Re: [osg-users] Vec{2,3,4}{b,s,i,f,d,ub,us,ui} harmonisation

2013-06-13 Thread Robert Osfield
Hi David, I read/hear some programming rules, One well know is release early, release often another I think good is 'library implement all possible feature, executable implement required feature. This is not the exact sentence, i can't find it on google, but this is the idea. I 100%

Re: [osg-users] Vec{2,3,4}{b,s,i,f,d,ub,us,ui} harmonisation

2013-06-13 Thread David Callu
Features have to implemented, ported and maintained, the more features you stuff into the code to more less each feature gets tested and debugged, and the lower the user to feature ratio is, so the less available resources you have to maintain each line of code, so... code quality goes down

Re: [osg-users] Vec{2,3,4}{b,s,i,f,d,ub,us,ui} harmonisation

2013-06-13 Thread Robert Osfield
Hi David, On 13 June 2013 15:31, David Callu led...@gmail.com wrote: As you say, we need to carefully choose what we add in OSG, but I think OpenGL feature have to be add before we need it, to be sure that OSG is a fine layer over OpenGL and not a fine layer over a subset of OpenGL. I don't

Re: [osg-users] Vec{2,3,4}{b,s,i,f,d,ub,us,ui} harmonisation

2013-06-13 Thread David Callu
Hi Robert Thanks for the answer and thanks to keep OSG on the good way. I will try to follow your rules about features that all OSG user will rely upon, and niche features that a fair number of OSG users will rely upon. Don't blame me if I still try to add niche feature, this is not always easy

Re: [osg-users] Vec{2,3,4}{b,s,i,f,d,ub,us,ui} harmonisation

2013-06-12 Thread Aurelien Albert
Hi, I think this is a really interesting idea. Have a look here : http://glm.g-truc.net/ This library already implements a lot of glsl-like syntax. Before rewriting everything (that's not complex, but a lot of work) maybe we could make osg and glm work together ? Maybe adding to glm headers

Re: [osg-users] Vec{2,3,4}{b,s,i,f,d,ub,us,ui} harmonisation

2013-06-12 Thread Aurelien Albert
Forgotten link from previous message : http://devmaster.net/forums/topic/10009-swizzle-operator-in-c/ = interesting ideas on how to implement developper friendly but asm efficient swizzle in C++ -- Read this topic online here:

Re: [osg-users] Vec{2,3,4}{b,s,i,f,d,ub,us,ui} harmonisation

2013-06-12 Thread michael kapelko
Those implementations are truly ugly. 2013/6/13 Aurelien Albert aurelien.alb...@alyotech.fr Forgotten link from previous message : http://devmaster.net/forums/topic/10009-swizzle-operator-in-c/ = interesting ideas on how to implement developper friendly but asm efficient swizzle in C++