next »

[Ben Kuhn]

I think if I was just about to start a project then SFML would be for me. All the setting up of Vector classes, sprites, rectangles, maths etc etc etc has been done. Thing is I am now so far into my project that switching from SDL now would have little benefit. Shame. Wish I knew I had taken a serious look at the lib before! Though I would have to compile from source as there is a lot of stuff in the API that I just don't like and wouldn't want hanging around.

If you link it statically, most compilers will kill a lot of stuff with dead code elimination, so don't worry about recompiling it.

Actually, that's another benefit of the license - you can't use DCE with SDL unless you static link it, which requires your program to be (L)GPL. So in practice, SFML may not be much larger if you don't use all that "bloat".

[Average Software]

I think if I was just about to start a project then SFML would be for me. All the setting up of Vector classes, sprites, rectangles, maths etc etc etc has been done. Thing is I am now so far into my project that switching from SDL now would have little benefit. Shame. Wish I knew I had taken a serious look at the lib before! Though I would have to compile from source as there is a lot of stuff in the API that I just don't like and wouldn't want hanging around.

If you link it statically, most compilers will kill a lot of stuff with dead code elimination, so don't worry about recompiling it.

Actually, that's another benefit of the license - you can't use DCE with SDL unless you static link it, which requires your program to be (L)GPL. So in practice, SFML may not be much larger if you don't use all that "bloat".

Dead code elimination isn't what you seem to think it is.  Dead code elimination is removing code that can be proved to have no effect on the program, such as this C example:

Code:

int x;

x = 5; // Dead code, has no effect due to the following assignment.
x = 6;

The optimization you refer to is unused code elimination, which is a completely different problem.  The terms are often used interchangeably, but there is a big difference.  Unused code elimination is most often a linker optimization, except in languages/compilers that have whole-program analysis capabilities.

[Martin 2BAM]

Fonts in SFML work great.

IF you're not doing a non-smoothed pixel game.
Because the border antialiasing is applied by FreeType2, and there is no way to turn that off in SFML... except by hacking the lib and replacing one parameter to another.

http://www.freetype.org/freetype2/docs/reference/ft2-base_interface.html#FT_Render_Mode
Check that out.

I posted a topic about it but I think that, as usual, was not integrated in the API.
I've re-read the topic and Laurent is a bit of a tool, replying to my request to optionally disable smoothing on fonts because "It would look ugly".

[increpare]

I posted a topic about it but I think that, as usual, was not integrated in the API.
I've re-read the topic and Laurent is a bit of a tool, replying to my request to optionally disable smoothing on fonts because "It would look ugly".

Which I found to be a pretty interesting response.  I'm doing a monochrome game right now so I ended up just getting rid of the anti-aliasing with a post-process effect : P

[JOBA]

Not really a valid comparison. SFML is in completely different category.
I can compare SDL with GLFW and GLFW is clearly better if you plan to use opengl.

While i totally love GLFW, it's still not complete gamedev package. It only loads .png files and has no sound functionality.

I have written simple wrapper/framework for GLFW(window, input, threading, time), OpenGL + DevIL(for all sorts of image formats) + OpenAL + alut(sound) + ogg + vorbis + loader for angelcode's BMFont.

This handles most of the stuff i commonly use. Downside is - it has plenty of dependencies which is something i clearly dislike. And i had to write considerable amount of wrapper-classes/encapsulation/resource management on top of it all, since all of them are C libraries.

And that's basically what SFML does. I'm cant quite judge how good/bad is the API since i've only played a little bit with it. From what i've heard, the API's not perfect and the maintainer is a bit stubborn, but if i'd had to choose between writing a framework again or using SFML, i'd probably go with SFML.

Also, the inclusion of font loading/displaying is totally understandable. Otherwise If i had to write a little game with SFML, i'd have to write my own font loader and that would suck.

SFML seems like a complete-ready-to go gamedev package. And i'm planning to try it for future projects.

[Klaim]

SFML seems like a complete-ready-to go gamedev package. And i'm planning to try it for future projects.

It is not. You don't have a game engine with it, only bricks to build one.

I've worked 10 hours with it for a 1week project last week and I clearly see that I could have been far faster with an full engine. But then I also would have to learn the engine first and be limited by some engine decisions.

So it's a good thing to start a game with, but don't assume you have a game engine ready to manage your game.

[JOBA]

SFML seems like a complete-ready-to go gamedev package. And i'm planning to try it for future projects.

It is not. You don't have a game engine with it, only bricks to build one.

Yes, it is.

I don't write engines. I write games.
And for writing games, it's pretty much a ready-to go gamedev package.
And by that i mean - i can load images, display sprites and text, play music and sounds. And do it in with no fuss.

Of course - i have to write a suitable tilemap class if i need one and i'll have to write pathfinding if i need it and whatnot. But it's part of the game code.

Well, if you're writing bleeding-edge 3d game (or just 3d game) you'll probably have to write a 3d model loader and some other stuff before being able to actually start working on your game, but otherwise if you stick with 2D, 2.5D or some simple, rudimentary 3D - you're pretty much set.

[increpare]

It is not. You don't have a game engine with it, only bricks to build one.

Yes, it is.

As discussed already, it has no animation classes (some examples provided on the site, but they're very bare bones), no collision classes, no gameplay code (pathfinding), no UI stuff, no cross-platform file IO stuff.  There's a whole lot of extra infrastructure that you have to do by hand if you want to make a 2d game.  Which isn't necessarily the end of the world.  Compare it to something like game-maker, flixel, or unity, and it's 'missing' lots of stuff.  You do seem to draw some distinction between gameplay and engine code, which is a distinction, but nonetheless one has to write a lot more generic game code with SFML than the other setups mentioned

[Klaim]

increpare++

I am making a simple SHMUP and had to write myself rendering and update organisation code calling Draw() on Sprites...

That's the kind of thing you write in an engine, and when I say engine, I don't think about big ones but just basic automatic stuff you don't have to write yourself because it's so basic need.

Just look at Flash, that looks a lot like a game engine. But you write directly your games in. You don't need to write your rendering loop in, but you still have control on it. (that might be a bad example for some specific points)

[Schtee]

I guess it's as much of an engine as XNA, in that it's not, but it's a library that abstracts some low level graphics and etc stuff.

[Akhel]

Alright, I'm getting a bit fed up with Allegro. How well can SFML handle tinting of sprites and transparent sprites/polygons?

[increpare]

Alright, I'm getting a bit fed up with Allegro. How well can SFML handle tinting of sprites and transparent sprites/polygons?

really easily

Switching to using it shouldn't be too tough - the interfaces aren't too far apart, really.

[SimonLarsen]

I have a quick question for you SFML users.

If I'm making a 8-bit-ish game I can use small resolution sprites (with smoothing disabled) and scale the screen (using views) while still preserving the pixel-arty look. However if I wan't to use primitives (line drawing, shapes etc.) they won't get pixelated, even If i zoom out before drawing them then zooming in before updating the screen.

Is there some way to draw primitives and then making them pixelated by zooming in with SFML?

[Gold Cray]

From what I hear this will be easier in the next version of SFML, but right now you could draw them to the screen, put that bit of screen in an image/sprite, scale the sprite, and draw the sprite. I don't know of any simpler solution off the top of my head.

SFML 2.0 is supposed to have support for drawing directly to images.

[kefka]

SFML is definitely the API of choice for me at the moment.  Especially with SFML2 around the corner, which introduces a couple of changes im really looking forward to:
- Batch rendering
- Better low level OpenGL access for vector style graphics

That being said I feel I should learn some other languages.  I'd like to learn Lua and also maybe check out PyGame

[InfiniteStateMachine]

been using SFML 2 for a while now. It's really stable and so easy to work with. Don't let the alpha status scare you away. I much prefer it to 1.6

[Golds]

Whichever you're more comfortable with.

[ProgramGamer]

I vote for using the directx api directly and relying on wine and steamos for multiplat support :^)

[Schrompf]

Yeah, DX will get you far, I presume. And I'm sure we'll come to a great conclusion for this topic last discussed in 2011.