www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Vibrant 1.5

reply ponce <contact gamesfromILOVESPAMmars.fr> writes:
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
Sep 04 2010
parent reply ponce <contact gamBOOMesfrommars.fr> writes:
Vibrant has been open source'd (again):
http://bitbucket.org/ponce/vibrant
Sep 20 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
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
Sep 20 2010
next sibling parent Johan Granberg <lijat.meREM OVEgmail.com> writes:
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
Sep 21 2010
prev sibling next sibling parent reply Don <nospam nospam.com> writes:
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.
Sep 21 2010
next sibling parent #ponce <contact gamCOOKIESesfrommars.fr> writes:
 
 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. ;)
Sep 21 2010
prev sibling parent so <so so.do> writes:
On Tue, 21 Sep 2010 11:59:51 +0300, Don <nospam nospam.com> wrote:

 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.
You know vectors are one of the hardest things to implement if you want everything. In D2 it should possible to have it all! My ideal vector design : - one struct for all dimensions. - swizzling - after a limit (dimension) you have a choice to use either unwrapping or plain for. - avoid temporaries as much as possible. - policy to use sse. etc... Can't think of anything more now. First 3 is very easy to implement, 4 wasn't possible on C++ because of aliasing, didn't give much of a thought in D, 5 also shouldn't be that hard. alias vector!(3, float) vec3; alias vector!(4, float) vec4; ... There we solved everything! in theory :) -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Oct 09 2010
prev sibling parent reply #ponce <contact gamCOOKIESesfrommars.fr> writes:
 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.
Sep 21 2010
next sibling parent #ponce <contact gamCOOKIESesfrommars.fr> writes:
Errata: A good rounding routine should be based on FISTTP which avoid messing
with the rounding mode entirely.
Sep 21 2010
prev sibling parent reply Don <nospam nospam.com> writes:
#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.
Sep 21 2010
parent reply #ponce <contact gamCOOKIESesfrommars.fr> writes:
 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.
Sep 21 2010
parent reply #ponce <contact gamCOOKIESesfrommars.fr> writes:
 vec3h a = vec3h(cast(half)1.f, cast(half)2.f, cast(half)3.f);
In C++ I can make the half type and create vec3h with vec3h a = vec3h(1, 2.f, 3); because so much thing are implicit.
 I heard stories of half-float => float conversions being the bottleneck
I meant float -> half-float
Sep 21 2010
parent Don <nospam nospam.com> writes:
#ponce wrote:
 vec3h a = vec3h(cast(half)1.f, cast(half)2.f, cast(half)3.f);
In C++ I can make the half type and create vec3h with vec3h a = vec3h(1, 2.f, 3); because so much thing are implicit.
 I heard stories of half-float => float conversions being the bottleneck
I meant float -> half-float
My friend Google found some SSE2 code which does float->half in 3.5 cycles. Not too bad. http://www.devmaster.net/forums/showthread.php?t=10924
Sep 21 2010