Vibrant 1.5

#ponce contact at gamCOOKIESesfrommars.fr
Tue Sep 21 02:31:35 PDT 2010



> Very good. I have seen 2D vectors implemented something like ten times in D code, so I think it's time to stop this. They need to go in the standard library:
> http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/vec2.d
> http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/vec3.d
> http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/vec4.d
> http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/vectorop.d
> 
Those are pretty useful to me but the use a template mixin (sheduled for deprecation ?)

> Useful math, fast too:
> http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/common.d

A lot of functions here do not behave well (especially the pow/exp variants)

> http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/rounding.d
> 

This is plain ugly stuff, the rounding affect the FPU control word and do not restore it.
A good conversion rounding routines should be based on 

> Half floats, I don't know if they are better than user defined floats of Phobos2:
> http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/half.d

half float are useful for 3D because it saves bandwidth with the graphic cards. Less for other purposes.
I think common2 allow to use vec3!(half) but lack of implicit conversion makes it less useful than the same design in C++.

> Quaternions:
> http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/quat.d

Those are mostly untested.


> 
> A color module is useful:
> http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/misc/colors.d
> Python std lib has colorsys:
> http://docs.python.org/library/colorsys.html

No this one is not good.

> 
> More useful general matrix code:
> http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/mat4.d
> 

this stuff is well tested now.

> Some very basic geometry code fit for a std.geometry module:
> http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/math2d.d
> 

not really usable.

> I think all those things (maybe with a little more docs, improvements, unittests, contracts) are fit to be added to Phobos, because:
> - they are basic things that are commonly useful;
> - they aren't a lot of code;
> - they will be useful ten years from now too, they will not become obsolete;
> - I have seen them implemented in user D code several times;
> - Some of them are present in my dlibs1 and I have used them several times.
> 

The obvious problem is that all of this is currently
- for D1
- not elegant "D-style"
- too much assembly
- not very reliable (I figured out my 4x4 matrix inversion was false 1 month ago, after using the code for two years)
- written for ease of use and conciseness rather than correctness

The only part that could be saved is half-floats and perhaps quaternions but this is specific to 3D graphics.

There was a discussion a while ago on adding small vectors to D2 and I think it's a good idea. 

A good small vector type should use the new D2 capabilities like opDispatch for swizzling, be parameterized by size and type, and not be much slower in debug mode.

I plan to convert the good stuff to D2 (in fact it already begun) but I'm on a lot of projects right now.




More information about the Digitalmars-d-announce mailing list