View Full Version : gluOrtho2D (left and right)

03-03-2014, 12:45 PM
I have a set up which calls


drawn my points with x between 65535.5 and 65536.5 with constant delta x of (0.025) - ( meaning current p.x = 65535.5 then the next point is p.x1 = 65535.5 + 0,025 until its greater or equalt 65536.5). I found that point that is beyond or less than 65536.0 are correctly spaced and points past 65536.0 somehow the projection is wrong (there are more space in between points).

Trying to picture it

65536.5 65536.0 65536.5
| | |
............................................. . . . . . . . . . . . . . . . . . . . . .

If Ill bring all my points to zero as my starting point (by subtracting some offset) and Ill use

things will be rendered right.

What did I miss in gluOrtho2D functionality? Is this some limitation to 16bit (65536) value?


03-03-2014, 01:29 PM
You don't have a problem with gluOrtho2D(), but with general precision.
Simply, the numbers you need cannot be represented by single precision floating-point values with enough accuracy.
Consider moving the segment to a coordinate-system origin.

03-03-2014, 02:10 PM
Thanks Aleksandar, by not moving the segment to a coodinate system origin will save me some work ( i dont have to subract some offset) which really helpful since this project is performance sensitive. Is there any other option other than moving it to the origin? Can I supply some double precision to some matrix stack?

03-04-2014, 01:12 AM
It is possible to avoid subtracting offsets, but it is not recommended, because:

1. double precision is not supported in legacy OpenGL (since you are using gluOrtho2D you are probably confined to it),

2. double precision is not supported on pre-GT200 cards and on some newer ones,

3. double precision is far more expensive than single precision even on the most powerful GPUs specially designed for double precision calculation,

4. simulating double precision in shaders is even more expensive than double precision (where it is supported)

5. try to subtract offsets, or even better make objects without that offset if it is possible, and try performance (maybe it is not as expensive as you think).

03-04-2014, 08:17 AM
Thanks , I don't have an option but to live with an offset then. Thanks once again