Re: [HOpenGL] 2D textures with OpenGL and GLUT

On Wed, Jul 2, 2014 at 9:33 AM, Elise Huard
Hi Jason, thanks for taking the time to answer. So trying to read between the lines: - do you have any _working_ examples of texture mapping with OpenGLRaw and low-level Haskell I could have a look at? (anything would help at this point)
I do. I converted some of the old nehe tutorials: https://github.com/dagit/nehe-tuts If you look through the history you can find examples that use a very very old version of OpenGL (instead of OpenGLRaw). The OpenGL style in those examples is old and no longer the recommended way. The examples use immediate mode which is now deprecated in favor of shaders. I think lesson 6 makes a cube and throws some textures on it. The lesson numbers are meant to match these: * http://nehe.gamedev.net/tutorial/lessons_01__05/22004/ * http://nehe.gamedev.net/tutorial/lessons_06__10/17010/
- do you think the unsafeCoerce (which I borrowed from examples) that transform CpFloat to GLdouble might be the issue, or is this just a general stylistic comment?
Not just stylistic. As for correctness, I think the answer varies by platform. Specifically, I think CFloat is not required to match GLdouble in size (in fact, doubles should be expected to be twice as big). While both types should correspond to IEEE 754 floats the bit width is very likely different and that could easily cause the interpretation of the values to go wonky. Imagine passing 64bits when only the first 32bits correspond to a valid number or truncating a 64bit value to 32bits. Which examples use unsafeCoerce for this? I'm just sort of curious so I can recommend people not to use them :)

I wanted to thank you, because pointing to unsafeCoerce was a nice bit
of serendipity. I'll admit I thought it was nitpicking initially, but
I did a quick pass at cleaning things up last week after your mail
(not perfect, but this was a prototype so I'm not looking for pretty):
https://github.com/elisehuard/game-prototype/commit/5cf85fa60f325dbe610b5e1f...
and that fixed the texture mapping!
Consider me informed on that issue :)
(as for which example, I used Redbook4 but I admit to extrapolating a
little, this was my mistake)
Thank you,
On 2 July 2014 13:11, Jason Dagit
On Wed, Jul 2, 2014 at 9:33 AM, Elise Huard
wrote: Hi Jason, thanks for taking the time to answer. So trying to read between the lines: - do you have any _working_ examples of texture mapping with OpenGLRaw and low-level Haskell I could have a look at? (anything would help at this point)
I do. I converted some of the old nehe tutorials: https://github.com/dagit/nehe-tuts
If you look through the history you can find examples that use a very very old version of OpenGL (instead of OpenGLRaw). The OpenGL style in those examples is old and no longer the recommended way. The examples use immediate mode which is now deprecated in favor of shaders.
I think lesson 6 makes a cube and throws some textures on it. The lesson numbers are meant to match these: * http://nehe.gamedev.net/tutorial/lessons_01__05/22004/ * http://nehe.gamedev.net/tutorial/lessons_06__10/17010/
- do you think the unsafeCoerce (which I borrowed from examples) that transform CpFloat to GLdouble might be the issue, or is this just a general stylistic comment?
Not just stylistic. As for correctness, I think the answer varies by platform. Specifically, I think CFloat is not required to match GLdouble in size (in fact, doubles should be expected to be twice as big). While both types should correspond to IEEE 754 floats the bit width is very likely different and that could easily cause the interpretation of the values to go wonky. Imagine passing 64bits when only the first 32bits correspond to a valid number or truncating a 64bit value to 32bits.
Which examples use unsafeCoerce for this? I'm just sort of curious so I can recommend people not to use them :)

On Tue, Jul 8, 2014 at 9:20 AM, Elise Huard
I wanted to thank you, because pointing to unsafeCoerce was a nice bit of serendipity. I'll admit I thought it was nitpicking initially, but I did a quick pass at cleaning things up last week after your mail (not perfect, but this was a prototype so I'm not looking for pretty):
https://github.com/elisehuard/game-prototype/commit/5cf85fa60f325dbe610b5e1f...
and that fixed the texture mapping! Consider me informed on that issue :)
Cool! By the way, the 'proper way' to convert between Double and CDouble is to use realToFrac: Prelude Foreign.C.Types λ> realToFrac (1 :: Double) :: CDouble 1.0 In specific case like this (Double <-> CDouble) it should be equivalent (but as a user of the library you shouldn't depend on know that). In some cases it can be a performance hit, but that's what RULEs pragmas are for. Moreover, some versions of the Haskell OpenGL bindings made it so that GLdouble was not the same type as CDouble. So the safest way is to use realToFrac and depend on the library writer to provide RULEs that make it efficient. I hope that helps, Jason

Definitely, I want to avoid unsafeCoerce completely.
thanks,
Elise
On 8 July 2014 12:32, Jason Dagit
On Tue, Jul 8, 2014 at 9:20 AM, Elise Huard
wrote: I wanted to thank you, because pointing to unsafeCoerce was a nice bit of serendipity. I'll admit I thought it was nitpicking initially, but I did a quick pass at cleaning things up last week after your mail (not perfect, but this was a prototype so I'm not looking for pretty):
https://github.com/elisehuard/game-prototype/commit/5cf85fa60f325dbe610b5e1f...
and that fixed the texture mapping! Consider me informed on that issue :)
Cool! By the way, the 'proper way' to convert between Double and CDouble is to use realToFrac:
Prelude Foreign.C.Types λ> realToFrac (1 :: Double) :: CDouble 1.0
In specific case like this (Double <-> CDouble) it should be equivalent (but as a user of the library you shouldn't depend on know that). In some cases it can be a performance hit, but that's what RULEs pragmas are for. Moreover, some versions of the Haskell OpenGL bindings made it so that GLdouble was not the same type as CDouble. So the safest way is to use realToFrac and depend on the library writer to provide RULEs that make it efficient.
I hope that helps, Jason
participants (2)
-
Elise Huard
-
Jason Dagit