Re: [Opensg-core] Real32 <-> Fixed32

[Gerrit V. <vo...@ca...>]

Hi,

On Sun, 2006-07-23 at 13:39 -0500, Dirk Reiners wrote:
> 	Hi Gerrit,
> 
> On Sun, 2006-07-23 at 14:55 +0800, Gerrit Voss wrote:
> > Hi,
> > 
> > just a short question as I want to finalize the embedded OSG version.
> 
> OK. When do you expect to commit it?

As soon as possible, currently I have 3 different versions lying around
(Normal, std C pointer and embedded) and I really want to have them 
back as one. This also keeps me from moving stuff to svn as I don't
want to open another manual sync area ;-)

> >
> > Any opinions or other solutions ??
> 
> I'm a little worried about the impact on existing code and the users.
> Will these changes be visible to the users, how will they impact them? 

They will be visible but they should not impact the user or existing
code, at least under normal use Real32 is still a 32 bit float so
everything should work as expected. As they move to embedded systems
they will have enough other challenges to be worried about ;-)) And
usually a move to embedded systems is not something that suddenly has
happened when you arrive at work the next morning ;-)

> Personally I'd prefer the typedefs without namespace. That also allows
> you to force some things to float, if necessary, by using the Float
> type, 

this forcing is possible in both versions.

> so I'm not sure what the benefit of the namespace version is.

the namespaces originated more from wrapping OpenGL functions. As they
are C functions overloading is not available. What I wanted to avoid is
having to use #ifdef all over the code when calling either OpenGL or
OpenGL ES. Another side effect is that you do not need new names. The
Real32, Float32 and Fixed32 was one example but this  will extend to
every dependent type like Vec, Pnt, Matrix, ..... Keeping them in a
namespace allows us to keep the OpenSG names as they are and only change
the parts that are used on embedded systems. 

Probably we should make it more general not only covering float and fix
point but double too. Parts of OpenSG are flexible enough to work with
double (e.g. the Geometry) others are not (transform, volumes, culling).

Basically it would be dropping the 32 from some of the float parts. So 
instead of Real32 or Vec3f we could start to use general Real or Vec3(r)
types.

regards,
  gerrit