Thread overview
Re: D demoscene compo
Mar 23, 2009
bearophile
Mar 23, 2009
ponce
Mar 23, 2009
bearophile
March 23, 2009
ponce:
> Source is released.

I have found this only now, thanks to http://planet.dsource.org/

I have seem there's lot of code like this one:
vec3!(T) xxx() { return vec3!(T)(x, x, x); }
vec3!(T) xxy() { return vec3!(T)(x, x, y); }
vec3!(T) xxz() { return vec3!(T)(x, x, z); }
etc etc ...

D1 allows you to do such things with less code (but less easy to understand):

import std.metastrings: Format;
import d.templates: Range;

string product3(char[3] s)() {
    string result;
    foreach (i; Range!(3))
        foreach (j; Range!(3))
            foreach (k; Range!(3))
                result ~= Format!("vec3!(T) %s() { return vec3!(T)(%s, %s, %s); }\n",
                                  ""~s[i]~s[j]~s[k], s[i], s[j], s[k]);
    return result;
}
pragma(msg, product3!("xyz")());
void main() {}

That can also be generalized in a compile-time general product, but it may be overkill.

Regarding the vec2D, vectors 3D, quaternions, segment-point distance, point-in-polygon, etc: most of such functions/classes/structs are present in most demos and games I have seen written in D, so I think such stuff deserves to be in the std libraries (Phobos and Tango), (part of that stuff is already present in my d libs, but this means little), avoiding people to re-implement them all the time. If you want you can polish such geometric code of yours, and offer it as a single module to Walter (with a license fitting for Phobos).

Bye,
bearophile
March 23, 2009
bearophile Wrote:

> ponce:
> > Source is released.
> 
> I have found this only now, thanks to http://planet.dsource.org/
> 
> I have seem there's lot of code like this one:
> vec3!(T) xxx() { return vec3!(T)(x, x, x); }
> vec3!(T) xxy() { return vec3!(T)(x, x, y); }
> vec3!(T) xxz() { return vec3!(T)(x, x, z); }
> etc etc ...
> 
> D1 allows you to do such things with less code (but less easy to understand):
> 
> import std.metastrings: Format;
> import d.templates: Range;
> 
> string product3(char[3] s)() {
>     string result;
>     foreach (i; Range!(3))
>         foreach (j; Range!(3))
>             foreach (k; Range!(3))
>                 result ~= Format!("vec3!(T) %s() { return vec3!(T)(%s, %s, %s); }\n",
>                                   ""~s[i]~s[j]~s[k], s[i], s[j], s[k]);
>     return result;
> }
> pragma(msg, product3!("xyz")());
> void main() {}
> 
> That can also be generalized in a compile-time general product, but it may be overkill.
> 

At the time this code was written I didn't knew about such "C-preprocessor"-like templates. Thanks. My code is clearly not smart enough and there could have been only one matrix and one vector class.

> Regarding the vec2D, vectors 3D, quaternions, segment-point distance, point-in-polygon, etc: most of such functions/classes/structs are present in most demos and games I have seen written in D, so I think such stuff deserves to be in the std libraries (Phobos and Tango), (part of that stuff is already present in my d libs, but this means little), avoiding people to re-implement them all the time. If you want you can polish such geometric code of yours, and offer it as a single module to Walter (with a license fitting for Phobos).
> 
> Bye,
> bearophile

This may be a problem since every game-orientated library and 3D programmer will redefine its own vectors/matrices/quaternions. At a certain point it is enjoyable but time-consuming. In fact everyone seems to like having its own vectors/matrices classes, so to be accepted as standard it has to be efficient, non-obtrusive and with short names.

I think starting with some code from Defend would be more appropriate since it's already more template-aware and better tested.
March 23, 2009
ponce:
> In fact everyone seems to like having its own vectors/matrices classes, so to be accepted as standard it has to be efficient, non-obtrusive and with short names.<

Regarding the short names, most times the import alias:
import std.geometry: v3d = vector3d;
plus the normal alias and compound aliases and the typedefs are probably enough to avoid you the need to rewrite things just to have different names :-)

Bye,
bearophile