In my project, certain data is stored in floating point datatypes (C's native float, double). Before sending the data in a VBO to OpenGL I have to convert this data to GLfloat with some pretty silly code.

float data[DATA_SIZE];
GLfloat *new_data;

new_data = malloc(sizeof(data));
for (i = 0; i < DATA_SIZE; i++)
    new_data[i] = (GLfloat) data[i];



Of course, since I know float is equal to GLfloat on my platform, I can just ignore this but then my code won't be properly platform-independent. I could also store the data in my program in OpenGL native datatypes but this is unacceptable as I don't want to fixate my code only on OpenGL (DirectX or a software renderer are possibilities I don't want to exclude).

How can I solve this? Is the conversion step unavoidable? Or am I obligated to store my geometry in GLfloat's?


1 Answer 1


Don't do this.

On any system supporting OpenGL you will ever use, GLfloat is the same as the C/C++ native float - IEEE 754 single precision storage.

The C standard does not require IEEE 754 be used as the underlying representation, but a vanishingly small percentage of machines do not meet this criterion. C and C++ compilers will complain at compile-time if GLfloat is not equivalent to float, because then a GLfloat * is not compatible with a float *. So even in the (0%) chance you do end up on one of these systems, you will have plenty of warning.

Other types, such as GLint, are more relevant, because there are a small but significant number of systems where ints are 16 bits and in these cases you will find GLint aliased to a type permitting at least 32 bits of storage. However, in any game programming task, you are very unlikely to use these kind of systems.

  • \$\begingroup\$ Thanks for the answer. Still, what do I do with doubles, those need to be converted for sure. I also don't know what the OpenGL standard says, but can I be sure GLfloat will be 4 bytes long and not 8 or 2? \$\endgroup\$
    – Kasper
    Oct 11, 2011 at 14:15
  • 5
    \$\begingroup\$ Yes, doubles "must" be converted to floats. So don't use doubles. \$\endgroup\$
    – user744
    Oct 11, 2011 at 15:49
  • 2
    \$\begingroup\$ You can't possibly have to use doubles anywhere near your renderer, because they won't render with that level of precision. It may make sense to use some doubles somewhere else to ensure accurate integer promotion or whatever for the duration of some computation, but if you're storing them long-term you're going to end up regretting it in many ways (no/less SIMD, blown caches, higher memory bandwidth requirements). \$\endgroup\$
    – user744
    Oct 12, 2011 at 5:31
  • 2
    \$\begingroup\$ I'm making a space simulation. At the distance of the moon (and I need the whole solar system) the distance between two subsequent float's is 32 meters! Vastly insufficient. So when I want to render something, the logic part of my program sends out some doubles that I have to cast to floats. My meshes and other render-specific data are of course stored in float's. \$\endgroup\$
    – Kasper
    Oct 12, 2011 at 12:56
  • 3
    \$\begingroup\$ But if you convert the doubles to floats you will lose precision and things will render wrong. You need a better solution. Doubles are not the answer. \$\endgroup\$
    – user744
    Oct 12, 2011 at 12:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .