|
Socoder -> Question of the Day -> QOTD - C++ Graphics Libraries |
|
| Tue, 28 Jul 2009, 11:44 | |
shroom_monk
|
I've been thinking about graphics and sound in C++... a little while ago I was experimenting with Haaf's Game Engine (HGE), which is pretty easy to use. But I've also heard of SDL, which is apparently another graphics library for C++. A friend of mine said a while ago that it was better just to use OpenGL than any of these libraries, though. So my question is: when it comes to graphics and sound in C++, what do people use? HGE, SDL, OpenGL, or something else? Which would you consider better, and why? Or is using a graphics library 'cheating' - should you do it yourself instead? What are people's views? -=-=- A mushroom a day keeps the doctor away... Keep It Simple, Shroom! |
| Tue, 28 Jul 2009, 11:53 | |
Phoenix
|
HGE is in my opinion a pretty bad graphics library. SDL is great for interfacing with OpenGL without having to dabble with the intricacies of the Windows API, but its built-in graphical capabilities are fairly limited. I would recommend SFML. I haven't used it extensively, but from what I've seen I think it's better than most libraries. There is no such thing as cheating. SFML doesn't have super streamlined drawing routines, i.e. it uses OpenGL's immediate mode internally for rendering, but it should be enough for most stuff. If you're after having huge amounts of sprites on screen, the OpenGL road is perhaps something worth looking into, perhaps in conjunction with SDL. I doubt this will be necessary though. As a general rule of thumb, it's always better to use a pre-made library if it's written properly and has support. Saves you from reinventing the wheel. When you find that a library is insufficient for your needs, that's when you try to roll your own. Sorry I can't write a more lengthy reply, I have to go now. |
| Tue, 28 Jul 2009, 12:10 | |
JL235
|
SDL does have graphics functions, but like Phoenix says it's mainly used in conjunction with OpenGL. Quake 4 used SDL! But it really depends on what you want. You could just use DirectX which includes libraries for 3D, sound, music, video, controls, networking and more. That would be my recommendation over OpenGL with lots of other random libraries, although there is also OpenAL for sound. I personally use OpenGL with Java and it works well. I chose to use it over the other game libraries available because 1) I wanted a complete framework to help with the entire game and 2) none of them were tailored solely for 2D games. Shroom_Monk If there is a graphics library that's perfect, use it. If not, build your own. Which would you consider better, and why? Or is using a graphics library 'cheating' - should you do it yourself instead? What are people's views? Just research your options fully, including what happens after you've built it like any license restrictions and how you will go about deploying it. Also is it well supported/maintained? Is it well documented? Is there an active community around the library? |
| Tue, 28 Jul 2009, 14:46 | |
cthug
|
SDL is a great library, its LGPL and cross platform. SDL is really a low(er) level graphics layer. See the SDL homepage here. Irrlicht is a great high level c++ cross platform game engine. Uses openGL, Direct3D or Software rendering. Has a it own GUI system. Reads from .zip, .pak, .pk3 and Many texture and model formats: Currently supported textures file formats: * JPEG File Interchange Format (.jpg, r/w) * Portable Network Graphics (.png, r/w) * Truevision Targa (.tga, r/w) * Windows Bitmap (.bmp, r/w) * Adobe Photoshop (.psd, r) * Zsoft Paintbrush (.pcx, r/w) * Portable Pixmaps (.ppm, r/w) * Quake 2 textures (.wal, r) Currently supported mesh file formats: * Irrlicht scenes (.irr, r/w) * Irrlicht static meshes (.irrmesh, r/w) * 3D Studio meshes (.3ds, r) * B3D files (.b3d, r) * Alias Wavefront Maya (.obj, r/w) * Lightwave Objects (.lwo, r) * COLLADA 1.4 (.xml, .dae, r/w) * Microsoft DirectX (.x, r) (binary & text) * Milkshape (.ms3d, r) * OGRE meshes (.mesh, r) * My3DTools 3 (.my3D, r) * Pulsar LMTools (.lmts, r) * Quake 3 levels (.bsp, r) * Quake 2 models (.md2, r) * Quake 3 models (.md3, r) * DeleD (.dmf, r) * FSRad oct (.oct, r) * Cartography shop 4 (.csm, r) * STL 3D files (.stl, r/w) Only problem is that it has no physics engine or networking but it can easily used with other physics engines like ODE (Open Dynamic Engine), Tokamak, Ageia PhysX and Newton Game Dynamics. It is licensed under zlib/libpng license, homepage. |edit| Also you can use SDL_net for networking with irrlicht easily |edit| -=-=- CTHUG.co.nr Get Ubuntu 
|
| Tue, 28 Jul 2009, 14:50 | |
Jayenkai
|
If something's there, bloody well use it! There's no cheating in coding. Well, unless you steal someone elses game, and call it your own!! You'll probably find that each lib has it's own purpose. So one would be better suited to one sort of game, and vice versa. Figure out what you want to do with it, and then see what there is that could help achieve it. -=-=- ''Load, Next List!''
|
| Tue, 28 Jul 2009, 14:56 | |
|
Phoenix
|
SDL has no hardware accelerated graphics built-in, so no alpha-blending, rotating or scaling. At least not at a manageable speed in realtime. Then he's better off with the aforementioned SFML. I have some issues with Irrlicht, but I suppose that it's workable. It is however primarily a 3D engine, and although Shroom didn't say anything about what he was looking for I suspect that he wants a framework fit for 2D stuff. |
| Tue, 28 Jul 2009, 14:59 | |
|
Jayenkai
|
Oh, well if it's just 2D stuff he's after, then it shouldn't be too hard. I wrote a 2D in 3D framework, and I know Phoenix has, too. It's a simple case of load images, create squares polys, use image as texture. It's relatively easy no matter whether you're using OpenGL or the dreaded ever-changing, never the same, DirectX. The thing I found the hardest was actually the audio, not the graphics.. -=-=- ''Load, Next List!''
|
| Tue, 28 Jul 2009, 16:22 | |
|
Hotshot |
why dont you used allergo that have rotating or scaling but not sure about alpha-blending!
|
| Tue, 28 Jul 2009, 19:40 | |
|
cthug
|
With SDL you can use other libs, that rely on SDL, like SDL_image to load heaps of image formats, SDL_gfx for rotating, fps managing, primitives (lines shapes etc), SDL_net for networking and SDL_ttf for ttf rendering.
-=-=- CTHUG.co.nr Get Ubuntu
|
| Tue, 28 Jul 2009, 20:23 | |
Cower
|
I'll put in a recommendation for SDL and some advice that you should avoid Irrlicht like the plague. Former because it's good, fast, stable. Latter because it's got the most convoluted API ever, doesn't really support anything of value (if you just glance at the feature list, it looks long and seems impressive, and then you read it and should hopefully realize it's actually a very weak engine). Chances are you just won't like it.
|
| Tue, 28 Jul 2009, 20:39 | |
|
JL235
|
I find it odd that Irrlicht supports loading Photoshop documents but not Direct Draw Surfaces for textures.
|
| Tue, 28 Jul 2009, 21:15 | |
|
cthug
|
I agree that the developers of irrlicht probably should spend more time on the functionality of the engine rather than the file formats it supports.
-=-=- CTHUG.co.nr Get Ubuntu
|
| Thu, 30 Jul 2009, 10:32 | |
|
mindstorm8191 |
I can't talk about other engines because I haven't used them, but I have used Allegro, and its not really that bad, especially for 2D games. I don't use it often so can't comment much more about it, but the documentation is thorough and the API is straight-foreward. I'm just not a big fan of C++. For 3D games you'll have to resort to something else, I think...
-=-=- Vesuvius web game
|
| Thu, 30 Jul 2009, 10:51 | |
Afr0
|
There's also the Quake III engine from id. It's written in C, though I believe it's been ported to C++. Also, rumours are swirring that Doom III's engine code will eventually be released. It's been written from scratch in C++.
-=-=- Afr0 Games Project Dollhouse on Github - Please fork!
|
| Thu, 30 Jul 2009, 12:46 | |
|
Cower
|
Also, rumours are swirring that Doom III's engine code will eventually be released. It will be released some time after Rage has been released.
|
| Thu, 30 Jul 2009, 12:58 | |
|
JL235
|
When/if it's released it will also almost certainly be just the engine, not the game content.
|
| Thu, 30 Jul 2009, 13:28 | |
|
Afr0
|
This thread is for graphics libraries, not game content.
-=-=- Afr0 Games Project Dollhouse on Github - Please fork!
|
| Thu, 30 Jul 2009, 13:33 | |
|
JL235
|
I know. I wasn't trying to correct you, I was just saying. It won't be Doom 3 they are releasing, it'll be the Doom 3 engine. Some people would get those confused. |
| Thu, 30 Jul 2009, 23:39 | |
|
Nolan |
I always thought HGE was great, but in all honesty there's no practical reason to create games in C++. No, this isn't a "use this language instead" post, but just the truth. The language simply wasn't meant for a lone user to make a game with.
-=-=- nolandc.com
|
| Fri, 31 Jul 2009, 04:11 | |
|
Phoenix
|
You cannot state that you don't want a language debate, and then clearly call your own thoughts "just the truth," hoping to avoid some kind of argument. I began with C++ because I wanted something more than Blitz. I still use Blitz every now and then, but mostly to test ideas I have, for quick prototyping. The are many reasons for using C++ instead of Blitz: there's a great amount of libraries available, it's cross-platform, it's what's used in the industry (if one wants a career it's pretty much required), it's OO, and there are no dependencies (no .NET, XNA, JRE, etc) apart from a tiny runtime library in Visual Studio, which is embedded anyway. I have been looking into BlitzMax, which seems to be a very nice language, but I can't see the killer reason to make the switch. I've grown pretty used to C++, and I don't see BlitzMax offering anything I don't already have for free. If I decide to leave C++, it will be for C#. To me, programming isn't the slim bottleneck. Art and sound is, but that's a completely different topic. To step away from the digression a bit, shroom has been pretty silent. Have you decided on anything yet? |
| Fri, 31 Jul 2009, 05:03 | |
|
shroom_monk
|
Well, I've been looking at the various options discussed, although I don't have much time at the moment because I'm on holiday.  But I have downloaded SFML, and it does look a bit easier to use than HGE. I'm intending to experiment a bit with it later, but I do think that's what I'll use.Nolan in all honesty there's no practical reason to create games in C++I think there is good reason. As Phoenix said, it's used in the industry and it's OO, it's cross-platform and has no dependencies. Blitz may be faster to create games with, but there were often times when it couldn't do things I wanted to do, but C++ probably could. Which is why I intend to use it. -=-=- A mushroom a day keeps the doctor away... Keep It Simple, Shroom! |
| Fri, 31 Jul 2009, 05:31 | |
|
JL235
|
Nolan didn't mention anything about Blitz Basic or Blitz Max in his post. C++ is industry standard for game development, but so are lots of other languages (although at a lesser extent) such as Lua, Flash and Java. Blitz Basic and Blitz Max however are not industry standard, at all. Shroom_Monk Blitz may be faster to create games with, but there were often times when it couldn't do things I wanted to do, but C++ probably could. Which is why I intend to use it.For that very reason, I'd say Blitz Basic makes building games slower rather then faster. It's pretty rare that you truly cannot can build the same effect in BB, it's just that you typically need to do it in a far less productive and maintainable way. |
| Fri, 31 Jul 2009, 07:03 | |
|
shroom_monk
|
Well, for basic game design, Blitz is faster in C++ - the main advantage being graphics. As we've discussed, C++ needs various libraries to easily support graphics, whereas Blitz has the commands inbuilt. However, as you said, for more complex tasks, Blitz is much slower, but it's designed for making games, not for more complex processing, which is where C++ is more useful.
-=-=- A mushroom a day keeps the doctor away... Keep It Simple, Shroom! |
| Fri, 31 Jul 2009, 07:50 | |
|
JL235
|
I didn't meant BB is slower in terms of CPU performance, I meant it's slower in terms of your productivity. i.e. how long it takes you to write a program. Yes it takes longer to get graphics going, but spend a week getting all the main 2D graphics functions knocked out and you done. I also don't agree that the limitations in BB don't matter for games. For example you cannot create a local array, pass arrays into functions or return them. Wanting to do these are pretty common for all programming tasks. |
| Fri, 31 Jul 2009, 12:52 | |
|
Nolan |
Well, perhaps it will start an argument, but it's more a "language X not suited for project Y", rather than "language X is better than language Z." C++ is an industry standard because of legacy code and because, ten years ago, there was nothing better. This is no longer the case. C++ is cross platform in a sense, but good luck trying to sort out all of the little kinks. It's not a straight port. If you were making a huge MMO, than certainly, use C++, but for any project of modest size, the extra power is unnecessary. And like JL235 said, I'm not advocating another language (BlitzBasic would not be my suggestion). I'm predicting a change in industry standards towards more manageable and modern languages, if it's not happening already. -=-=- nolandc.com
|
| Fri, 31 Jul 2009, 13:04 | |
|
JL235
|
I agree with one of Nolans points, lots of industry specialists (such as Tim Sweeny who founded Epic Games) have started advocating alternative languages, namely functional ones. It tends to be far easier to predict the flow of the program in these languages allowing for better static analysis (spotting potential null pointers) and automated parallelism (which is the key to high performance in the future). But in 10 years time I would still expect C++ to be a popular language for game development. However all this is arbitrary. Once you've learnt a few languages, you've learnt them all and can switch to new ones within a week or two. I learnt TCL, VBScript, VBA, Erlang, C-Shell and Bourne Shell; as well as lots of accompanying libraries over the last year alone. |
|
|
| |||
|
| ||||