Temple of The Roguelike Forums
Development => Programming => Topic started by: miki151 on July 24, 2013, 12:25:17 PM
-
I've used Allegro for many games, because it was simple and had low hardware requirements. When making my recent game, I started with Allegro 4.x, but had to switch to Allegro 5 due to better unicode font support. But now trouble has started, on some Windows PCs the game runs really slow, due to problems with hardware acceleration and/or D3d, and doesn't start at all on a Windows 7 on Vmware. Furthermore, there are performance issues, as some drawing primitives are much slower than in Allegro 4.
Does anyone have any recommendations on a simple library that doesn't get in the way too much? All I need are drawing primitives, bitmap and truetype fonts support, and portability between Linux and Windows. I know many people use libtcod, but I think it's too constraining for my needs, as I'd like to be able to draw anything I want on the screen, as opposed to using a pre-made console. But maybe I'm wrong about it. And I don't know how well it runs on older computers.
-
You can try SFML or SDL, but what I'd really recommend is to make a harder drill into Allegro 5. Or at least do not expect that with another library everything will be smooth. Sometimes it is, but causes more trouble elsewhere. Every library has its dark side. The sooner you get used to it and learn how to solve common problems, the better. It's worth to note that some problems (including performance degradation!) are very similar with every library.
-
I use Allegro 4 and Alleggl. The Alleggl gives accelerated drawing via OpenGL, and I find the combination very easy to use although it does require familiarity with OpenGL itself of course.
-
Yup, I used Allegro 4.x with Allegttf that and it worked really well, except that it wouldn't draw many unicode symbols.
-
Best is flamebait :)
I like SDL because it is getting active funding and support from Valve (The Steam dudes), it supports a lot of environments and is really mature.
There is definitely a case to be made for other systems, but I like that SDL has been around for so long and still has very active development. SDL2 supports OpenGL and DirectX out of the box.
My 2 cents.
-
I might go the SDL way. Will it work fine on weaker computers, like netbooks that many people use nowadays?
-
I might go the SDL way. Will it work fine on weaker computers, like netbooks that many people use nowadays?
If you code your game properly - yes, it will ;).
-
I've been using SFML for some time now. It's not as mature as SDL, but its maintainer is very active and helpful on the forums, documentation is very good, and the object-oriented interface is a lot nicer to program in than SDL. Version 2.0 was finally released not long ago, after a long time in RC state.
-
I think that if you want simpler (to use) you might want to go with SFML, I've heard a lot of good things about it. If you want to ensure portability to a maximum number of platforms (desktop/phone), then SDL may be a better choice.
Like I said, 'best' is flamebait :)
-
Come on, I wouldn't expect a flamewar over a graphics library... Or am I just new to the Internet ;D
Anyway, thanks for recommendations, I'll try out SFML then maybe.
-
I hadn't realised SDL2 was also about to come out and with hardware support and all that, but SDL just felt a lot more low-level than SFML ever did. It required lots of extra libraries to do stuff like rotations and so forth. I am sure SDL 2.0 is better, but I do really like SFML's API. I'm currently using PySFML. I have a major gripe in that it doesn't support drawing a line, which is annoying, but maybe SFML does?
-
About two thirds of the way down http://www.sfml-dev.org/tutorials/2.0/graphics-shape.php .
-
sfml is beautiful
-
The only problem with it is it sounds like Super FML.
-
That made me laugh out loud :D
-
I recently dumped SDL, because it was so complicated to build an executable that would run on different versions of windows. You need lots of extra libraryies to do simple things like loading a jpeg or png file. With all those libraries come the linking nightmares.
I wonder if SDL 2 will be any easier to use...
-
I recently dumped SDL, because it was so complicated to build an executable that would run on different versions of windows. You need lots of extra libraryies to do simple things like loading a jpeg or png file. With all those libraries come the linking nightmares.
Huh, funny. I just went back to SDL because it supports many different operating systems so well, and tends to work really smooth and problem free. And adding another library for extended functionality is no more trouble than setting up the main SDL.
-
I recently dumped SDL, because it was so complicated to build an executable that would run on different versions of windows. You need lots of extra libraryies to do simple things like loading a jpeg or png file. With all those libraries come the linking nightmares.
I wonder if SDL 2 will be any easier to use...
If I were you, I wouldn't worry about linking problems when choosing graphics framework. You will face them anyway, using external libraries or not. And you will face them many times since they are a common problem in C++. No library will save you from them. Better learn how to deal with common problems now so you are prepared for future.
Or write in Java.
OK, the last one was a joke, of course ;).