Elysian Shadows

I have learned a little bit of Allegro, created a simple game, was struggling with tile maps recently, however failed, so started improving my C++ skills, since i knew basically the basics well, but not the little bit advanced stuff.

Anyway, i was looking for something on the internet, and i ran into some game's, i guess open source, programming discussion. Someone recently has advised the guy, who is programming the game, to switch to SDL from Allegro. He claimed, that Allegro was good in DOS times, little weaker PCs and stuff like that, as SDL is more modern language, have more C++ support, instead of C. So i've googled again, found many threads, which are outdated a lot, in some threads there were suggestions, that SFML is even better than both of these libraries - it's more modern and it has even more C++ support, instead of C. As Allegro is plain C, SDL is half C and half C++, and that last one - SFML is plain C++. So it sounded pretty tempting to me.

Anyway, here is what i know and who i am:
I know C++'s basics well, now learning the little advanced stuff of C++, like classes and structures and stuff like that,

What i intend to make:
Currently a lot of 2D games, for about half a year to a year. Like platformers, maybe some not very advanced rpg at the end. Games are not going to be cross-platformed, most likely. After that, i think, that i will be able to take on a 3D game, maybe i will make some friends to work with over that time too, since a 3D game, for my current knowledge of programming process, takes a lot of time. Especially for a single person.

What i have made already:
I have made a few console games in plain C++, when i was learning the basics, Ping Pong in Allegro, Some other game with no name even, just to learn the tile maps, haven't finished completely, as i failed to make the collision detection.
I have also made a few programs, but those are simple C++ basic programs, not very useful for Windows user.

Criteria to the library i am going to take:
Since i am a noobie still, i would like the one, which is not VERY advanced. I mean to learn it, and to be able to understand it. Also i would like to take some, to receive support on questions about it. And it should support 2D games pretty good. I don't care much about resource usage, as i doubt many people around here have Pentium 2 computers. Also, i intend to use Windows 7 for myself.

If you need more information on what i know, what i need or what i would like to do, please ask.

Links:
http://www.sfml-dev.org/
http://www.allegro.cc/
http://www.libsdl.org/

My 2 cents

• In my opinion and from things i've learned, and overall factors Allegro < SDL < SFML
• Allegro cannot work with OpenGL for your future 3D stuff, but the other two can.
• There's nothing wrong with trying them all out, to see what you would personally prefer. e.g.
  • some people prefer SDL's C style
  • others prefer SFML's C++ object oriented style
  • people I've heard like Allegro just for "learning the ropes", like how to make 2D tile based games and such

Basically it's SDL vs. SFML. I use SDL because that's how I started out but from what I've heard, SFML is better in many aspects. SFML is more OO and it has better hardware acceleration than SDL. I'm not sure about the specifics but I *think* SDL has almost no hardware acceleration while SFML is almost entirely hardware accelerated. If I was just starting, using solely the 2D API, no OpenGL, I would probably learn SFML.

I've only been using SFML for a little while, but from what I've seen so far, it lets you get things going with just the basics of what you need or get very involved in specifying what you want it to do.

For example, you can create a sprite and set its position in a line or two, but you can also specify its clipping subrect, its center and rotation, its scale, and its color mask. It also has text-handling built in and supports a variety of different filetypes for audio and graphics. In short, it does what you need it to but it can also do what you want it to; rather easily.

The website's tutorials are very helpful. Keep in mind that you'll be running into classes and namespaces, and the little quirks that go with them. They're easy to deal with once you figure them out, but they'll annoy the hell out of you in the meantime.

OK, Allegro < SDL <= SFML. SDL is greatly inferior to SFML if you intend to use it for graphics, but if you are using OpenGL with them, they're about equal. Personally, I would use SDL with openGL because the blitting allows me to pack textures together when I load them, and SFML has no such functionality.

Seems, that SFML is the best too around. Thanks for answers, i am going to take off Allegro, skip SDL and take SFML, after i finish learning those classes. Actually haven't even started on classes yet, found some other concepts of C++, that are more basic and in my opinion needs to be learned, while was searching for classes tutorials. Hope i'll get what those things are, hehe.

P.S. are pointers often used for game development? Especially talking about 2D games. Overlooked the tutorial, seems it needs much more investigation, and i couldn't think of a possible good reason to learn them, where to use them... So it seems to me, that it's quite unnecessary thing to learn, they are...

Learn them!

one of the main reasons you would use pointers pointers when building a game include:

- dynamic allocation (i.e. creating objects at runtime, trust me, you need to do this in any complicated game)
- passing objects by reference (objects can be bigger than types such as ints and bools, passing copies of some objects would bring your program to a standstill )

so yes , learn them!

And I personally use SDL, tried SFML, liked it, but felt like I was 'working around' some of its high-level features (for example, I like to define what a sprite is myself, I just felt like I was undermining SFMLs philosophy by treating it like SDL), but that doesn't mean it's bad, far from it, it just means I'm stubborn

programmerinprogress wrote:- passing objects by reference (objects can be bigger than types such as ints and bools, passing copies of some objects would bring your program to a standstill )

actually the bigger thing here is that you may not want it copied. There aren't many things where copying them would slow down your program very significantly, but (for example), you wouldn't want your whole Engine being copied when you want things to be able to use it.

Ginto8 wrote:

programmerinprogress wrote:- passing objects by reference (objects can be bigger than types such as ints and bools, passing copies of some objects would bring your program to a standstill )

actually the bigger thing here is that you may not want it copied. There aren't many things where copying them would slow down your program very significantly, but (for example), you wouldn't want your whole Engine being copied when you want things to be able to use it.

That being said, copy constructor and operator= should be private in those classes.

K-Bal wrote:

Ginto8 wrote:

programmerinprogress wrote:- passing objects by reference (objects can be bigger than types such as ints and bools, passing copies of some objects would bring your program to a standstill )

actually the bigger thing here is that you may not want it copied. There aren't many things where copying them would slow down your program very significantly, but (for example), you wouldn't want your whole Engine being copied when you want things to be able to use it.

That being said, copy constructor and operator= should be private in those classes.

actually you only need the copy constructor private, as long as you don't define an operator= publicly. The normal assignment operation for structs/classes relies on the copy constructor, so unless you customly define your own operator=, you only need a private copy constructor.

Lol, seems i understand almost nothing from the few past topics.

cppgames wrote:Lol, seems i understand almost nothing from the few past topics.

In short, copy constructors are used to copy objects. If a CC is private, you can't just copy the class.

cppgames wrote:Lol, seems i understand almost nothing from the few past topics.

http://www.cplusplus.com/doc/tutorial/classes/ Reading that should give you a pretty good understanding.

Seems, like i get something... Mostly pointers are used to use the code more efficiantly, make the program work faster and shorten the code, also make the code simplier to read. That's how i understand pointers at 4am.

Thanks for explainin!

Pointers are useful when something is optional or when something has the chance to not exist. You could have an optional function parameter or a class that contains an optional object. You could have a function return a pointer instead of a reference when there's a chance something could go wrong in the function and the expected reference could not be returned (You would return 0/NULL).