Hey everyone,
I'm writing my code in Windows 7 with VS 2008. My game project is a simple 2D tile base Rpg. I'll be using OpenGL for the graphics. My question to anyone here is should I use the Windows API (WinMain and WndProc) for creating a fullscreen window, or is it better to use something like SFML or SDL.
Is there a performance hit for using libraries like SDL or SFML ?
Thanks for any advice here...
Michael
Best way to setup OpenGL
If you are only ever planning on making the game work with windows, then I say use windows API. But if you are planning on cross platforming someday, even if it's the slightest thought, I would use SDL.
SDL has a lot of nice features for you to use, texture loading, music, sound, user input, threading, networking. And its free, and simple to learn...
I use SDL, OpenGL for my games.
Performance no difference between the two.
SDL has a lot of nice features for you to use, texture loading, music, sound, user input, threading, networking. And its free, and simple to learn...
I use SDL, OpenGL for my games.
Performance no difference between the two.
I Would also recommend SDL for almost the same reasons MARS_999.
There is also GLFW for a more OpenGL specific approach but I find it easier to use SDL on Mac OS X so therefore I use SDL.
There is also GLFW for a more OpenGL specific approach but I find it easier to use SDL on Mac OS X so therefore I use SDL.
SDL, by far. Not only you can use it with OpenGL, but also you get other stuff, like things related to user input and such.
Quote:Original post by MARS_999I would recommend either of glfw-lite or SFML over SDL.
SDL has a lot of nice features for you to use, texture loading, music, sound, user input, threading, networking. And its free, and simple to learn...
Unless you are willing to live on the bleeding edge and use the alpha 1.3 branch of SDL, you will find SDL to be outdated and missing features (OpenGL 3 support, for instance).
Aside from cross-platform support (which you may not even need or want, so it might be totally irrelevant) one thing that something like SDL will give you is that it will handle a lot of the platform-specific heavy lifting for you. Being able to say "gimme a window that supports OpenGL" is just so much more easier on you than having to mess around with the OS-specific stuff (do you need CS_OWNDC? how should you handle WM_PAINT? etc.)
Balance this against the requirement for your end users to have the SDL DLLs (for example) on their machines, however. And also be aware of any interoperability issues that there may be between your chosen framework and Windows 7/VS 2008. At the very least I would say that you should write a small test app just to ensure that things work as expected, and that you're comfortable with how they work, before committing to anything major.
Balance this against the requirement for your end users to have the SDL DLLs (for example) on their machines, however. And also be aware of any interoperability issues that there may be between your chosen framework and Windows 7/VS 2008. At the very least I would say that you should write a small test app just to ensure that things work as expected, and that you're comfortable with how they work, before committing to anything major.
Don't use SDL. I can quote various instances of unoptimized code there (especially the threading subsystem).
Write dual WGL and GLX initialization if you need this to work on both Windows and Linux. It's not that much code, and you have a leaner project with less dependencies on others' update schedules and such.
Write dual WGL and GLX initialization if you need this to work on both Windows and Linux. It's not that much code, and you have a leaner project with less dependencies on others' update schedules and such.
Quote:Don't use SDL. I can quote various instances of unoptimized code there (especially the threading subsystem).I think I remember you mentioning this in the past. Is what you're referring to an issue even if multiple threads aren't used explicitly? I'm not doubting you, but with SDL (1.2.x, that is) used so widely and in so many projects, it seems like we'd hear more about it if the library suffered from fundamental performance problems. (Anyway, just curious. I've never encountered any particular performance problems that I could trace back to SDL, but maybe there's stuff going on 'under the hood' that I'm not aware of.)
As for which library to use, SFML seems good, although last I read the OS X version wasn't being actively developed.
After that I would probably recommend SDL 1.2.x (although I haven't tried some of the other similar libraries, such as GLFW, myself).
[Edited by - jyk on July 11, 2010 6:36:31 PM]
pthreads can be used on Windows and pretty much all Unixes, and it's well optimized.
For sound, OpenAL (with libavcodec for decoding) is the way to go, or FMOD if you're OK with the non-free licensing.
SDL is most useful for input handling, but it's too big to be used just for that. And a Windows message loop is not complicated stuff...
For sound, OpenAL (with libavcodec for decoding) is the way to go, or FMOD if you're OK with the non-free licensing.
SDL is most useful for input handling, but it's too big to be used just for that. And a Windows message loop is not complicated stuff...
I want to point out that using existing libraries allows you to be enhanced by those libraries, but at the same time limited by them.
If you are going to support Macintosh it makes sense to also support iPhone/iPod/iPad. This requires just a small port of your OpenGL code, and suddenly the value of your engine/game increases because you support more platforms.
The Nintendo Wii API is also very similar to OpenGL. Very easy to port from OpenGL to Nintendo Wii, and with that little work once again your product has gained tons of value.
But you can’t do that if you use SDL/SFML/etc.
On the other hand, rolling your own OpenGL engine takes effort.
If you notice a trend between my points, it is portability.
That is OpenGL’s main selling point. In other words, if you are not even remotely considering porting your product, you probably don’t need OpenGL at all. If you are sticking to Windows, you would be better off using DirectX, frankly, and then an Xbox 360 port of your game is free.
My conclusion (and the only part you NEED to read) is that you are just making a small game, probably as a hobby. Not such a serious product.
You should definitely roll your own (regardless of DirectX or OpenGL).
Because it is so simple, it is a good chance for you to do things manually. It will not overwhelm you, but it will give you very valuable experience.
All successful programmers have one (or more) thing(s) in common: The drive to figure things out for themselves/do things manually for the sake of learning how it works.
Just imagine two programmers who started programming on the same day in the same room.
* Programmer A: He used external libraries somewhat, but mostly rolled his own. He spent a bit more time on each project, but really understood how it was all coming together in detail and was free to explore multiple platforms, etc., without any problems. 5 years later he can make his own commercial-quality game engine from scratch.
* Programmer B: Was more interested in the results. Once he learned a library it was easy to get good results fast, and since that satisfied him he did not branch out too much. Naturally everyone gains experience over time, and after 5 years he has a decent understanding of how a whole game engine works, but can’t make his own from scratch (just parts of it), and has trouble working on other platforms.
Programmer A is the one who works as a CTO for some major game company, pulling in the big bucks and making his parents proud, writing books, speaking at game conferences, etc.
Naturally Programmer B dies cold and lonely under a bridge, abandoned by his parents and dog. I mean obviously.
L. Spiro
If you are going to support Macintosh it makes sense to also support iPhone/iPod/iPad. This requires just a small port of your OpenGL code, and suddenly the value of your engine/game increases because you support more platforms.
The Nintendo Wii API is also very similar to OpenGL. Very easy to port from OpenGL to Nintendo Wii, and with that little work once again your product has gained tons of value.
But you can’t do that if you use SDL/SFML/etc.
On the other hand, rolling your own OpenGL engine takes effort.
If you notice a trend between my points, it is portability.
That is OpenGL’s main selling point. In other words, if you are not even remotely considering porting your product, you probably don’t need OpenGL at all. If you are sticking to Windows, you would be better off using DirectX, frankly, and then an Xbox 360 port of your game is free.
My conclusion (and the only part you NEED to read) is that you are just making a small game, probably as a hobby. Not such a serious product.
You should definitely roll your own (regardless of DirectX or OpenGL).
Because it is so simple, it is a good chance for you to do things manually. It will not overwhelm you, but it will give you very valuable experience.
All successful programmers have one (or more) thing(s) in common: The drive to figure things out for themselves/do things manually for the sake of learning how it works.
Just imagine two programmers who started programming on the same day in the same room.
* Programmer A: He used external libraries somewhat, but mostly rolled his own. He spent a bit more time on each project, but really understood how it was all coming together in detail and was free to explore multiple platforms, etc., without any problems. 5 years later he can make his own commercial-quality game engine from scratch.
* Programmer B: Was more interested in the results. Once he learned a library it was easy to get good results fast, and since that satisfied him he did not branch out too much. Naturally everyone gains experience over time, and after 5 years he has a decent understanding of how a whole game engine works, but can’t make his own from scratch (just parts of it), and has trouble working on other platforms.
Programmer A is the one who works as a CTO for some major game company, pulling in the big bucks and making his parents proud, writing books, speaking at game conferences, etc.
Naturally Programmer B dies cold and lonely under a bridge, abandoned by his parents and dog. I mean obviously.
L. Spiro
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement