Thor C++ Library – An SFML extension

[Haikarainen]

Because it may be very useful for user-defined controls, I implemented string conversion functions for sf::Keyboard::Key and sf::Mouse::Button enumerators. Both directions (from and to string) are provided.

Huh, thats pretty nice. How do you do it? Hardcoded strings or are they configurable using the api (as in not changing the api)?

Something tells me that thor will sometime be grown into something close to a game engine

[Nexus]

Huh, thats pretty nice. How do you do it? Hardcoded strings or are they configurable using the api (as in not changing the api)?

Since C++ offers no possibility to get all constants of an enum, each enumerator is hardcoded. I tried to reduce boilerplate code to a minimum and have a static assertion in case Laurent suddenly adds new keys

If you mean whether a string associated with an enumerator can be configured by the user, this is not the case yet. But it sounds like a good idea. However there is the possibility that a key is mapped to different strings during runtime, if one is not careful enough...

Something tells me that thor will sometime be grown into something close to a game engine

Depends on what you understand by game engine. I see it like some sort of rigid framework that offers functionality for almost every part of a game and where the single parts often depend on each other. With Thor, I try to keep them more or less independent, and to cover mainly frequently-used functionality. Thus, one can only use the modules that are needed, without aligning the whole application towards the library design.

However, the Resource module tends to increase coupling. For example, the Particles and Animation module depend on it since they use ResourcePtr. Maybe I switch to the standard shared_ptr... This just as a sidenote. I'm always open for design discussions, just post what you think!

[Haikarainen]

Since C++ offers no possibility to get all constants of an enum, each enumerator is hardcoded. I tried to reduce boilerplate code to a minimum and have a static assertion in case Laurent suddenly adds new keys

Allright, I myself is currently on work on a keymanager for my game. It includes classes; nn::KeyManager, nn::Key, nn::Action and nn::Binding.

nn::KeyManager hold all keys, actions and binding.

nn::Key holds a sf::KeyCode~, a name and a displayname, and functions to get if the key was pressed, released, the current state etc.

nn::Action holds a displayname and a commandname.

nn::Binding holds a pointer to a nn::Key and a nn::Action.

The (command)name in both action and key is the "identifier", what to type in console to bind them togheter(for example "bind leftctrl jump"), commandname also has to be a valid command for the engine (a la quake).
And the DisplayName for both is what to show to the user(especially under the keybinding options in menu).

Just thought I'd share in case you wanna bind your key-management with your custom eventhandling thingy  

Depends on what you understand by game engine. I see it like some sort of rigid framework that offers functionality for almost every part of a game and where the single parts often depend on each other. With Thor, I try to keep them more or less independent, and to cover mainly frequently-used functionality. Thus, one can only use the modules that are needed, without aligning the whole application towards the library design.

However, the Resource module tends to increase coupling. For example, the Particles and Animation module depend on it since they use ResourcePtr. Maybe I switch to the standard shared_ptr... This just as a sidenote. I'm always open for design discussions, just post what you think!

Class independence is a great thing for such a library, And I totally agree on keeping it as a framework rather than an engine, lets just call it a really flexible game api-extension to SFML

Regarding the Particles, im not sure how things work anymore since I dont use them after my SFML2-post-texture-port (never got the time to look up the changes heh), but it sure would be nice if you didnt bind the particles to your resourcemanagement, since Im looking forward to implement particles in my game again, and I allready have my own resourcemanager wich have to load files from my custom packaging format etc. Remember that you could just bind a sf::Image(when it was current) to a particlemanager, isnt that the case anymore(but for sf::Texture) ?

[Nexus]

Just thought I'd share in case you wanna bind your key-management with your custom eventhandling thingy  

Thank you. I have already received requests to serialize thor::Action (which supports arbitrary events, realtime inputs and their logical combinations), but I will probably not do this in near future, because it involves parsers and/or serialize frameworks, it would be quite specific and I don't know how many people would even find it useful. The new functions in InputNames.hpp provide a possibility to perform such a task on user side.

Remember that you could just bind a sf::Image(when it was current) to a particlemanager, isnt that the case anymore(but for sf::Texture) ?

Yes, see here. There is still the possibility to copy whole sf::Image objects or parts of them. Additionally, there is a constructor from a shared sf::Texture object (using thor::ResourcePtr, here I could use shared_ptr). I don't know whether the constructors taking sf::Image will last forever, they're more a interim solution for the SFML API change. And one can have the same functionality with the sf::Texture constructors only, by creating a texture and calling sf::Texture::LoadFromImage() first. What do you think will be a common/simple way of specifying the particle texture?

The dependency on the Resources module is not too big however, since you can put anything into a ResourcePtr (like shared_ptr), so resources needn't be loaded by my manager. What bothers me more is the fact that I sometimes use shared_ptr (to carry the abstract Emitter, Affector, Animation classes) and sometimes ResourcePtr (for SFML resource classes), although both could be used interchangeably at the moment. In fact, ResourcePtr is only a thin wrapper around shared_ptr. I can still add new features to ResourcePtr one day, that's the main reason why I haven't used shared_ptr everywhere

[Silvah]

Just a little question: do you really want to copy the map and the key in src/InputNames.cpp, line 40?

Code: [Select]

 typename M::mapped_type GetMapped(M map, typename M::key_type key)
  //                                ^      ^^^^^^^^^^^^^^^^^^^^
Also, could you consider increasing the precision of pi in Math/Trigonometry.hpp to make the computations depending on it slightly more, well, precise?

[Nexus]

Just a little question: do you really want to copy the map and the key in src/InputNames.cpp, line 40?

No, of course not. Thanks a lot for the hint!

There are also other optimizations possible, I could even use std::vector instead of std::map in one direction. But I'm not sure if the enumerator values will remain subsequent, in SFML 1.6 they were not.

Also, could you consider increasing the precision of pi in Math/Trigonometry.hpp to make the computations depending on it slightly more, well, precise?

I can increase the literal lengths in thor::TrigonometricTraits<T>::Pi(), but I don't know whether the float version (which is equal to thor::Pi) is affected by it...

[Silvah]

I can increase the literal lengths in thor::TrigonometricTraits<T>::Pi(), but I don't know whether the float version (which is equal to thor::Pi) is affected by it...

So just increase the lengths and let the compiler worry about the most precise representation. It may not affect float version, but certainly will affect double and long double versions.

[Nexus]

Okay, the Pi precision has been extended and the InputNames performance has been improved.

Other tasks:

• Add possibility to customize strings associated to keys/mouse buttons, i.e. void SetInputName(sf::Keyboard::Key, const std::string&). Or maybe a better name like SetKeyString?
  
• ParticleSystem: Remove the sf::Image constructors and instead provide another sf::Texture constructor with only a sub-rect.
• Animation extension, although I'm still not sure how exactly.
• Maybe in the long term a reduction of dependencies by the use of std::tr1::shared_ptr instead of thor::ResourcePtr.

Ideas and suggestions concerning one or more of those points are welcome!

[gsaurus]

I still didn't get why the association of strings to keys feature. Can you give an example where it's important?

[Nexus]

You mean the way back? It is useful to serialize data. For example, a user can store key controls in a text document, and parse them when reading the file.

He could also convert the enumerators to integers and vice versa, but this has some disadvantages: The text document is full of magic numbers, making manual read/write access complicated. And if Laurent changes the enumerator values one day, the integer mapping will be broken. On the other side, these are also reasons against SetInputName() functions -- I cannot guarantee a bijective mapping anymore, if the user specifies his own strings.

Or do you think converting strings to keys/mouse buttons is rather unnecessary?

[gsaurus]

I think it's unnecessary as it's just for serialization purposes.
I think that SFML keys should change anyway, the enum keys could refer to ASCII values for example.

[Nexus]

I think it's unnecessary as it's just for serialization purposes.

The functionality can also be used to display key names on screen (again for dynamic controls), serialization is just one example. But wouldn't serialization alone be reason enough? It seems unnecessary that everybody who isn't satisfied with the integer conversion needs to reinvent the wheel.

I think that SFML keys should change anyway, the enum keys could refer to ASCII values for example.

They did in SFML 1.6, but probably not many people made use of it. And other than alphanumeric keys would still have more or less arbitrary values, so you don't get a human-readable description for them. Apart from that, a consecutive implementation also allows simpler and faster treatment (e.g. one can iterate through the enumerators).

[N1ghtly]

This library is bawz
Keep it up, Nexus!

[Ceylo]

I was wondering whether Thor had some support for a clock class that would be able to correctly handle the OS standby mode. From what I saw, it hasn't.

I mean, currently sf::Clock just computes the difference between the current time and the start time. If your computer goes to standby mode, your app logic and drawing is paused, but the clock goes on. When waking up, there'll be a huge "frame time". I'd like to know if it's possible to handle this correctly, maybe with a class that get the OS ticks rather than real elapsed time.

Thanks,
Ceylo

[Nexus]

I have already thought about some kind of "manual" clock. That is, two classes like thor::StopWatch and thor::Timer, but instead of basing on sf::Clock, they have an Update(float dt) function and accumulate a member variable. The advantage is better interaction with game logics, for example one doesn't have to stop/restart timers every time a game is paused. It can be updated along with all other game elements that need frametime updates. If no game logic is computed, time stands still -- also in standby mode.

But I would like to unify both approaches somehow, I'm not sure whether it would confuse users if I provided two versions of each class. Some ideas?