View previous topic :: View next topic |
Author |
Message |
clayasaurus
Joined: 21 May 2004 Posts: 857
|
Posted: Fri Apr 27, 2007 10:54 am Post subject: (float, float) vs. Point vs Point.tupleof |
|
|
(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 |
|
|
ChristianK
Joined: 26 Sep 2006 Posts: 159 Location: Berlin, Germany
|
Posted: Sat Apr 28, 2007 3:30 am Post subject: |
|
|
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 |
|
|
clayasaurus
Joined: 21 May 2004 Posts: 857
|
|
Back to top |
|
|
Brix
Joined: 28 Oct 2006 Posts: 21 Location: EU, Denmark, Lyngby.
|
Posted: Wed May 02, 2007 2:32 pm Post subject: |
|
|
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 |
|
|
ChristianK
Joined: 26 Sep 2006 Posts: 159 Location: Berlin, Germany
|
Posted: Fri May 04, 2007 4:01 pm Post subject: |
|
|
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 |
|
|
Brix
Joined: 28 Oct 2006 Posts: 21 Location: EU, Denmark, Lyngby.
|
Posted: Fri May 04, 2007 4:43 pm Post subject: |
|
|
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 |
|
|
clayasaurus
Joined: 21 May 2004 Posts: 857
|
Posted: Sat May 05, 2007 1:32 am Post subject: |
|
|
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 |
|
|
ChristianK
Joined: 26 Sep 2006 Posts: 159 Location: Berlin, Germany
|
Posted: Sat May 05, 2007 1:42 am Post subject: |
|
|
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 |
|
|
|
|
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
|