OpenGL/GLUT/API?

I have a simple question. If I want to make a game like Quake 3, what do I need except OpenGL itself? I believe GLUT is out of the question. What about pure API or a framework (like MFC)? Exactly what do I need except OpenGL (and great knowledge of 3D) to make a real game?

Thanks in advance!
/Chris, Sweden

In theory you could use GLUT. In practice, however, it has its limitations. On the other hand you can come a long way with GLUT, and if you wrap it the right way you can always switch later.

If you are talking about a fullblown game engine you are in for some work, and the question “To GLUT or not to GLUT” is hardly very relevant compared to other issues. In that case you may be better of looking for some free/cheap game engine to start with.

Ok, so what does a game engine need in terms of toolkits/APIs?

  1. OpenGL
  2. A windowing toolkit/API
  3. A input device toolkit/API
  4. A sound/music toolkit/API

…plus more (geometry toolkit? file import? networking? threads? etc).

If you want to rely on a portable & easy to use toolkit, such as GLUT, but more suitable for game development, you should have a look at GLFW .

Ok, sounds reasonable. So what would you recommend in my case? I know Win32API pretty well, but I have just started with OpenGL. I’m not going to make a game at once, of course, but I want to know what opportunities there are in the world of OpenGL =). I guess fmod is the best choice when it comes to the sound API, but what about the input API? I can’t make up my mind, whether to use DirectX or OpenGL+other APIs. Convince me! =)

Another option over GLUT/FMOD is SDL (Sound Device library), which gives better keyboard control, joystick, etc and add’s sound control. SDL is also crossplatform, so programing with it will let you easly move your program to say Mac or Linux.

With directX for input and sound you are limited to only a Windows machine.

Originally posted by znakeeye:
Ok, sounds reasonable. So what would you recommend in my case? I know Win32API pretty well, but I have just started with OpenGL. I’m not going to make a game at once, of course, but I want to know what opportunities there are in the world of OpenGL =). I guess fmod is the best choice when it comes to the sound API, but what about the input API? I can’t make up my mind, whether to use DirectX or OpenGL+other APIs. Convince me! =)

Being the author of GLFW, I would say GLFW+FMOD (or some other sound toolkit)

GLFW has very good input handling (ISO-8859-1 + Unicode + most special keys incl. left/right versions of modifiers etc + joystick + mouse), a very good timer source, and is very portable. Presently supported by all Windows versions (excl. WinCE) + Linux + Solaris + Irix + AmigaOS etc. Mac OS X + QNX + FreeBSD + MS-DOS suppport is soon ready to ship.

If you’re making a fullscreen game like Quake, why do you need advanced Windowing functionality? Why exactly would GLUT be not up to the task?

I could see the problems if you were creating a MDI Windows CAD program, with lots of dialogs, window, etc., but not a fullscreen game.

Originally posted by starman:
If you’re making a fullscreen game like Quake, why do you need advanced Windowing functionality?

As Marcus said, GLUT have very poor input handling, and for a game like quake, it is important.
GLFW is very good for that, with high-res timer and the like. And multi-platform.
Still missing is pbuffer support and complete thread-safe API (for my particuliar project). Need help, Marcus ?

use the windows system sdk, for openGL interfacing, then look to the manufacturers for your extensions and higher level support. ofcoarse you can always download the specifications from this site, just make sure your OpenGL32.dll is inline with what specification your using. use glGetString to get the version.

i used DirectInput for my API of choice under the relms of input, its got a nice way of enumerating devices and device objects, i then dynamically tree all that out, and use call backs / branch entry points for checking device states, i threaded the device root so i get constant updates, the thread is also controlled so it gives up its time since its not a very intensive thread taking up too much time from graphics.

Originally posted by ZbuffeR:
Still missing is pbuffer support and complete thread-safe API (for my particuliar project).

I know that the lack of support for pbuffers is a problem for many people. However, the way I want it implemented is in line with how I would like to implement support for multiple windows, which has to do with how I would like to make GLFW thread safe In other words, it’s a major API change, and will not happen until GLFW 3.0. It’s something that will affect all platforms, and I want all current implementations to be stable before taking that step.

Suggestion (regarding thread safety): Don’t call GLFW functions from different threads (most function deal with window/OpenGL context anyway, and should be called from the same thread that has created/bound the context - that’s how OpenGL works, that’s how GLFW 3.x will work). Also, you can protect GLFW calls manually with a mutex.

Need help, Marcus ?

I can always use help Contact me if you want to join the GLFW sourceforge team.

However, I think I will do most of the actual pbuffer/thread safe implementations myself (since it spans all platforms, and I think I have the best insight into all the code for the supported platforms ).

I could really use some help with the X11 implementation though (I’m currently having problems with window iconification + overrideredirect…).

[This message has been edited by marcus256 (edited 12-08-2003).]