• bearophile <bearophileHUGS lycos.com> Mar 22 2009
• ponce <aliloko gmail.com> Mar 23 2009
• bearophile <bearophileHUGS lycos.com> Mar 23 2009

bearophile <bearophileHUGS lycos.com> writes:

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

ponce <aliloko gmail.com> writes:

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. 

bearophile <bearophileHUGS lycos.com> writes:

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