What is the best?

Hy guys!

I’m part of a young group who is interested in creating a 2D strategy game that will run both on Linux and Windows. While I say that it’ll be a 2D game (lots will be in an isometric view) we might need some 3D functionality in the future.

Now, what toolkit would be the best? Major requirements is that it supports both Linux and Windows and that it has a good amount of documentation. It should also be capable to support an entire game. An advantage would be that it was a tool that is part of the Open Source community.

thanks for all feedback!

and we still need programmers, so if you are interested… you can always tell me

Just opinion but I think that GLUT is the best if portability is your goal.

As for an entire engine I am not sure, I am not there yet but I am sure that it can handle it.

1 vote for GLUT

Hehehe,

well, I was also in favour of GLUT, so 2 votes for GLUT

[This message has been edited by kvaruni (edited 04-11-2002).]

[This message has been edited by kvaruni (edited 04-11-2002).]

Carrying extra DLL(glut.dll) with your game, I don’t think you’ll like it.

Originally posted by kvaruni:
[b]Hy guys!

I’m part of a young group who is interested in creating a 2D strategy game that will run both on Linux and Windows. While I say that it’ll be a 2D game (lots will be in an isometric view) we might need some 3D functionality in the future.

Now, what toolkit would be the best? Major requirements is that it supports both Linux and Windows and that it has a good amount of documentation. It should also be capable to support an entire game. An advantage would be that it was a tool that is part of the Open Source community.

thanks for all feedback!

and we still need programmers, so if you are interested… you can always tell me [/b]

Cpw currently supports Win32. GLFW currently supports Linux and Win32. Both are free source. GLUT supports every platform known to man. Unfortunately the GLUT source is gross to look at and debug, buggy, and is not open source. Hence Cpw and GLFW.

Good luck!

There is also a C++ option in the form
of the GLT C++ OpenGL ToolKit. It
includes GlutMaster wrapper objects for
GLUT, with the intention of supporting other
back-ends such as CPW or SDL. At the
moment GLUT is supported, and soon a
native Win32 screen-saver back-end will be
included:
http://www.nigels.com/glt/

LGPL open-source license.

GLT also supports static linking of GLUT,
textures and fonts. This eliminates the
problems of extraneous DLL’s and data files.

[This message has been edited by nigels (edited 04-24-2002).]

I would vote for GLFW .
It is much more game oriented than GLUT, and it supports Win32 and most Unix/X11 environments (including Linux).

It has some features that GLUT lacks: high resolution timer, multi threading support, very good fullscreen support, etc. And it’s open source. You also have full control over the “main loop”, since you write it yourself (GLFW does not use a glutMainLoop() model).

glut!! Ive been using it on linux its great. So what if your game has an extra dll?

If you use glut, and can compile source code
and make dll’s, .a’s or whatever you need,
then check out …
http://www-users.york.ac.uk/~rpf1/glut.html

There you get a fix for glutMainLoop() as I provide a glutCheckLoop() which will process events and timers and return … so you CAN make your own “event loop”.

glutMainLoop() is still available, implemented internally as

 for(;;) glutCheckLoop();

Also … an elegant fix (I think so ) for the nasty window close behaviour of glut. If you close ANY window the whole application is killed with an “exit(0);”.

I provide glutWMCloseFunc( (func*) (void) )

which will let you register a window close event handler for each window. This will let you catch the user shutting the window via the Window Manager, and allow you to do the right thing … e,g., warn, close down gracefully etc etc …

Rob.

[This message has been edited by Rob Fletcher (edited 05-14-2002).]

Did I mention that GLFW is compact? A simple fullscreen game (3D version of PONG), is less than 30 KB (executable, including GLFW). What would the corresponding figure be with GLUT?

I also think the GLFW timer is better than the GLUT timer (the GLFW timer unsually has a resolution better than 1 us).

And of course the fullscreen support is smashing You can even change video modes under Linux (not possible with GLUT GameMode).

[This message has been edited by marcus256 (edited 05-14-2002).]

Once the new callback functionality is built into GLFW, then the small size, and full screen mode and threads support should make GLFW attractive!

You see Marcus (I’m not biased towards GLUT, just that if a user is going to use GLUT, then they should know the pitfalls and also that there is help and expertise around).

Also, of course, GLUT is not being actively developed (it should be really!).

The poor timing of GLUT really goes back to its roots (Unix), where in a sense the idea of having a “real time” clock for user use, in a multi user environment, just did not make sense. Many people use Linux these days as a single user Unix.

Note, I was not voting for one or the other.

Cheers,

Rob.

> … should make GLFW attractive!

I hope so

The poor timing of GLUT really goes back to its roots (Unix), where in a sense the idea of having a “real time” clock for user use, in a multi user environment, just did not make sense.

I realise that. On the other hand, for many purposes (gaming being one of them), you really need a timer with at least 1 ms resolution (already such a poor resolution gives you 10% frame-time error for a 100 fps game).

Actually, SGI/IRIX stations have a free running high resolution (e.g. 40 ns) timer, which can be used directly by user level programs (of course GLFW uses this timer on IRIX computers), wihch just goes to prove that such functionality is necessary for real-time interactive applications (which is one of the traditionally most important areas for SGI stations), even for Unix stations.

3D games are inherently single user applications (at least they require the kind of dedicated performence to mimic a single user environment - e.g. one 3D accelerator and one CPU per gamer), which is one of the reasons that I think a high resolution timer is necessary.

“Actually, SGI/IRIX stations have a free running high resolution (e.g. 40 ns) timer
…”

Yes, I know, one reason I use SGI O2’s … also, texture memory is simply part of main memory … need more textures, add more memory! Last app use 35 megabytes of textures, all preloaded, mipmapped etc.

Video buffers are also simply main mem, so you can easily have live vid coming in, and
grab that bit of memory for a texture …
map it to a mesh and distort incoming video.

The timing is also useful for music apps as
well (audio and midi).

Rob.