# Cross-platform, free (for commercial use) C/C++ 2d game library or rendering engine? [closed]

I need a C/C++ engine that should be really cross platform (or at least windows, android, and iphone).

The 2d engine should be written in C or (better) C++, should permit the rendering of animated sprites, permit transparency, collisions (but I can integrate box2d for that), rotations (eventually with opengl support to accelerate things), handle tile-based games. If it could be a game engine (with support for events/actions, scripting and generally have the features needed when developing a 2D game) it would be fantastic.

There are a lot of open source free 2d engine out there, but soon or later you find that:

1. the documentation is not so good and/or the tutorials are not so good (or there are no tutorial at all), the examples are missing (or are too few or are missing)
2. the community is too small and not so supportive
3. the engine doesn't abstract system things enough. That is bad, because you soon find out that there is support for X and Y but not Z. With abstraction, you can use even Z adding system specific code
4. the engine is a game engine but does not have an associated editor. scripting is good, but an editor would save a lot of time I think
5. the engine writers have spent too much time to develop a complex (that will probably fails) compilation tools.

It would be useful to have something that:

#define WIN_PLATFORM
#define IOS_PLATFORM
#define ANDROID_PLATFORM
#define UNKNOWN_PLATFORM


In that way, using an empty implementation of the relevant interfaces, you can simply code what you need

6 . You come to the conclusion that usually there is not a sufficient conceptual separation from what really needs to be abstracted and what can be supposed to be found on almost all systems (e.g. opengl).

Ok. The question is, regarding a free, open source 2D rendering engine or a 2D rendering engine+2D game engine for at least iOS and Android: in your experience, what would be a good/wise choice?

## closed as off-topic by MichaelHouse♦May 12 '14 at 19:07

This question appears to be off-topic. The users who voted to close gave this specific reason:

• "Questions about "how to get started," "what to learn next," or "which technology to use" are discussion-oriented questions which involve answers that are either based on opinion, or which are all equally valid. Those kinds of questions are outside the scope of this site. Visit our help center for more information." – MichaelHouse
If this question can be reworded to fit the rules in the help center, please edit the question.

• I made the same observation as you, and decided to write my own minimalist framework. It is obviously bound to fail point 2, however it allows me to support DirectX and the PS3 in addition to the platforms you mention, which only a professional grade engine will give you. Anyway, how strong is the opensource requirement? Because engines such as UDK or Unity will give you most of what you need except the free as in source. – sam hocevar Nov 4 '11 at 16:56
• This is C# (why is C++ a requirement for you?) and is kind of shameless self-promotion - so I won't make this an answer, but consider ExEn. It has the functionality and platform support you want. It costs money to distribute (due to MonoTouch/Mono for Android) but can be tried for free on the simulator. – Andrew Russell Nov 4 '11 at 17:42
• Another C#/Mono-flavored suggestion: MonoGame 2.0, an open-source implementation of XNA, has recently been announced. It might be worth checking out. – chaosTechnician Nov 4 '11 at 20:59

SDL is probably the most popular and known for producing AAA-quality titles. Allegro is the oldest (first built for Atari ST I believe) and has seen a huge amount of use. It's fast and efficient 2D, like SDL. SFML is a much newer contender and, as I understand, assumes OpenGL support. However both SDL and Allegro support OpenGL seamlessly in their most recent versions.

Allegro and SDL are written in C, and plot pixels about as fast as a software renderer could be expected to (which is pretty damn fast on today's systems). SFML is C++.

Documentation is decent for all of these, but with SDL and Allegro you may sometimes be slightly confused by articles online that are out of date. The official docs are current, however.

As for editors, well, you may have to pay for something like Torque2D if that's what you really need. I haven't heard the greatest things about that library's in terms of stability, though. Else go for Java / jME, or C# / Unity.

• ...none of these are engines though. – Maximus Minimus Nov 4 '11 at 19:51
• None of what the OP asks for is engine-related, outside of the question title, which I have now changed. He asks for features to be permitted by the underlying mechanism (read: library), not for them to be implemented. OP: "If it could be a game engine... that would be fantastic." – Engineer Nov 4 '11 at 20:15
• +1 I think the OP confuses 2d libraries with full engines, and I think it's nice to show him these options. – Diego Nov 5 '11 at 12:49

but soon or later you find that:

You're not going to find anything that user-friendly in the open-source world. Not full-fledged game engines.

If you don't want to spend money on an engine, then you're going to have to accept one immutable law: you get what you pay for. Let's go through your points:

1. People who don't get paid have little incentive to write documentation, unless they're particularly anal about it. Remember: free programmers get into a project to code, not to document.

2. There are a lot of tools out there. Some are going to be more popular than others.

3. Each engine is designed for a specific purpose. You can't make everything abstract, because then everything is abstract and nothing is defined. You'd have a library that does nothing. Every engine must decide what it is going to make easy to do and what it isn't. The kind of games that the engine is made for fall in the former category, and the kind of games that it isn't made for fall in the latter.

This is true regardless of whether the engine is free or not.

4. Pretty much the same as #1. If you're making an engine, you're not making a game. And people who are interested in making engines aren't necessarily interested in going through the other 80% of the work necessary to make a game. Part of that work is a good suite of tools.

Also, editors are very closely tied into the kinds of games they make. It's hard to "abstract" an editor. So if you have a general-purpose engine, it's going to be hard to create an editor for it that doesn't in some way limit what the user can do. Editors also require a lot more planning than many open-source projects get.

5. I've generally never seen this. Usually, the build process will be CMake, some form of Autoconfig stuff, or just straight-up Makefiles. If they do use a more complex build system, it is only because they want to give the user the ability to configure the software as they wish. SFML and Allegro allow you to pick-and-choose different tools to work with.

Ultimately, there are plenty of C/C++ tools out there which you can pull together into a game engine. But there is no one-stop-shop for them. There is no one engine that ties them all together in a nice, well-documented package. Which is why serious indie game developers either pick tools they like using and build what they need, or just buy something off-the-shelf.

• While you are making very good points, I feel the need to state that Ogre3D is really close to a full-fledged game engine. – sam hocevar Nov 4 '11 at 20:22
• and for this specific question: I'm working with cocos2d-x for a while now, I think you can count it as a complete 2d gameengine. and for the documentation, it may not contain anything on it's own but it's a complete port of cocos2d-iphone, which has many documentations and even there are books out there about it. cocos2d engine group also rely on some other opensource softwares to provide some GUI for level editing and other non-code issues, like tiled editor or zwoptex. – Ali1S232 Nov 4 '11 at 20:40
• @SamHocevar: How? It has no physics support. No entity support. No AI support. No sound support. No input support. It's a graphics rendering library. A good one certainly, but games are a lot more than drawing a picture. – Nicol Bolas Nov 4 '11 at 20:57
• @Nicol: agreed for AI support, it's lacking and I don't see it coming any soon. But Ogre3D has physics support through OgreODE, entity support through various classes such as MovableObject, sound support through OgreAL, input support through OIS... it's truly not only a graphics rendering library. – sam hocevar Nov 4 '11 at 21:09
• Well that's how an opensource ecosystem looks like. I don't think it's that bad, what's important is the availability, not the source. (Also, OIS has been part of Ogre3D since 1.4.5). I don't mean to constantly argue with you, I just want to mitigate your claim of unavailability; it's far from perfect but it's out there and might suit some needs. – sam hocevar Nov 4 '11 at 21:24

There is a gameengine named cocos2d-x. it's c++ port of well-known cocos2d-iphone engine. So far this engine supports iOS, Android, Windows and some other platforms (there is a complete list here). But according to it's own site windows should only be used for development and debug purposes but I think with a little modification you can release windows version of your game using this engine too.