[Discussion] Usage of SFML

[Noir-]

I want to know: What leads to the decision that SFML is used in this project?

---

Disclaimer: Please don't hate me, questioning things is part of my job and my life philosophy. :x I also cant appreciate enough supers engagement to actually DO something while it seems that he has the exact same vision of the next gen Cultris that I have.

The background: For me it seems like there are not that much games developed in SFML while TGUI seems to be a One-Man-Show at the moment. When I'm looking at the history of the Cultris II project, the used libraries are a important factor which leads to the current state of the project. In particular, some features like multi-byte input support for your Asian friends could not be implemented without a major version change of LWJGL. Apparently this would have broken a lot of code so Simon was not willing to do it. In my opinion this had impact on the user base of Cultris II. This led me to the question how much we can rely on these relatively small projects. Also, couldn't we make our life easier by using a game engine? At this point I realized that I need to know why SFML was chosen. I could imagine that super already thought about such things.

[zDEFz]

At the moment - nothing does justify the size and the amount of libraries we need to use. Would vote for an own (Open GL) Engine. For International communicating we really should have some fitting font / library for it. Whatever we choose - keep it simple and let it be easy to compile cross-platform.

IF we would move away from sfml, tgui would been dumped as well.

Well, that are just my thoughts, correct me if i'm wrong somewhere :)

[kroyee]

One of the reasons I ended up with SFML is that I have worked with SDL before, witch you could call a predecessor if you will. I wanted a 2D-library with full c++ support that has very direct and good OpenGL toolchain. You can even combine SFML with OpenGL directly, let SFML deal with window handling and input events while you do the actual drawing directly with OpenGL.

TGUI is indeed a one-man-show. It is however a competent man who is usually very fast to respond and help with what he can.

Another big factor in this choice is time. The amount of work that would go into writing your own OpenGL Engine is a lot to say the least. Just making a GUI library is a lot of work in itself and as small and simple as TGUI is, there is not much to choose from that works with SFML.

Using a game engine, like Unity for example, could absolutely be an option. I have not really looked into this too much. My reasoning being that it is much more then what is needed, and added complexity is usually very time consuming. It would basically mean to start from scratch. I don't have any experience working with these bigger game engines, so I don't really feel qualified to say if it is a good option or not.

I started this project less then two months ago as a way of getting back into coding, since I've been away from it for almost 10 years. I did not really have too much expectations at that point so I was not thinking very large-scale.

[chinatsu]

I think SFML + TGUI is a decent fit for this project. Primarily for its simplicity, and also for how well the game runs. I feel like any bigger and bolder libraries will come with a bunch of defaults that'll bog it down, and for a relatively simple 2D game, I don't think that a lot more than what we have at the moment is absolutely necessary.

Of course, had it been up to me, I'd choose a different programming language altogether.

[kroyee]

A side note: As far as chinese/alternative character sets go SFML supports this and a translation could be implemented if proper fonts are supplied with the client.

[Noir-]

Thank you very much for your feedback! Very reasonable to me. It seems that the only thing which could be reasonable in the near future is to encapsulate the access to library functions good enough to make a library change possible without heavy modification of all components. But i haven't looked at the architecture of the current game yet. I was busy compiling :laughing:

(...) and for a relatively simple 2D game, (...)

I have to disagree with this :stuck_out_tongue: The requirements to the processing of the user input is absolutely high end. There are not that much games out there which have to process up to 16 (or even more) keystrokes per second without almost no error tolerance. Even if there would be a only 0.1 ‰ chance that input is not processed properly, even average players would start complaining about input lag after a few minutes of playing the game.

[zDEFz]

SFML seems to have various problems

https://github.com/SFML/SFML/issues/7

It's not just tilde that it gets wrong, write a little input echoer program and you'll probably see a lot of incorrectly reported keys. It works for most of the basic letter keys, but other than that has not proven to be very robust when I've used it.

https://www.reddit.com/r/gamedev/comments/44npzz/sdl20_vs_sfml2_in_2016/

At the moment - i can not get a perfect key handling and it does not compare to http://harddrop.com/wiki/NullpoMino or other clones

If it comes to Input - it has to get better somehow... I also saw blitz misdropping and he is using 1 key finesse which virtually should have a perfect finesse.

[kroyee]

The issue you are referring to has nothing to do with detecting if a key is pressed or not, or how accurate that is. It is concerning SFML's ability to detect keys that are not in the "standard" set, like a key that only excist on the keyboards in a cenrtain country for example.

What this comes down to is the ability of the game to measure small time-units. When a key is pressed, the game uses the internal OS-specific system to measure how long time has passed since the key was pressed, and after a specific period sends a "repeat" of that key.

I think it basically comes down to adjusting how it is calculated to get the best result.

EDIT: I just realized maybe you were referring to the chines/alternative keys. SFML has 2 different functions to work with here: sf::Event::KeyPresse/Release (does not recognize all special keys). sf::Event::TextEntered capture any character that was inputed to the system as.

It is 2 different things. You could not bind any key on a chinese keyboard, or even my standard keyboard (some of the odd keys will not interpret correctly and just give you a blank 0 value) You can however still get any character entered in text from any keyboard. Holding shift + clicking 1 gives you a textEnteret event with '!' as value, but at the same time would produce 2 keyPressed events with LSHIFT and 1 as values. Same goes for chinese/anything else. No matter if the keyPressed can get a value, textEntered will always give you the right input.