would I be able to port SFML to platforms that aren't listed on the site (Win/Mac/Linux), such as PS4, Xbox One, WiiU, 3DS, Android, etc? Does anybody know if SFML would work on the Dreamcast?
SFML works on platforms supporting OpenGL. Additionally, SFML has to support the platform's window management. Currently this "limits" SFML to Win/Mac/Linux and more recently Android/iOS as well. PS4 doesn't use OpenGL, XBox will probably never use OpenGL (go figure why), WiiU doesn't use OpenGL, 3DS doesn't use OpenGL. SFML probably won't support any of these "closed" consoles requiring a hell of a lot more work and legal issues to get started with any time soon. It is a free, open source library and does not have the resources required (money) to easily support any of those platforms.
- Is SFML complete enough that I would be able to make a full SNES-tier game with it? I've used other APIs before only to find out later that they aren't actually 'complete'.
If all you need for a SNES-tier game is rudimentary sprite graphics, simple audio (play sounds and music), single window/screen management (not multiple windows/screens) and input, then yes, SFML will provide you with everything you need. Even if something pops up that isn't directly supported in SFML, there are numerous extension libraries that might provide what you need and if that isn't an option, it isn't too hard to implement custom functionality yourself.
- Is SFML 'open' enough that I can use Lua or Python as a scripting language with it? As in, are there features in the language that allow for this?
The language? Or the library? SFML provides mid-level object oriented access to graphics, audio, input and window management. It doesn't support high level concepts such as scene management or resource management. You will have to write all of that kind of high level stuff on top of SFML, and that is probably what you want to interface your scripting engine with. If you haven't stumbled into it yet, there is a
Python binding for SFML, probably not what you were looking for, but still worth a look if you are into Python.
- At what level does SFML become a burden over going straight to OpenGL, performance wise? As long as I'm using good algorithms and my engine is realtively optimized or well thought out, should there be no issue with my engine running at 60 fps (and my game is like an SNES-tier game)?
If you can optimize your scene to not draw too many things at once (let alone things that are not visible anyway), the performance is acceptable. SFML draw calls map 1:1 to OpenGL draw calls, the more SFML
.draw()s you have, the more OpenGL will have to do. If you reduce them, the OpenGL overhead also gets reduced. For a SNES-tier game, it shouldn't be too hard to get a good framerate. 60 FPS should be easy to achieve unless you do something really really wrong, in which case, you can always come and ask for advice on the forum. Performance related questions are not uncommon if you look in the graphics help sub-forum.
- Is there anything about SFML that a developer should know before dedicating themselves to making a full length complete game with it? Is it missing anything, is it buggy, anything like this, or is it fully ready to go?
SFML is designed to be stable, both implementation-wise and API-wise. It has most features that people might need to make graphically simple games, and if that isn't enough, it can interoperate with raw OpenGL quite well. Official releases of SFML aren't very frequent, the last one being 2.1 was released quite a while ago. This does not mean that progress isn't being made. If you check the official GitHub repository, you will see a lot has changed since 2.1 was released, and I would recommend you to compile and use the GitHub master branch or a nightly build of it. SFML has had a rather conservative versioning scheme in the past, and this might change, since a few months ago several people were added to its team of maintainers. The average release cycle between versions should be shorter now than it was previously.
In regards to whether SFML is missing anything, this always has to be asked relative to its target audience. If you were developing next-gen 3D games with cutting-edge graphics that should be ported to all major consoles as well, then maybe SFML might not be what you are looking for. If you aim to create a simple SNES-tier game, then SFML should have everything you need. It currently limits itself to very simple graphics and audio concepts, which makes it easy for beginners to the field to learn using SFML. Another point to consider is that, every now and then, there are some users that request legitimate niche features to be implemented into SFML. We review such requests thoroughly, and if it turns out that the feature would be beneficial to a larger audience it often gets implemented after a while. If you stick to the "mainstream" features you would expect from such a library, you shouldn't miss anything.
Regarding bugs, legitimate bug reports get high priority when it is certain that they persist in the current master revision of SFML. The standard procedure involves providing a minimal self-contained SFML-only code sample that reproduces the bug along with a description of what happens and what should happen instead here on the forum. Often, bug reports end up being false alarms attributed to wrong usage of the library or some other factor that doesn't have to do with SFML itself. If the bug can be verified by multiple people including someone on the SFML team, it is assigned an issue on the GitHub tracker and will be looked into when possible. Most serious bugs with trivial fixes don't last very long, being fixed within a week of the report depending on how much time the team has. Bugs that are hard to reproduce or don't affect that many people are still given an issue on the tracker, but aren't given as high priority as the serious bugs, since they often require non-trivial fixes. All in all, I would say SFML is quite bug-free compared to many other libraries I have seen.
Is SFML ready to go? Sure, I wouldn't discourage anybody from using SFML in a production environment. There are many people who use SFML in more "serious" contexts and are satisfied with it from what I can tell. You can give it a try, and even if you find that it isn't the right library for you, you would not have spent that much effort on it since SFML makes rapid prototyping very easy.
