GLUT for dim3, Should I be Talked out of It?

[ggadwa]

Still trying to figure out how I want to make dim3 cross platform, or at least start it. There are things about SDL that bug me, so I was looking into GLUT. I am an expert in neither of them (always used the system to calls for these.)

Anybody want to give me the quick run down of pros and cons? GLUT seems quiet a bit lighter and cleaner, but obviously isn't centered totally on maxing speed (like SDL is.) This is, of course, an educated guess :)

Any help would be appreciated.

I assume most of glut is supported in windows/linux.

[>] Brian

[OneSadCookie]

speed isn't an issue, but things like keyboard, mouse-look, resolution switching, etc. would be killers for Dim3.

* you can't distinguish between the number keys and the keypad
* you can't tell that 4 and $ (or £, or whatever, depending on keyboard layout) are from the same key, just with different modifiers
* you can't detect modifier key presses in isolation
* although you can use glutWarpPointer to implement mouse look on most platforms, it doesn't work without making an additional mac-specific call on Mac OS X
* glutLeaveGameMode doesn't work on Mac OS X
* there's no way to get a list of supported video resolutions

[ggadwa]

speed isn't an issue, but things like keyboard, mouse-look, resolution switching, etc. would be killers for Dim3.

* you can't distinguish between the number keys and the keypad
* you can't tell that 4 and $ (or £, or whatever, depending on keyboard layout) are from the same key, just with different modifiers
* you can't detect modifier key presses in isolation
* although you can use glutWarpPointer to implement mouse look on most platforms, it doesn't work without making an additional mac-specific call on Mac OS X
* glutLeaveGameMode doesn't work on Mac OS X
* there's no way to get a list of supported video resolutions

I'm just not making any headway anywhere! :(

[>] Brian

[OneSadCookie]

SDL is crap in some ways, but in others it's perfectly good enough.

If you're not using SDL, you'll be writing your own...

[unknown]

Isnt RubyGameShell and the RBuild stuff cross platform?

[ggadwa]

SDL is crap in some ways, but in others it's perfectly good enough.

If you're not using SDL, you'll be writing your own...

Can I use SDL, but also create my own contexts? As far as I can tell, in SDL I can only have a single OpenGL context; this won't work for dim3, but is only used for a couple effects (notably, shadows.) I could always wall off that part with some ifdefs, so they only work in the mac version, and wait for additional support in the future.

[>] Brian

[OneSadCookie]

RubyGameCommon uses GLUT and GameShell isn't (yet) portable.

I don't see why you need multiple contexts, brian -- use EXT_framebuffer_object where available and fall back to CopyTexSubImage2D where not...

GLUT doesn't allow you to create off-screen contexts, either, so it's no better in this regard.

As I've said before, you could also use the SDL 1.3 betas, which include pbuffer support, or write small amounts of platform-specific code to create pbuffers, whilst still using the mainstream SDL.

[ggadwa]

I don't see why you need multiple contexts, brian -- use EXT_framebuffer_object where available and fall back to CopyTexSubImage2D where not...

I don't think framebuffer_object is available anywhere, and the CopyTexSubImage2D is slower by far, and I'd still need another context for it.

Frankly, I hate multiple paths :)

I'm expirementing with other ways to do the effects, I might be able to remove the need for multiple contexts all together, but I don't have a great deal of hope for that.

[>] Brian

[OneSadCookie]

EXT_framebuffer_object is already available on Windows and Linux, and is in development for the Mac. CopyTexSubImage2D certainly is slower, but it shouldn't be that much slower.

The whole point of both approaches is that you don't need a second context; why would you?

[ggadwa]

EXT_framebuffer_object is already available on Windows and Linux, and is in development for the Mac. CopyTexSubImage2D certainly is slower, but it shouldn't be that much slower.

The whole point of both approaches is that you don't need a second context; why would you?

This is something I'm drawing with OpenGL itself, which is why I need another context. A couple of them, in fact, to work around syncronization problems.

[>] Brian

[ggadwa]

I have an idea ... everybody cross your fingers.

I'll move everything around so I can do all the texture rendering before I do the scene, using the regular OpenGL context for rendering (instead of a separate context during the regular render); this is going to make some additional oddities with sizing, but in this way, I can have my cake and eat it, too ...

Of course, it could just be a bad idea ...

[>] Brian

[Zekaric]

Have you considered wxWidgets. If all you need is a context or multiple contexts on various platforms then getting a small layer in wxWidget to do this may be simple enough.

[ccccc]

whatever you do, make it possible to put dim3 games on windows, i hate windows but my freinds have it, and their depending on me to give them my game.

[OneSadCookie]

If you want it on Windows, find a knowledgeable Windows programmer to do the port. It shouldn't take them more than a day or two now that Linux is working.

[ggadwa]

If you want it on Windows, find a knowledgeable Windows programmer to do the port. It shouldn't take them more than a day or two now that Linux is working.

This message came back from the dead! Keith is exactly right -- all it will take is somebody to port it and all the big issues should already be conquered.

[>] Brian

[ravuya]

10.4.4 added the FBO extension to my NVidia card.

[OneSadCookie]

actually, 10.4.3 did :p