SFML community forums
General => General discussions => Topic started by: orgos on June 09, 2009, 04:34:11 pm
-
Hello.
It's SFML good enough for comercial games like Stacraft and diablo 2?
Some people make casual games with it? and try on others plaftorms like linux and mac?
-
Yes it is good enough. It works fine on Linux and Mac also.
-
Look at the projects on the projects forum (http://www.sfml-dev.org/forum/viewforum.php?f=10)to have an idea.
And as I'm here... I might as well just leave a link to a game I made (http://www.sfml-dev.org/forum/viewtopic.php?t=1300), as an example of course :roll: :lol:
Good luck!
-MartÃn
-
Of course its well enough for commerical games. I've just started using it, and I can say its pretty amazing. Its better than SDL.
-
No, it's not. "Real" commercial games like that are written their own, specialized, optimized engines directly on top of DirectX/OpenGL. No actual game developer giant would use SFML. They have offices full of seasoned programmers so it's not a problem for them.
At least, that's how I see it. Could be wrong.
-
Core Xii,
I'm one of those "seasoned programmers" you speak of, 20+ years as a game developer.
I have published titles based on Ogre3D and ClanLib as well as using a number of other Open Source libraries, including Lua which I have co-written a book ("Game Development with LUA").
I am using SFML 1.5 in my current project because Ogre3D is way too heavy for this project and ClanLib has all but abandoned the Mac platform (though I am now concerned about SFML as the Mac maintainer has announced his retirement). I use Open Source libraries because I don't want to write the same functionality myself. Why would I spend my time re-inventing the wheel when a perfectly good wheel is available free or for the cost of making some of my additions available to the other users of the libraries?
In fact, I would say that anyone, no matter how rich in resources, that would rather "roll their own" is being grossly foolish.
-
Why would I spend my time re-inventing the wheel when a perfectly good wheel is available free or for the cost of making some of my additions available to the other users of the libraries?
Because the reinvented wheel is 100% optimized for whatever you're doing. Blizzard would never use SFML for StarCraft because by writing their own engine they get every bit of juice out of it that a generic library cannot offer by design.
Ogre3D falls into the same category. "Real" developers don't use Ogre3D either.
-
Because the reinvented wheel is 100% optimized for whatever you're doing. Blizzard would never use SFML for StarCraft because by writing their own engine they get every bit of juice out of it that a generic library cannot offer by design.
Ogre3D falls into the same category. "Real" developers don't use Ogre3D either.
Sorry, but that is nonsense. There is absolutely no reason to "reinvent the wheel" every time, especially in cases that are absolutely not performance relevant (like... using SFML or SDL to create an OpenGL window)
Don't believe it? Then look at the Neverwinter Nights Linux client... guess what they use for the OpenGL window... SDL! (And we all know SFML is better :-D )
*Still* don't believe it? Then look at what all those "real" developers use for their games.... How many games are there that use Havok? The Source engine? The Unreal engine? SpeedTree? Did these developers reinvent the wheel? No, because it's just not worth it. Yes, the aforementioned examples are not opensource, but there are a few commercial games that use Ogre (For example Ankh by Deck13) and even more that use Bullet ( see here http://www.bulletphysics.com/Bullet/phpBB3/viewtopic.php?p=11971#p11971 and don't tell me you've never heard of these "tiny" developer studios mentioned ;-) )
Ok... sorry for that rant, but this just had to be said
-
How many games are there that use Havok? The Source engine? The Unreal engine? SpeedTree?
Havok and SpeedTree are in an entirely different ballpark. They are specialized libraries, Havok specifically designed to simulate physics in a certain way (performance over accuracy), and SpeedTree to procedurally generate trees.
SFML on the other hand is a generic library - It isn't designed to render any type of graphics in particular. Thus a custom graphics engine will always benefit a taxing game.
Now I'm not trying to diss SFML here or anything, I use SDL myself in my indie dev hobbies. You can use SFML for real games like StarCraft, but writing your own graphics routines is still always better (if more laborious).
-
Havok and SpeedTree are in an entirely different ballpark. They are specialized libraries, Havok specifically designed to simulate physics in a certain way (performance over accuracy), and SpeedTree to procedurally generate trees.
SFML on the other hand is a generic library - It isn't designed to render any type of graphics in particular. Thus a custom graphics engine will always benefit a taxing game.
Now I'm not trying to diss SFML here or anything, I use SDL myself in my indie dev hobbies. You can use SFML for real games like StarCraft, but writing your own graphics routines is still always better (if more laborious).
Specialized or not, libraries like SFML (SDL can be consideres the same kind of library) are being used by your so-called "real" developers!
And... Ogre3D is a library specialized in graphics ;-) (it's not a generic game engine)
-
99% of the """"""""real""""""" developers just license engines because the developement of an own engine is more expensive. on the market at the moment there are the ID engines (tech 5 now), of course the unreal engine and the source engine, thats it. blizzard is one of the few companies who constantly develop new engines for their games.
and the guys who do write their own engines just do it because engines like Ogre3D lack a loooooot of features they need. it's not because ogre3d is too slow, or not well enough designed, it's just that it misses a lot of stuff (by the way studied the source engine source code when it leaked a few years ago and hell that thing was a fucking mess).
in the realm of 2D games however, SFML is perfectly fine and probably the best thing you can use at the moment. the few "real" developers that you name so often (kyle gabler, petri purho) use SDL because they've written their engines years ago when SFML wasn't even around and they still use their old engines, thats why they don't need to switch to sfml. some even use totally different things (take derek yu for example, he built spelunky using some game creator)
in the realm of 2d games, there's very few things that you'd actually have to implement anyways, since 2d is not as complicated. 99% of 2d-game engines consists of actual game-stuff instead of graphics stuff.
so to simply answer the op's question: yes sfml is perfectly fine for 2d graphics. if you're talking about whole game engines sfml isn't one anyways.
-
and the guys who do write their own engines just do it because engines like Ogre3D lack a loooooot of features they need. it's not because ogre3d is too slow, or not well enough designed, it's just that it misses a lot of stuff (by the way studied the source engine source code when it leaked a few years ago and hell that thing was a fucking mess).
Actually, you can do almost every effect with Ogre (most new effects are shader based, which is possible, and iirc you can even define your own passes in Ogre) In this case the slowness might actually be the real problem... (haven't found ogre to be particularly fast)
so to simply answer the op's question: yes sfml is perfectly fine for 2d graphics. if you're talking about whole game engines sfml isn't one anyways.
But unlike the 3d-side (ogre), sfml contains everything necessary for a game engine (except physics, which isn't necessary for most 2d games and if it is... box2d)
-
99% of the """"""""real""""""" developers just license engines because the developement of an own engine is more expensive. on the market at the moment there are the ID engines (tech 5 now), of course the unreal engine and the source engine, thats it. blizzard is one of the few companies who constantly develop new engines for their games.
Uh... Epic Games wrote the Unreal Engine for themselves. Valve wrote the Source engine for themselves. They're not some generic engines written by an outside party.
These big names are exactly the "real" developers I'm talking about. Your average commercial game developer doesn't write their own engine because it's easier to use an existing one... But that's the difference between those developers, and the absolute top-notch devs like Valve and Blizzard.
Also, again, I must note that the engines mentioned here are again specialized engines, Source specifically designed for first person shooters, etc.
SFML is not the de-facto library for 2D games. It lacks a lot of features like palette mode and vector drawing, and really only excels in rendering raster images.
-
99% of the """"""""real""""""" developers just license engines because the developement of an own engine is more expensive. on the market at the moment there are the ID engines (tech 5 now), of course the unreal engine and the source engine, thats it. blizzard is one of the few companies who constantly develop new engines for their games.
These big names are exactly the "real" developers I'm talking about.
Ahh right. And I guess, for you, the only "real" astronauts are the ones who went to the moon, right?
Valve did indeed write the engine primarily for themselves, Epic Games however, specifically designed and developed the UE3 for others. My facts for that u ask? When the UE3 appeared in the public, Epic Games made huge advertisement for it, not to mention that there's a MASSIVE toolchain around the UE3. They did it because the Unreal Engine 2 was used by many many games, and they knew (and know) that they can make a lot of money with their engine.
They didn't develop the engine for UT3 and then added a couple of features so that they could license it to others... they developed the engine for the sole purpose of licencing it to others. using it for their own games was just a bonus. Epic Games major income comes from their engines.
Say, I assume you're not working in the gaming industry right? Have you ever seen the work of one of your "average commercial game developers" (i mean the code)? Have you ever seen the code of some of your "real" developers? I assure you, pretty much every single one of those "average commercial game devlopers" could produce the same things that EG, Valve and ID produces. The only reason they don't is MONEY. Nothing else.
Also, who the hell needs vector drawing for games? SFML isn't even supposed to be a "engine". It's a fucking library for the very basic stuff. Has anyone of you ever written a game engine? Please stop talking if you actually haven't ever done anything like it.
-
They didn't develop the engine for UT3 and then added a couple of features so that they could license it to others... they developed the engine for the sole purpose of licencing it to others. using it for their own games was just a bonus. Epic Games major income comes from their engines.
Same thing for id Software. The Quake games were mainly glorified tech-demos...
Also, who the hell needs vector drawing for games? SFML isn't even supposed to be a "engine". It's a fucking library for the very basic stuff. Has anyone of you ever written a game engine? Please stop talking if you actually haven't ever done anything like it.
If I'm not mistaken, vector graphics are planned for SFML 2... And vector graphics are very useful IMO, for example for GUIs (esp scalable ones).
-
SFML isn't even supposed to be a "engine". It's a fucking library for the very basic stuff.
And that's why I would not recommend it for any... complicated projects (anything but the simplest raster graphics). It limits creativity. Every time I consider using SFML for one of my projects I run into some limitation and have to go back to reinventing the wheel. It doesn't have the simplest stuff like palette mode and vectors.
But of course, SFML is still in active development. That's why I'm lurking around here.
-
It doesn't have the simplest stuff like palette mode and vectors.
Why would anyone want/need a palette mode?
-
It limits creativity.
Are you saying libraries limit creativity compared to engines? I would have to disagree, a person is free to implement the game however he pleases with SFML but other systems make you use their "descriptor" formats, especially for sprites and animations. In SFML you can implement it the way you find most intuitive. Furthermore, the commercial RPG Torchlight (made by former Blizzard employees who worked on Diablo 2) uses Ogre3D. This is a testament to open source software's ability to progress and compete with commercial libraries. And now may we let this horrid topic die.
-
Why would anyone want/need a palette mode?
What kind of a question is that? That's like asking "why would anyone want 3D graphics?" It's an art style as any other. Not as frequently used perhaps, but an art style nonetheless.
-
What kind of a question is that? That's like asking "why would anyone want 3D graphics?" It's an art style as any other. Not as frequently used perhaps, but an art style nonetheless.
No, it's not an art style, it's a limitation. Everything that can be done in palette mode, can be done in 24-bit colors (you just have to limit yourself to a certain pallette).
And here's a suggestion: Why not render in 8-bit grayscale and do a post-fx palette mapper :P
-
No, it's not an art style, it's a limitation.
Are you kidding me? Who makes arguments like that seriously? If limitations were not art styles, the only kind of art style we would have is as realistic as possible. Please tell me you were joking with that incredibly stupid comment. The only kind of art we would have would be photographs and photorealistic renderings.
Everything that can be done in palette mode, can be done in 24-bit colors (you just have to limit yourself to a certain pallette).
Here we go again... Yes, you can eat soup with a fork but the spoon just does it better. You can emulate palette mode with 24-bit graphics but it's inefficient, you're forced to draw each sprite multiple times for each palette you intend to use on it.
Here, I'll give you an example. Suppose we have 100 sprites of 16x16 pixels in size, 4 bits per pixel. 16 palettes with 4 colors each, 32 bits per color.
With palette mode, all this takes only 13056 bytes or ~13 kilobytes to store in memory. And you can display any sprite with any palette.
With 24-bit graphics as you suggest, it would require a whopping 1638400 bytes or ~1.6 megabytes to store! That's a 12549% increase in memory consumption!
And here's a suggestion: Why not render in 8-bit grayscale and do a post-fx palette mapper :P
Because it's not the same. You can't draw any sprite with any palette with that.
Now thankfully, you probably won't need every sprite in every palette in practice, but my point stands. It's more efficient. And easier.
-
Core Xii, you seem to be here just for trollish flame. If you don't like SFML or other free libs, wouldn't you just pass by? :evil: :evil: :evil:
-
I think the point of Core Xii is not making a critize of SFML but triying to get better SFML with some issues.
-
Are you kidding me? Who makes arguments like that seriously? If limitations were not art styles, the only kind of art style we would have is as realistic as possible. Please tell me you were joking with that incredibly stupid comment. The only kind of art we would have would be photographs and photorealistic renderings.
Yes, I am serious, and your metaphor is totally off. Do painters only paint photorealistic paintings, just because they have many kinds of paint and brushes? No, they still make all types of painting, despite not being limited to -say- flat brushes.
Here we go again... Yes, you can eat soup with a fork but the spoon just does it better. You can emulate palette mode with 24-bit graphics but it's inefficient, you're forced to draw each sprite multiple times for each palette you intend to use on it.
Here, I'll give you an example. Suppose we have 100 sprites of 16x16 pixels in size, 4 bits per pixel. 16 palettes with 4 colors each, 32 bits per color.
With palette mode, all this takes only 13056 bytes or ~13 kilobytes to store in memory. And you can display any sprite with any palette.
With 24-bit graphics as you suggest, it would require a whopping 1638400 bytes or ~1.6 megabytes to store! That's a 12549% increase in memory consumption![/i]
So what? An average PC today comes with, what, 1GiB of Memory? So in one case you're using 0.001% and in the other 0.15% of total memory. Not much either way. Also you don't really have to draw them once for each palette. You can store them in palette mode and simply "expand" them on load.
Because it's not the same. You can't draw any sprite with any palette with that.
Then use 8 bit colors and shade the sprites individually using different textures as palletes (this is admittedly not supported by SFML)
Now thankfully, you probably won't need every sprite in every palette in practice, but my point stands. It's more efficient. And easier.
Well, about the more efficient part... I'd like to point out that the paletted texture opengl extension can only be considered deprecated ( http://www.opengl.org/wiki/Common_Mistakes#Palette ). So in any case the textures would still have to be "expanded".
This discussion is getting a little off track, so if you want to continue... just send me a pm :wink:
-
Core Xii, you seem to be here just for trollish flame. If you don't like SFML or other free libs, wouldn't you just pass by? :evil: :evil: :evil:
God, what's with all the hate? All I'm trying to do here is have an intelligent debate on whether SFML is good enough for StarCraft, the topic's original question.
I am not saying SFML sucks. I just want you to acknowledge that it's not the one and only all-powerful solution to all our problems. I already said I use SFML myself, didn't I? Not talking about one's flaws for the sake of not springing argument is just ignorance and stupidity.
Yes, I am serious, and your metaphor is totally off. Do painters only paint photorealistic paintings, just because they have many kinds of paint and brushes? No, they still make all types of painting, despite not being limited to -say- flat brushes.
And now suppose someone comes up with a painter's kit to aid painters in their work. It does not include flat brushes at all. And you're arguing that nobody uses those anyway. (actually, someone comes in and asks if the painter's kit is good enough to paint the Mona Lisa, etc....)
So what? An average PC today comes with, what, 1GiB of Memory? So in one case you're using 0.001% and in the other 0.15% of total memory. Not much either way.
SFML is also designed to run on low-end and embedded systems. (wait, I couldn't find any mention of this on the features page; Isn't it?)
Then use 8 bit colors and shade the sprites individually using different textures as palletes (this is admittedly not supported by SFML)
Why suggest something that's not supported?
I don't think it's getting off topic. We're still discussing whether SFML is good enough for StarCraft.
-
And now suppose someone comes up with a painter's kit to aid painters in their work. It does not include flat brushes at all. And you're arguing that nobody uses those anyway. (actually, someone comes in and asks if the painter's kit is good enough to paint the Mona Lisa, etc....)
Since were talking about colors... what about this: You give a painter 256 colors... or you give him 16.7 million colors (including all those 256 colors)... can't he do everything he can do with the 256, when given 16.7 million?
SFML is also designed to run on low-end and embedded systems. (wait, I couldn't find any mention of this on the features page; Isn't it?)
It's targeted at OpenGL 1.2 systems. Which by today's standards is very low end. Embedded systems not quite yet... (No OpenGL ES support... btw... did you know that GLES2 is a shader-only pipeline :P )
(PS: your sprite example would still only use up 1.22% of memory on a 128MiB machine)
Why suggest something that's not supported?
It's not -directly- supported, but you could of course make your own extension... (wouldn't be GL 1.2 anymore though) Besides, it's the only option except expanding the paletted images at load time. (OpenGL does not support palettes, no way around that)
I don't think it's getting off topic. We're still discussing whether SFML is good enough for StarCraft.
Which it definitely is :lol:
-
Since were talking about colors... what about this: You give a painter 256 colors... or you give him 16.7 million colors (including all those 256 colors)... can't he do everything he can do with the 256, when given 16.7 million?
That would be a valid analogy if we were debating bit-depth. But we're not; This is about the pixel format, RGBA versus palette index.
(PS: your sprite example would still only use up 1.22% of memory on a 128MiB machine)
Fine, I'm a perfectionist. So kill me. :wink:
-
That would be a valid analogy if we were debating bit-depth. But we're not; This is about the pixel format, RGBA versus palette index.
Ok, he gets the same 16.7 Mil. colors but is only allowed to use 256 at the same time :lol:
Fine, I'm a perfectionist. So kill me. :wink:
Hey, that's ok. Doesn't change anything about OpenGL (and therefore SFML) being incompatible with real palette modes (aside from emulation via shaders, which would be GL 2.0).
-
Ok, he gets the same 16.7 Mil. colors but is only allowed to use 256 at the same time :lol:
Still no. Palette mode doesn't restrict you to 256 colors. You can use any number of bits for that, just as with RGBA.
The trick is that you can change easily what the colors are by swapping the palette.
-
The trick is that you can change easily what the colors are by swapping the palette.
This can be done with shaders, as l0calh05t already pointed out (http://www.opengl.org/wiki/Common_Mistakes#Palette).
And since those shaders are supported by SFML, why couldn't you just use that approach?
-
well, to answer the topics question: your question is invalid. sfml is not a game engine and therefore there is no answer to "is sfml good enough for starcraft". it's like asking "is opengl good enough for a game like starcraft?" or "is iron a good engine for a car?". iron won't help you in your car. you first need to make an engine out of that iron (or whatever car engines consist of).
in the same way you first need to built a game engine around sfml. sfml only provides you with rendering, input, audio, networking and the basic OS-stuff (creating a window for example). therefore, sfml is not an engine (and it's not supposed to be). the stuff sfml does maybe accounts for a half percent of what you need for a game.
your question should be something like: "is sfml good enough to built an engine around it which would be good enough to programm something like starcraft?". then your answer is definately yes.
-
Oh god, I wish I found this earlier.
I made a whole bunch of cpps to make my crappy opengl window fully customized. I got a big headache making FSAA customizable... With SFML is so easy! (and so elegant!).
I love it!