Hi,

Do you remember Vibrant, the abstract arena shooter I wrote last year? The game has been updated several times since, bringing many enhancements.

http://www.gamesfrommars.fr/vibrant

Cheers,
ponce

Vibrant has been open source'd (again):
http://bitbucket.org/ponce/vibrant

ponce:

> Vibrant has been open source'd (again):
> http://bitbucket.org/ponce/vibrant

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

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

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

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

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

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

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

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.

Advanced modules for computational geometry, colorimetry, statistics, etc, are beyond the scope of Phobos2. But short, simple to use, frequently useful functions are fit for the standard library. So I think there are modules that should be added to Phobos:

std.geometry
std.color
std.quaternions
std.halffloats
std.vectors
std.combinatorics (or std.comb) for permutations, combiantions, subsets, and few more.
Plus more code for std.math and std.array (for the matrix code) and std.numerics.

Eventually I'd like to write a basic std.combinatorics module for Phobos2.

Bye,
bearophile

bearophile wrote:

> ponce:
> 
>> Vibrant has been open source'd (again):
>> http://bitbucket.org/ponce/vibrant
> 
> 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
> 
> Useful math, fast too: http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/common.d http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/rounding.d
> 
> 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
> 
> Quaternions: http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/quat.d
> 
> 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
> 
> More useful general matrix code: http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/mat4.d
> 
> Some very basic geometry code fit for a std.geometry module: http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/math2d.d
> 
> 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.

I second that, if we should learn something from looking at 3D libs written in c++ it is that they all reimplement vectors and that this make it a pain to move code betwean them because of incompatible vector implementations.

So adding this would be a huge step forward for phobos.

> Advanced modules for computational geometry, colorimetry, statistics, etc, are beyond the scope of Phobos2. But short, simple to use, frequently useful functions are fit for the standard library. So I think there are modules that should be added to Phobos:
> 
> std.geometry
> std.color
> std.quaternions
> std.halffloats
> std.vectors
> std.combinatorics (or std.comb) for permutations, combiantions, subsets,
> and few more. Plus more code for std.math and std.array (for the matrix
> code) and std.numerics.
> 
> Eventually I'd like to write a basic std.combinatorics module for Phobos2.
> 
> Bye,
> bearophile

bearophile wrote:
> ponce:
> 
>> Vibrant has been open source'd (again):
>> http://bitbucket.org/ponce/vibrant
> 
> 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

Definitely we need vectors in Phobos.

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

Actually, I don't see any functions which are faster than std.math. std.math.exp2() is *much* faster than common.pow2() (one slow instruction, vs five!!!) And exp2 sets the flags correctly.
expi() is faster than sincos().

> 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
> 
> Quaternions:
> http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/quat.d
> 
> 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
> 
> More useful general matrix code:
> http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/mat4.d
> 
> Some very basic geometry code fit for a std.geometry module:
> http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/math2d.d
> 
> 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.

I agree. There's some useful stuff here.

> 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.

Errata: A good rounding routine should be based on FISTTP which avoid messing with the rounding mode entirely.

> 
> Actually, I don't see any functions which are faster than std.math.
> std.math.exp2() is *much* faster than common.pow2() (one slow
> instruction, vs five!!!) And exp2 sets the flags correctly.
> expi() is faster than sincos().
> 

I wrote that years ago because Pascal didn't have those ;)
I refused to use std.math function because they were taking a real argument. is that optimized ?

I've strong NIH syndrom. ;)

#ponce wrote:
>> 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++.

My guess is that what you really want, is pack-and-unpack routines for whole arrays.  half[0..n*2] <--> float[0..n]

It's a fascinating problem. I bet it can be done very efficiently.

> My guess is that what you really want, is pack-and-unpack routines for whole arrays.  half[0..n*2] <--> float[0..n]

What I would like is the ability to take a custom type and make a small vector out of it.

alias vec3<half> vec3h;

but as D doesn't have conversion function like C++, here is how to create such small vectors :

vec3h a = vec3h(cast(half)1.f, cast(half)2.f, cast(half)3.f);

Granted, hardly a problem and dropping conversion functions is a gain.

> It's a fascinating problem. I bet it can be done very efficiently.

I heard stories of half-float => float conversions being the bottleneck while filling mapped GPU buffers. The other one being using anything else than memcpy.