Using OpenGL with SDL for a 2D engine targeting casual games?

Started by
22 comments, last by shadowcomplex 17 years ago
Hi everyone, While I am a bit rusty at programming, I am trying to start things up again by jotting down a list of requirements for a reworking of my 2D game system. Presently I am using SDL and OpenGL, using OpenGL to get rotation, alpha blending, hardware acceleration and so on. At present I am comfortable enough to use both to get the basics of a game system up and running, however I would not consider myself a wizard at both, especially with OpenGL which I know the minimum to get 2D textured rectangles working. I am currently strongly considering regearing my system towards supporting more casual 2D games rather than fast action scrollers. This would require me to aim for a lower base computer spec. However I am uncertain as to how sensible it is to rely on OpenGL for a casual game. While I do not expect to use any newer extensions I am unfamiliar with the capabilities of the low end graphics cards that would be commonly found in the standard home computer. Would it be still be sensible to aim for SDL and OpenGL as compulsory in my new system, or should I aim for SDL only and lose the capability for many special effects? Or is it feasible to have a system that can toggle between the two? In case it is relevant, I am using C++ with SDL and OpenGL. I have been presently coding just for Windows, but I recently bought a MacBook Pro and am looking to get into cross-platform development. If there are any other relevant alternatives that I have not considered in my question I am happy to learn about them. Thanks in advance for any advice!
Advertisement
Dude! I don't understand your problem - you got an engine right?
So what do you want to do with it? Upgrade it? Replace the OpenGL with something?
I think you should write a few games with it, or just get a new programming project...

Mikle :)
Mikle
I have most of an engine done, but I have been away from working on it for some time and need to brush up on the functionality. I want to start by cleaning up its internals - make it event driven and polish up the function interfaces. I am hoping I can reuse most of what I presently have, however I may need to rewrite the kernel to incorporate the event based focus.

However my question refers to the rendering component. I want to make my engine fit for the kinds of games I wish to make, which do not have to be that technically impressive. I only use OpenGL at the moment to allow polygon rotation, alpha blending and the occasional polygon primitive for special effects. Many of the game types I would like to make - such as the puzzle game I am presently working on, for example - could be implemented sans some effects purely in SDL. However others may benefit hugely from being able to rotate sprites efficiently.

Given simpler puzzle game are suitable for people with lower spec computers, I think it would be a good idea to focus the engine for that kind of application. However I am unsure as to the capabilities of such lower end machines and whether they would have problems with the OpenGL component.

My gut feeling is that these days even an integrated video chip should have sufficient capability in both hardware and the OpenGL drivers to render up to a thousand rotated sprites (i.e. textured quads). However given I have little knowledge of the range of hardware today I wanted to ask if my hunch is sound.

If such lower end machines cannot be relied on having a usable OpenGL for rotated alpha blended sprites, then I could design the rendering system to support SDL only. This may force me to lose the functionality of having rotated sprites and alpha blending however. There is also the question as to whether pure SDL would be fast enough on such machines if OpenGL is not.

There is also the question of technical problems - I do not know if there could be complications with relying on OpenGL that I would not have if I purely stuck with SDL - even if I am not using any of the more advanced capabilities of the hardware, purely rotation and alpha blending. Admittedly the alpha blending strikes me as a potential problem.

My question is for those people who have experience with using SDL with or without OpenGL on a range of systems whether they have any knowledge of how it fares on the lower spec systems that are common today. I am hoping that my fears are groundless and I can safely use my existing OpenGL based system for my sprite rendering without it becoming too much of a hassle to make it low-spec friendly.

Thanks!

On my old Compaq PoS* SDL would get 30 FPS where OpenGL would get 150 - 190. So on older systems you're not going to be gaining much by using SDL's software rendering.

Problem is my integrated intel GPU's OpenGL drivers sucked royally. I couldn't even get texture pixels after creating the texture.

You're not going to be able to have you engine run perfectly on all systems. Your going to have to have a minimum spec requirement. Go to your nearest place that sells used PC, pick up one for $50 and have that as your test machine for your minimum target.

*Compaq PoS has 700mhz P3, 128MB RAM, and 4MB GPU.

Learn to make games with my SDL 2 Tutorials

Why not use an existing sprite engine which does all that you're asking for, and more?
Quote:Original post by Lazy Foo
On my old Compaq PoS* SDL would get 30 FPS where OpenGL would get 150 - 190. So on older systems you're not going to be gaining much by using SDL's software rendering.

Problem is my integrated intel GPU's OpenGL drivers sucked royally. I couldn't even get texture pixels after creating the texture.

That's pretty much what I thought; on any system where OpenGL is too slow then SDL will be slow too. However the problem is the poor driver support for OpenGL on those integrated boards. I think I am only using OpenGL 1.1 functionality (except maybe I was playing around with texture clamping - that's 1.2 right? - but I can work around that), so I am hoping there will be less issue with outdated drivers. But it is still something I will need to consider.

After putting some more thought into it I think the sensible option is to assume basic 3D functionality - which should be reasonable for anything made in the last several years - but ensure that all the rendering code is completely isolated in its own module. Then once I have the OpenGL rendering version up and running it should not be too difficult to write a DirectX variant for greater Windows compatibility. Admittedly I do not know DirectX, but I am wagering it should be similar enough to OpenGL to make a conversion from existing OpenGL code fairly straightforward with a good reference source close at hand.

Quote:You're not going to be able to have you engine run perfectly on all systems. Your going to have to have a minimum spec requirement. Go to your nearest place that sells used PC, pick up one for $50 and have that as your test machine for your minimum target.

Good point - I need to snag something old to use as a test machine. I am pretty sure I have back home in storage a couple of old PCs - a Pentium and a Pentium 2, I think. They might have a few busted components but with a bit of fixing they should work fine. Might be a bit too old, though!

Quote:Original post by DarkHorizon
Why not use an existing sprite engine which does all that you're asking for, and more?

Although this may stray me off-topic it's a fair question, and one that I spent some time considering several months back. If all I was concerned with was getting a game concept up an running, then the sensible option is to use a good existing, well documented and thoroughly tested engine that satisfies your requirements.

However, while making games is important to me, I also want to derustify and sharpen my architectural design and programming skills. My thinking is that developing my own 2D engine on top of SDL and using other third party libraries for some of the more annoying grunt work (for example TinyXML) is the best way to do that; it is a complex enough task to be a moderate challenge to do right, but not so complex as to be too frustrating. It is not that hard to get 2D sprites to bounce around a screen using SDL; the fun bit is how you structure all those internals to make the whole coding process as smooth as possible.

If you are writing your programs on Windows, barring the extension system, you're restricted to OpenGL 1.1. I believe that version came out some time in the mid 90s (95?), so any machine from around that time and later shouldn't have any problems with your programs.

Personally, I would stick with using OpenGL. I'm pretty sure you won't ever have worse performance for using it, even with a mediocre graphics card. As I recall, SDL handles most of its stuff through software, where as OpenGL will nearly always be able to do at least some stuff through hardware.

Also, you won't be hurt by the extra functionality provided by OpenGL, although you certainly aren't required to use it. A bit of extra effort may be required to get things going, but you'll have a lot more functionality to work with, if you ever decide to use it.
Quote:
Trapper Zoid wrote:
In case it is relevant, I am using C++ with SDL and OpenGL. I have been presently coding just for Windows, but I recently bought a MacBook Pro and am looking to get into cross-platform development. If there are any other relevant alternatives that I have not considered in my question I am happy to learn about them.


If there is the possibility that you might run your engine on a big-endian architecture such as PowerPC Linux or an older Macintosh, be sure to make all of the binary blobs you write to files use the SDL_SwapLE32(value) or other variable sizes from SDL_endian.h so that the files will come out the same on a little-endian or big-endian system. Also remember to use SDL_SwapLE32(value) when reading the binary back in. The same goes for packets sent over a network.

-edit-
There aren't many systems that don't have OpenGL that do have SDL. The ones that ARE like that are probably working on adding OpenGL since there are so many SDL games that use it.

If you are going to make your source codes portable to multiple platforms, try getting an old PowerPC-based Mac so that you can be sure you got all of the endian-issues worked out.

[Edited by - samuraicrow on March 19, 2007 5:15:51 PM]
I'd go with OpenGL+ SDL also. As you mentioned, it allows you to do thing like blending,scaling,rotation,quads practically free. That adds up to a lot eye-candy that everyone likes and also flexibility in designing games. When done in software, these operations can add up and affect performance. Even on fast computers, you probably have to use SIMD instructions to speed things up.

The Popcap's framework uses D3D with some software fallbacks. SDL 1.3 is supposed to offer a OpenGL renderer with an option to use the DX9 renderer for Windows platforms. So I guess it would be safe to go along with the hardware-accelerated crowd:)
0xa0000000

This topic is closed to new replies.

Advertisement