1. I am part of a group which is pretending to develop a 3D-engine, and I suggested working with HOpenGL. Some people liked some functionalities of HOpenGL, but they would like to know if it is possible to work with C/C++ code AND issue some calls to HOpenGL routines. Is it possible? Or the only way is to work around with the FFI? 2. People were surprised when I told that GLUT (the one that "came with" HOpenGL) supports joystick. They said that it normally doesn't. So here comes my second question: is the joystick support a specific HOpenGL functionality? -- Andre
Andre W B Furtado wrote:
[...] they would like to know if it is possible to work with C/C++ code AND issue some calls to HOpenGL routines. Is it possible? Or the only way is to work around with the FFI?
I'm not sure if I understand you correctly: Do you want to write the engine in Haskell or C/C++?
2. People were surprised when I told that GLUT (the one that "came with" HOpenGL) supports joystick. They said that it normally doesn't. So here comes my second question: is the joystick support a specific HOpenGL functionality?
Nope, it's a WinDoze-specific part of GLUT. It's really a shame that GLUT is not being developed any further, due to some silly copyright stuff and Mark Kilgard's strange attitude towards releasing it to the open source community. :-( Adding e.g. X11 joystick support would basically be a piece of cake... Cheers, S.
I'm not sure if I understand you correctly: Do you want to write the engine in Haskell or C/C++?
Ok, sorry... I think the team would like to write the engine in C/C++. If it is not possible to do this AND call HOpenGL routines, I then ask if the only way to integrate both languages (C++ & Haskell) is via FFI... (in this case, I think the engine MUST be written in Haskell, am I right?) -- Andre
Andre W B Furtado wrote:
[...] I think the team would like to write the engine in C/C++. If it is not possible to do this AND call HOpenGL routines [...]
Hmmm, if the engine should be written in C/C++, I can't see a reason to use HOpenGL at all: Just use the ubiquitous C binding for OpenGL! The only further advice I can give then is to avoid hammering OpenGL into something OO, just use it imperatively within C++. It's a state machine of which you have only one instance of, so the potential for OO stuff is quite limited. The only thing I can imagine is using C++'s ad-hoc overloading to reduce the plethora of calls a bit. Note that I'm not against OO at all (after all, I'm using Java/C++ at work), but not everything fits nicely into a single paradigm. Cheers, S.
participants (2)
-
Andre W B Furtado -
Sven Panne