FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

(float, float) vs. Point vs Point.tupleof

 
Post new topic   Reply to topic     Forum Index -> ArcLib
View previous topic :: View next topic  
Author Message
clayasaurus



Joined: 21 May 2004
Posts: 857

PostPosted: Fri Apr 27, 2007 10:54 am    Post subject: (float, float) vs. Point vs Point.tupleof Reply with quote

(float, float) vs. Point vs Point.tupleof

Problem: The problem is to use either two floats for function arguments that represent a point, or just a Point struct .

Solutions:

Only use (float, float) --> Bad : You have to take things out of point form to use it
Only use (Point) --> Bad : Then you have to force something into point form to use it

Use both (float, float) and (Point), let the user pick --> Great for user, annoying for us on the developer side to maintain code like this, but may be best option

Only use (float, float) and then if wanting to use point, simply use (point.tupleof) --> Good for developer, pretty annoying on the user side to remember to write .tupleof

My thoughts and opinions.
~ Clay
Back to top
View user's profile Send private message AIM Address
ChristianK



Joined: 26 Sep 2006
Posts: 159
Location: Berlin, Germany

PostPosted: Sat Apr 28, 2007 3:30 am    Post subject: Reply with quote

There are pros and cons for both ways. I prefer using Points because:

- working with them (from elementary operations, like adding, to rotation etc.) becomes easier
- it keeps the number of function arguments down
- constructing points is rather cheap (.tupleof is probably free though)
- I think in points, not their components
Back to top
View user's profile Send private message
clayasaurus



Joined: 21 May 2004
Posts: 857

PostPosted: Wed May 02, 2007 12:04 pm    Post subject: Reply with quote

Alright, so let's use

Points

&

Color

instead of (x,y) and (r,g,b,a)

in function parameters.

Tickets

Color
http://www.dsource.org/projects/arclib/ticket/34#preview

Point
http://www.dsource.org/projects/arclib/ticket/35#preview
Back to top
View user's profile Send private message AIM Address
Brix



Joined: 28 Oct 2006
Posts: 21
Location: EU, Denmark, Lyngby.

PostPosted: Wed May 02, 2007 2:32 pm    Post subject: Reply with quote

Could we also get support for floating point colors? (for opengl/3D)

I'm currently using this:
Code:
///Color class, using floating point (0.0f-1.0f) for color representation.
class Colorf
{
public:
   ///Constructor.
   this(float r, float g, float b, float a = 1.0f)
   {
      this.r = r;
      this.g = g;
      this.b = b;
      this.a = a;
   }
   
   ///Color components.
   float r=1.0f, g=1.0f, b=1.0f, a=1.0f;
}

///Color class, using ushort (0-255) for colors.
class Coloru : Colorf
{
public:
   ///Constructor.
   this(ushort r, ushort g, ushort b, ushort a = 255)
   {
      super(cast(float)r/255, cast(float)g/255, cast(float)b/255, cast(float)a/255);
   }
   
   ///Get the red component.
   ushort r()
   {
      return cast(ushort)(super.r*255);
   }
   
   ///Get the green component.
   ushort g()
   {
      return cast(ushort)(super.g*255);
   }
   
   ///Get the blue component.
   ushort b()
   {
      return cast(ushort)(super.b*255);
   }
   
   ///Get the alpha component.
   ushort a()
   {
      return cast(ushort)(super.a*255);
   }
}

- Brix
Back to top
View user's profile Send private message MSN Messenger
ChristianK



Joined: 26 Sep 2006
Posts: 159
Location: Berlin, Germany

PostPosted: Fri May 04, 2007 4:01 pm    Post subject: Reply with quote

Hm. I don't think giving reference semantics to Colors is a good idea. However, if we used two seperate structs, we'd need a lot of overloads.

I've no idea about the technical details: can you do anything with ushort Colors that you can't do with float Colors or vice versa? If one of them is more general, we could go with that one.
Back to top
View user's profile Send private message
Brix



Joined: 28 Oct 2006
Posts: 21
Location: EU, Denmark, Lyngby.

PostPosted: Fri May 04, 2007 4:43 pm    Post subject: Reply with quote

Well I believe a float is able to represent a higher range of colors. But on the other hand ushort colors seems more natural (or atleast easier to use).

Here is some info about the opengl color mapping: http://www.glprogramming.com/blue/ch05.html#id5458953
Back to top
View user's profile Send private message MSN Messenger
clayasaurus



Joined: 21 May 2004
Posts: 857

PostPosted: Sat May 05, 2007 1:32 am    Post subject: Reply with quote

I kind of like the ushort version myself.

Maybe we can do some math to convert

float -> ushort values on set routines in color and
ushort -> float on get routines in color

so you can still set/get floats with color, but it would be stored internally as ushorts.
Back to top
View user's profile Send private message AIM Address
ChristianK



Joined: 26 Sep 2006
Posts: 159
Location: Berlin, Germany

PostPosted: Sat May 05, 2007 1:42 am    Post subject: Reply with quote

Okay then: it seems OpenGL uses floats internally. Also our current implementation uses ushorts to store the colors, but then uses the ubyte GL method. Unsigned bytes can definitely represent a far smaller color range than floats.

I propose we use floats for the internal representation in Color and provide an ubyte constructor for compatibility, so (hopefully) no code has to be changed. Except for the glColor4ub calls, which would become glColor4f - or preferably a seperate call.

I've created a ticket (http://www.dsource.org/projects/arclib/ticket/47) and will do it today.

EDIT:
Quote:
float -> ushort values on set routines in color and
ushort -> float on get routines in color

so you can still set/get floats with color, but it would be stored internally as ushorts.


Since floats offer more than ubytes, I recommend doing it the other way around. It's transparent to the user anyway.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic     Forum Index -> ArcLib All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group