next »

[Eraser]

So I've got C::B, with MingW, but I'm having trouble what library I should really start tinkering with (which ideally would consist of at minimum creating the window, handling graphics and sound, and cross platform.)

I was tinkering with SDL, but I ran across an interesting limitation: You cannot have a .png with an alpha channel, then adjust the alpha some more from within your game. Also, AFAIK SDL is limited to software rendering which is definitely not ideal. I think we're at the point where most even integrated graphics chips will support oGL.

I had a look at SFML and all seemed good except for one thing - to get the libs I want for graphics, sound, and window, it's like 16 megs of libraries. Yes I realize most people don't care too much about download size, but when I slap them with 20megs for a 5 minute game consisting of a game with 1 level and a song, it will matter. What I'm currently using is only 2-3mb of libs, plus my game executable and data.

Makes me want to go back to Java, Pascal, or GM... Anyone know of any noteworthy libs/engines for C++ that are lightweight, cross-platform, and handles window/gfx/sfx? I've been googling around without luck.

[oahda]

Object-oriented library for 2D graphics, sound, threads and networking:

SFML.

[Overkill]

Also, AFAIK SDL is limited to software rendering which is definitely not ideal. I think we're at the point where most even integrated graphics chips will support oGL.

OpenGL is definitely supported by SDL. I saw people say SDL only supports software rendering in another thread too, but it's not true. It does support an OpenGL drawing mode. Though there are a couple downsides OpenGL in SDL, mainly that any time you resize the window or adjust the resolution, it nukes your GL context. You can get around this by not allowing windows to be resized, but it's not entirely ideal.

That said, I've been considering switching my engine to SMFL. It seems interesting, and I've read a little about it.

[Eraser]

OpenGL is definitely supported by SDL. I saw people say SDL only supports software rendering in another thread too, but it's not true. It does support an OpenGL drawing mode. Though there is a couple downsides OpenGL in SDL, mainly that any time you resize the window or adjust the resolution, it nukes your GL context. You can get around this by not allowing windows to be resized, but it's not entirely ideal.

It doesn't support it directly, seems like. http://www.libsdl.org/opengl/index.php
And from that page, the links are no longer relevant to SDL, but oGL as a whole. I can't find any more info than that page.

[Overkill]

Yes, the official website isn't that helpful under that section (or really, most sections), but it is supported directly by the library. It is in their doc wiki about SDL 1.2 (look at the API under the Video section): http://www.libsdl.org/cgi/docwiki.cgi/SDL_API

Also, I just googled "SDL OpenGL" and found this: http://gpwiki.org/index.php/SDL:Tutorials:Using_SDL_with_OpenGL

The thing is SDL (or any library, really) doesn't need to provide much. You make a call to setup the video mode with SDL_GL_SetAttribute and then SDL_SetVideoMode (with SDL_OPENGL set), then you use regular GL calls after that. When you want to refresh the screen, you call SDL_GL_SwapBuffers.

[oahda]

I have no idea about older versions, but in SDL 1.3 you just create an OpenGL context. It's really easy.

[Chris Whitman]

Yeah, even in the stable release (1.2, I think?) it's a piece of cake. Pretty much just as Overkill described.

Edit: and it will pretty much run with hardware rendering by default.

Buuuuut, in general I'd look for something higher level than OpenGL/SDL, if you can swing it. I used that pairing for my current project and spent a lot of time reinventing wheels. There seem to be a plethora of other API options to get up and running faster (unless you're doing this strictly for educational purposes).