next »

[skyy]

I'll throw a lucky guess: raise it to the next pot.
Quite common thing to do. That's what I'd do too. Hell with extensions. More work for the programmer. *whip whip*

[Martin 2BAM]

I'm almost sure it does, and accomodates the "subrect" (shown region, tx coords) so the image is shown properly.
Anyway, that will increase loading times a bit.

The extension checking could be there to discard resizing increasing loading speed and lower texture memory use (besides the graphics card mem, SFML stores images in the RAM in order to be able to "set/get" pixels)

[falsion]

So after trying SDL and SFML I have to say I like SFML more than SDL, though I wouldn't say SDL is bad. It's just harder to set up, and too modular for me. I like my fonts and image rotating all in one lib.

Anyway, which do you like better and why?

Whichever that jerk Zaratustra doesn't use. How dare he get so much attention when a game like Fall is free.
^{saw the username and couldn't resist, sorry.}

[Mikademus]

Let's not bring sentiments from other threads into here, eh?

[Gold Cray]

It seems I've just switched from SDL to SFML. I've only got two issues with SFML: all the function names are capitalized, and the windows dlls are huge.

[Mikademus]

Yeah, the capitalised letters bothers me too! Of course it is a small, perhaps even insignificant thing, but it looks ugly and is counter to conventions.

That said, our experiences with it so far is that we're increasingly convinced that it is an excellent language to use to rapidly produce at least somewhat demanding prototypes in. We will likely not use it for sharp versions, though, except perhaps for smaller one-off projects.

[Klaim]

Yeah, the capitalised letters bothers me too! Of course it is a small, perhaps even insignificant thing, but it looks ugly and is counter to conventions.

Most in-company C++ code I've seen follow those rules...

Low characters on first letter is typically Java-based convention, came later than those type of conventions

I tested a lot of conventions, now I use different conventions on different type of code (library, game, public project, private project, language extension/lib, etc...)

[Mikademus]

Yeah, the capitalised letters bothers me too! Of course it is a small, perhaps even insignificant thing, but it looks ugly and is counter to conventions.

Most in-company C++ code I've seen follow those rules...

That's not my experience, and as examples both Qt and Google prescribe lower-case leading character of members, but I doubt either of us have got enough empirical data to make generalised claims with statistical significance

[Klaim]

Yes, I meant that lot of company uses that convention and many others, there is not such a thing as "looks ugly and is counter to conventions" in the C++ programming world, at least 

[increpare]

there is not such an exception to "looks ugly and is counter to conventions" in the C++ programming world, at least 

That was maybe too easy

[BrianSlipBit]

and the windows dlls are huge.

You're gonna want to statically link anyway, so DLL size is moot.  However, if you insist on using the DLLs, then expect to crash on exit when running on ATI cards.

[Mikademus]

kada2k9, your post contributed absolutely nothing in a comparative context since it was only about self-confessed ignorant prejudice O.o *applause*

[Klaim]

kada2k9> For having used it each day this week I can say that SFML don't gives you more than you need, at all.
It's not an engine, it's only some basic bricks like sprite and display systems ready to be used to build a game engine with.
SDL is the same but older and really really badly organized... (and in C but that might not be a real problem if you make a C game).

[jmp]

I’ve used both. I reverted from SFML to SDL (or GLFW occasionally) because SDL has (in my opinion) a cleaner API, is more mature, stable, has a larger developer base (as opposed to a rambo coder) and doesn’t have as much useless code I never use (TrueType fonts, sprites, the butt-ugly log system, etc.).

Another (and perhaps more important) reason I prefer libraries with less features is that it’s a perfect way to learn more about implementing a sound or font system, animation classes, etc..

It’s worth at least trying both.

[PGGB]

kada2k9, your post contributed absolutely nothing in a comparative context since it was only about self-confessed ignorant prejudice O.o *applause*

Good thing I apologized in advance then  

However, he did ask what people prefered and why, so I can't really give more than my subjective opinion, can I?

Well yeah, but your opinion is useless if you know only about one of the options (and you obviously do know only about SDL).

[Ben Kuhn]

(I suggest we stop piling on kada2k9. Clearly he's at least developed some opinion on SFML, which he stated in his first post, so he had at least some grounds to post. Plus, people have pointed out that said opinion might not be legitimate, nothing's going to come of belaboring it except for hard feelings.)

My main issue with SDL is lack of good OpenGL support. SDL is a relic of the era when OpenGL wasn't as common as it is now, and so it was actually useful to have a blitting graphics engine. But now that OpenGL is on nearly every computer, there's no reason to use the slower, less flexible blitting engine of SDL, making it basically bloat. If you're using SDL OpenGL without blitting, you have no reason to complain about SFML's cruft. (And remember that SFML is way smaller static linked.) Plus SDL gives you jack all to work with if you try to use OpenGL, whereas SFML has the excellent Sprite class to take care of mucky texture business. (Note: for some deranged reason SFML's sprites do not support setting the OpenGL z-coordinate, which means you have to draw them in depth order CPU-side. Next time I use it I'm going to submit a patch, because that's pretty dumb. Other than that, Sprite is way better than anything SDL has to offer.)

Then of course there's language thing. SFML has a much slicker object-oriented interface than SDL, because C++. I myself love objects, but I also hate C++ object semantics, so it's kind of a toss-up. If you can deal C++'s references/pointers/copies/whatever crap, then go for SFML hands-down; it will make your life about an order of magnitude easier (and your code half as long). On the other hand, if you need a language that takes up less brain-space, SDL is written in C, which is easier to understand (to me, at least).

SDL has excellent bindings to other languages. If you need access from a scripting language it might be a safer bet. SFML also has bindings, but fewer (only C, .NET and Python at the current version), and you may have to figure some things out yourself. Of course, the SFML bindings to OO languages are probably much slicker than SDL's.

Feature-wise, SFML wins by a long shot, in my opinion. The main reasons: better OpenGL integration (Sprite object, fonts, ...), better sound support (SDL_mixer ameliorates this, but then you're adding more dependencies and it sometimes lacks bindings), and some niche features like FTP and sound recording.. SFML 2.0 will also include UTF support (for internationalization), which is pretty nice for some people. On the other hand, SDL has CD support, which is fast becoming a niche feature in its own right. With that plus the severely outmoded blitting engine, it's hard for me to say who's ahead in the bloat department -- SDL is smaller, but probably has just as much API bloat. And if you add in SDL_mixer and SDL_net and SDL_ttf (to get up to functionality-par with SFML), you're getting pretty big there.

SDL has been around longer than SFML but personally I haven't noticed any bugs in either of them (except for the crash on exit with ATI cards on dynamic linked SFML, I guess). Also, SDL has been moving very slowly in recent years as the devs don't have as much time as they used to. It *will* work on more platforms if you need to go beyond the Big Three.

There's also the small matter of license. SFML is zlib/libpng, which is more liberal than LGPL - most saliently, you're allowed to static-link it, and not SDL. That could simplify your distribution significantly.

Yeah, I think that covers the main differences between SFML and SDL. Better features, slicker interface, zlib license vs. maturity, platform support and smaller size.

Edit: The ability to static link to SFML with proprietary programs is actually quite useful, because some compilers (GCC for example) can cut down its size quite a bit with dead code elimination. So SFML has more bloat if you link them both dynamically, but if you link statically to SFML you don't have to worry about carrying a bunch of cruft in your exe, whereas you'll always have to lug SDL's CD/blit functions with you.

[Gold Cray]

I haven't tried using fonts with sfml yet, but I remember font support in SDL being pretty poor. It used 1-bit alpha or something so anything that wasn't a raster font ended up looking really bad.

[oahda]

Fonts in SFML work great.

[TeaAndBiscuits]

WOW! SFML sounds great! I have always used SDL rather then writing my own  windows code (YUCK!) and that was good enough for me.

To get up and running now I have been using SDL blit methods and they really are limited. No support for scaling?!?!?!

I'm downloading SFML now, looks interesting, though I REALLY don't need half the stuff it supports. This is why I liked SDL, it does so little... though as I said above somtimes too little.

[TeaAndBiscuits]

Just had a quick look at the SFML source code. If I compile myself then would be very easy to remove any stuff I don't like (I'm looking at you OpenAL!) and yes, the source is nicely split up with lots of support for lots of useful things like sprites, maths, sound etc.

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.