Jump to content
  • Advertisement
Sign in to follow this  
FlamingBow

OpenGL Good idea to use opengl and sdl together?

This topic is 4116 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I was just wondering whether it would be ok to use opengl and sdl together. Also, how well do they work together? Am I better off using glut instead? And if I do use opengl and sdl, do I learn the entire sdl api, or just the graphics part of it? I am going to go to college in a few years, and I am going to get a programming degree and probably get a job as a game programmer, so that should kind of help you decide whether the choice is good or not =)

Share this post


Link to post
Share on other sites
Advertisement
Well, I use SDL and OpenGL and they work great together. SDL covers the window-creation aspects and OpenGL the drawing. Works for both 2D and 3D applications.

It's common and it works nicely, anymore questions? :)

Share this post


Link to post
Share on other sites
SDL is great since it sets up the window for you, can handle device input, sound, 2D drawing, timers, its also quite standard and very portable. I use it with OpenGL.

Share this post


Link to post
Share on other sites
One small addition/correction to the above post:

Quote:
Original post by NerdInHisShoe
SDL is great since it sets up [...] 2D drawing [...]


If you use OpenGL and SDL and want to program a fast-running game in 2D with more than a 'few' images on the screen (say a game with tiles or particles for example), then it is in fact very smart to still keep on using OpenGL for the drawing. 'Even' in 2D, it's way faster than SDL.

So, basically, let SDL handle all it can EXCEPT the drawing, which should be completely OpenGL's task.

Share this post


Link to post
Share on other sites
Quote:
Original post by d h k
One small addition/correction to the above post:

Quote:
Original post by NerdInHisShoe
SDL is great since it sets up [...] 2D drawing [...]


If you use OpenGL and SDL and want to program a fast-running game in 2D with more than a 'few' images on the screen (say a game with tiles or particles for example), then it is in fact very smart to still keep on using OpenGL for the drawing. 'Even' in 2D, it's way faster than SDL.

So, basically, let SDL handle all it can EXCEPT the drawing, which should be completely OpenGL's task.


That's true if the system has a 3D accelerator and a driver/module to take advantage of it. I can think of a lot of systems that don't have at least one of them:


  • a lot of handled devices (PocketPC, cellphones, etc),

  • the average desktop system used by employees all over the world (heck, some of them are still running Windows 9x),

  • many GNU/Linux systems, if their card isn't supported by DRI and their user doesn't want to use a proprietary kernel module,

  • FreeBSD: see above,

  • Net/OpenBSD: I don't think users of these systems get a choice at all (it's DRI or nothing),

  • many "exoctic" ports of SDL (PS/2, Genesis, ...),

  • maybe more.



I'm not saying you should back off and forget about OpenGL, but if your target audience is likely to be using one of the aforementioned systems (eg casual gamers and average desktop systems), then you'll want to be careful. I know of at least one casual game team that ditched OpenGL in favour of AGG because some of their customers had issues with OpenGL drivers.

Again, I'm not saying "screw OpenGL", I'm saying "know your audience".

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!