C. Reinke wrote:
Issue OpenGL calls *after* the first createWindow, never before.
Isn't that an argument against the displayFunc parameter to HOpenGL's createWindow? One could still have a createSimpleWindow or something for simple applications, but why pass and install a null handler if one most certainly needs to replace it soon?
This would break the current API, so I'd vote against such a change for HOpenGL 1.x, but I'm open for suggestions for an additional function (OK, this *could* break applications, too, but it's much less likely). I would propose to leave createWindow as it is and add: createWindow' :: String -> [DisplayMode] -> Maybe WindowPosition -> Maybe WindowSize -> IO Window Any comments?
I was fooled by display lists [...]
Who wasn't? :-} It has been a little bit unclear to me for a long time (and obviously other people, too) that creating a GLUT window or an overlay effectively creates a new OpenGL state machine and you start with none at all. A look in the GLX spec was helpful... [ exitWith vs. shutdownHaskellAndExit vs. hs_exit ] To keep easy backwards compatibility, the GLUT module will contain wrappers/re-implementations for GHC's currently faulty (IMHO) functions from System, so you can issue exitWith ExitSuccess without getting a cryptic RTS message. A new compatibility release of HOpenGL will be released very soon, I'm just in the middle of fighting a number of small issues regarding different compilers, OpenGL implementations, OS variations, etc. *sigh* Cheers, S.