SDL or SFML for my first game?
Author
Hi, I'm a beginner, and I'm about to start my first game. I have some C++ knowledge (not real experience, but have read a couple books, and plan to read Effective C++ in the near future). I'm a 3rd year Computer Science student, so I also know OOP basics and some design patterns.
I want to make a racing game like MicroMachines (top-view) with guns (aiming with the mouse, like in Soldat). I know it's not a pacman or breakout, but I will go step by step, learning in the process. I don't want it to be a full game (with a story and everything), just something nice to play to have in my portfolio. It will be singleplayer (I'm not interested in network programming, but I am in AI).
Now here is my doubt. I was sure I was going to use SDL, mainly because there are lots of good tutorials out there. But I found out that SDL does not support rotation (it does with SDL_gfx, which I read is very slow), and that is quite important giving the kind of game I'll be doing. Many people use OpenGL for rendering, but I don't want to mess with it.
I read here that some people recommends SFML, which is like a modern version of SDL (more object oriented, which is a plus). But I haven't found any tutorials besides the one in the official site, and that's why I doubt.. I know I will need a lot of help :P
I don't want to make an engine, but I want to have a good code base to reuse in future games.
What do you think I should use? SDL? SFML? a free 2D engine?
thanks!
from Argentina
Leandro
Quote:Original post by Master-BlasterBut I found out that SDL does not support rotation (it does with SDL_gfx, which I read is very slow), and that is quite important giving the kind of game I'll be doing.
It's generally not common practice to actually rotate sprites anyway, unless you are using hardware to do so via OpenGL or D3D. Most 2D games use different sprite frames to handle the rotation of a sprite, so rotations are played out just like any other 2D sprite animation.
That said, I'd probably go with SFML myself. I'd never heard of it until this post, but it looks like it's a nice little package. These days, I think it's rather pointless to make 2D games that don't take advantage of hardware acceleration. You can get so many effects cheaply that way. SFML appears to use OpenGL under the hood. Most 2D game engines released in the past few years do so. Even on cell phones, OpenVG provides access to hardware-accelerated 2D graphics.
SFML seems nice and is implemented with hardware acceleration through OpenGL, so I think that would be your best bet. They seem to have an active forum, so the lack of tutorials should not be an issue. You may want to check whether their documentation is up to snuff, however.
If you are unsure of what to choose, I'd simply recommend that you encapsulate objects properly and separate the graphics-related code from game logic code. That way, it'll be relatively easy to change graphics libraries if you hit a roadblock with the one you've chosen.
If you are unsure of what to choose, I'd simply recommend that you encapsulate objects properly and separate the graphics-related code from game logic code. That way, it'll be relatively easy to change graphics libraries if you hit a roadblock with the one you've chosen.
I have used SDL before for games in C++, but I don't know much about SFML so I had to check its website out. It looks pretty interesting, and I notice it's got a Python binding too which is useful for me (I'm still debating which library to use for learning Python).
If you're working on a non-throwaway demo, then I recommend designing your program so it doesn't really matter which library you pick. Separate all the game logic away from the stuff that needs to interact with the system through the library. That way if you find you really hate a library it is fairly easy to swap it with another one.
As for the choice of library; it probably doesn't matter too much as long as you can learn how to use it (i.e., there's enough documentation for it to be useable). The tricky part is usually the initialisation, and that's the sort of thing that once you get it working you don't have to touch it again. You could try going a bunch of simple demos with both and see which you prefer. See how easy it is to get a sprite bouncing around the screen.
I haven't checked SFML's feature list extensively, but the only big differences I can think of are:
If you're working on a non-throwaway demo, then I recommend designing your program so it doesn't really matter which library you pick. Separate all the game logic away from the stuff that needs to interact with the system through the library. That way if you find you really hate a library it is fairly easy to swap it with another one.
As for the choice of library; it probably doesn't matter too much as long as you can learn how to use it (i.e., there's enough documentation for it to be useable). The tricky part is usually the initialisation, and that's the sort of thing that once you get it working you don't have to touch it again. You could try going a bunch of simple demos with both and see which you prefer. See how easy it is to get a sprite bouncing around the screen.
I haven't checked SFML's feature list extensively, but the only big differences I can think of are:
- SDL is more established, so there's probably more tutorials out there and more people who've used it to help you. But then again, once you get it working it's not the sort of thing that'll be a big issue.
- SFML looks newer, so it might not be quite as rugged. I notice it's not quite boasting the same sort of Mac support as for Windows and Linux, although they're working on it.
- But on the other hand, SDL has been around for ages so I don't know how often its updating now. SDL version 1.2 seems have been out for ages, and I'm not sure when it's going to 1.3.
- SDL is licensed under LGPL, while SFML is under the zlib/png license which is less restrictive on you. This probably isn't that much of an issue for your game unless you want to tinker around in their source code or statically link.
Quote:Original post by Master-BlasterI was going to use SDL, mainly because there are lots of good tutorials out there. But I found out that SDL does not support rotation (it does with SDL_gfx, which I read is very slow)
Well, SDL in general is slow. It's a software solution that doesn't make use of any hardware--possibly one of the things that make it SIMPLE.
Haven't heard of the other one you mentioned, but it doesn't sound bad.
As for your game idea...
I'm very much on the start small boat, but I don't think a beginner should make a cliche (I didn't). I recommend a one screen game, sprite based, simple physics, simple rules. Making my game (which fell under these rules, but it was merely a lucky coincidence) took about a month. I regard it as the worst month of my life, but it was fun. You have more experience than I do, so you'll probably do it more correct and faster than I, but my point is: how long do really want to be working on this?
Author
Quote:Original post by Splinter of Chaos
how long do really want to be working on this?
as long as it takes :P
I know it will take months, maybe a year, but I have a lot to learn and this is the only way. Of course I will be doing smaller things to learn the techniques, but always thinking in aplying these knowledge on my game.
I'll give SFML a try, some of the SDL tutorials may still be useful (remember I have absolutely no experiencie in Game Programming)
I would like the opinion of someone with experiencie in SFML, but nobody seems to have used it!
There is.. here I am [wink]. But I only used SFML t get access t an OpenGL context so I didnt use the sprite functions and so on.
The main advantage in my eyes are:
- nice OOP code
- Image Loading (think it was via DevIL) included
- Sound is included as well
As I said I mainly used it for creating an OpenGL window which is really simple (even better than in SDL), and I liked the image loading functions.
There's also post processing on your rendered frame available in SFML so you can make use of OpenGL hardware accelerated shaders without need to learn OpenGL and GLSL.
Guess what: I think you should go with SFML
The main advantage in my eyes are:
- nice OOP code
- Image Loading (think it was via DevIL) included
- Sound is included as well
As I said I mainly used it for creating an OpenGL window which is really simple (even better than in SDL), and I liked the image loading functions.
There's also post processing on your rendered frame available in SFML so you can make use of OpenGL hardware accelerated shaders without need to learn OpenGL and GLSL.
Guess what: I think you should go with SFML
Another good way to start is to use HGE http://hge.relishgames.com/ . Very easy to use some tutorials and a good community.
Quote:Original post by CasteThat's been replaced with SOIL (if I recall correctly) in order to reduce external dependencies, although the change doesn't really effect usage of the library.
- Image Loading (think it was via DevIL) included
I'd give SFML a shot, it's gaining in popularity, and although there aren't anywhere near the amount of resources available it has a forum which is starting to get more active and a growing userbase who will be able to offer some help.
I'm no authority by any means but the way I see it is there are 3 options.
SDL - a little old and clunky, but proven and has been around the longest;
GLFW - slim line, less code than SDL, fairly flexible;
SFML - less coding required, comes with sound, graphics and network capabilities, but do these tie you down?;
I have already written a game in SDL and I cannot complain about it as it provided everything I was looking for and I just plugged in any additional 3rd party libs I required, e.g. for image loading/manipulation: freeimage, sound: OpenAL, etc...
I'm now migrating over to GLFW as there seems to be more resources out there than there are for SFML, there's less plumbing than is required for SDL and I prefer to choose my own libs as previously mentioned.
It's really up to yourself, if you don't mind the libs that using SFML ties you into then go for it. I've not had any experience with it so I'm unsure how easy it is to opt-out of using the provided libs. Also, what if you don't want network functionality - does SFML allow you to remove it so you can cut down your distro package size? The roadmap seems to suggest that SFML is still a little immature for a 1.3 version number IMO.
SDL - a little old and clunky, but proven and has been around the longest;
GLFW - slim line, less code than SDL, fairly flexible;
SFML - less coding required, comes with sound, graphics and network capabilities, but do these tie you down?;
I have already written a game in SDL and I cannot complain about it as it provided everything I was looking for and I just plugged in any additional 3rd party libs I required, e.g. for image loading/manipulation: freeimage, sound: OpenAL, etc...
I'm now migrating over to GLFW as there seems to be more resources out there than there are for SFML, there's less plumbing than is required for SDL and I prefer to choose my own libs as previously mentioned.
It's really up to yourself, if you don't mind the libs that using SFML ties you into then go for it. I've not had any experience with it so I'm unsure how easy it is to opt-out of using the provided libs. Also, what if you don't want network functionality - does SFML allow you to remove it so you can cut down your distro package size? The roadmap seems to suggest that SFML is still a little immature for a 1.3 version number IMO.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
