Thor 2.0 released!

[The Terminator]

You still need _1 as the last argument in std::bind() -- it specifies the thor::ActionContext argument that is forwarded. Furthermore, for member functions you should pass a pointer, not a reference to the object.

std::bind(&SE::SInputManager::onTextEntered, this, _1)

If you struggle at understanding std::bind(), just use lambda expressions.

And have you seen my advice concerning "S" prefixes?

Thanks a lot! Regarding the S prefixes, they are not being used in the same way C prefixes were. In my engine, all code that belongs to it is marked with an S (stands for Shock, my engine is called Shock Engine) prefix to differentiate between engine code and user game code.

[dabbertorres]

I'm not sure what exactly Nexus is referring to concerning prefixes, but, my guess would be that you should look into using namespaces rather than using a prefix, which, is what they're meant to be used for after all. 

For example:

std::bind(&shk::E::InputManager::onTextEntered, this, _1)

That's why SFML uses the 'sf' namespace, to separate framework code from user code (and potentially other engine code), which is what you want to accomplish.

What if someone else made a library for something and prefixed all of their functions with an 'S' as well? You'd have a clash, which never turns out good for the compiler. As namespaces have longer names, the chances of clashing turns out much less.

[Nexus]

Another advantage of namespaces is that you can keep them long and expressive:

namespace ShockEngine
{
    // your library
}

In user code, you can still create aliases, even for nested namespaces:

namespace shk = ShockEngine;
namespace si = ShockEngine::Input;

shk::InputManager mgr;

You can also locally "empty out" the namespace (but never do this in headers):

using namespace ShockEngine;

[The Terminator]

Another advantage of namespaces is that you can keep them long and expressive:

namespace ShockEngine
{
    // your library
}

In user code, you can still create aliases, even for nested namespaces:

namespace shk = ShockEngine;
namespace si = ShockEngine::Input;

shk::InputManager mgr;

You can also locally "empty out" the namespace (but never do this in headers):

using namespace ShockEngine;

I am using namespaces as well. Well known libraries and engines have a prefix similar to mine such as Ogre3D. I am open to new ideas, but I think that the prefix will stay.

[Nexus]

You're full-quoting again

Well known libraries and engines have a prefix similar to mine such as Ogre3D.

Ogre3D uses the Ogre namespace, not a prefix. Most C++ libraries, especially modern ones, do use namespaces. Box2D is famous for using prefixes instead of namespaces; the arguments of the developers however are either very weak or inherently wrong ("it makes porting harder", "you have to type more", "debuggers can't handle them").

I am open to new ideas

Well, you've heard them

I just think you should benefit of C++ features where they bring advantages (and I don't see a real argument for prefixes, to be honest). But of course it's your decision.

[Lo-X]

My two cents are that when I write code, I like it to sounds like real written english (sort of). So when I use a class, its name should be the same that in a sentence. It's also easier to find them again with our auto-completion.

Prefixes tend to break these statements. But of course, that's not a reason not to use the lib. Just a convenience thing.

[FRex]

Box2D is famous for using prefixes instead of namespaces

Qt does use Q prefixes at times, not sure if it uses namespaces, but it's a very backwards compatible library so it's understandable.

Erin Catto also uses argument that he supports compilers that don't support namespaces (?!) and explicitly changed all cxxx includes to xxx.h few months ago (back to C from c++ compatibility ones, probably since they use namespaces, the commit had simply stated the fact, not given a reason), also he uses raw memory blocks instead of new (but that's to also allow plugging in other memory allocators). There is also a bug where copying ChainShape(it's that I think, I'm sure one class does that, might not be ChainShape but I'm fairly sure) would cause double free because only pointer gets copied - violated rule of zero/five/three + manual memory management. It's like ultimate bane of your existence, Nexus.

I don't know what to think about that. It's good physics library but the mentality of 'c++ is actually C' is very weird to me personally, especially since I am one of people who really really love C being nearly subset of c++.

I personally like namespaces, and they help with the fact that code completion starts looking only inside namespace when typing it's name followed by ::. They also make code clear and allow me to see easier which 'module' the functionality is coming from at a glance, :: really separates out the namespace name in monospaced fonts. Netbeans has no problem running GDB and listing these classes, it shows the type of class in namespace correctly as 'namespace::ClassName'.

[FRex]

Is there anything that could be done about Hold using isKeyPressed, like internally keeping bool for each key on your own instead and set/unset them on every keypressed/keyreleased event? I'm not sending any events to action map while input box is up but WASD still moves my character because ActionMap uses isKeyPressed. Using PressOnce with repeating keys makes it so first the character jerks a bit and then it starts moving smoothly(because there is one event, break and then many events for each key).
(As an ad hoc solution I'm not invoking callbacks with map instead of not sending events to map, but could something else be done for that? Also it'd be problem in (unlikely) case that someone wants to record input events and then use them to make demo/recording of game by letting game run using faked events from file instead of player ones).

[Nexus]

An event-based hold mechanism might be an idea for the future. It would also make things like handling only events inside the window easier. But the current realtime-based hold would probably still persist; I guess SFML users expect it to work like SFML's realtime input.

If you need a challenge, you can try to achieve this already now by combining thor::eventAction() and thor::realtimeAction()
(see doc)

[Dante12129]

I have compiled SFML and Thor before, but I am having issues with the latest versions. I got SFML to compile fine, but whenever I try to configure Thor in Cmake, it gives me this message:

Could NOT find SFML (missing:  SFML_AUDIO_LIBRARY SFML_GRAPHICS_LIBRARY SFML_WINDOW_LIBRARY SFML_SYSTEM_LIBRARY)

-> SFML directory not found. Set SFML_ROOT to SFML's top-level path (containing "include" and "lib" directories).
-> Make sure the SFML libraries with the same configuration (Release/Debug, Static/Dynamic) exist.

I have all my SFML stuff in C:/SFML-2.1, and have set the SFML_ROOT in Cmake to there. I have SFML_INCLUDE_DIR set to C:/SFML-2.1/include. I compiled SFML into debug and release dynamic libraries, and have THOR_SHARED_LIBS set to do the same. I am using Windows 7 and TDM GCC 4.8.1.

[Nexus]

So you followed the installation tutorial precisely? Have you edited the existing CMake variables (you should not create new ones)?

Are you sure that same the configuration you're currently trying to build for Thor exists already for SFML (all required files in include, lib and possibly bin directories are in SFML_ROOT)? For example, when you build Dynamic Release, there must be lib/libsfml-system.a and bin/sfml-system.dll.

Since you're mentioning TDM, it might also be related to that compiler, it's known to cause issues because it handles things non-inutitively. See also SFML issue #487... We still have to find a definitive solution. But I wonder why CMake would not even find SFML; I'd rather expect linking problems.

[Svenstaro]

Did you consider adding a general tweening system? I think it would be very helpful on its own and you could also use it internally in some places.

[Nexus]

Not at the moment... What functionality and API would you imagine?

[Svenstaro]

Something simple like this: https://github.com/runemadsen/Tween

It should be really easy to implement. A lot like the ParticleSystem, you'd have a TweeningSystem you add things to and update the TweeningSystem once a tick globally.

[Nexus]

I'm planning to make Thor 2.0 ready for release in the near future, so that I can make this version compatible with SFML 2.2 once it is out.

Most tasks are done, there are a few bugs (related to triangulation and compile errors in Aurora) that I plan to fix. Since Aurora is shipped with Thor, I might also clean it up fundamentally. Are there other crucial things? Note that I won't implement new features for Thor 2.0.

It's also a good opportunity to give again feedback to Thor's API. Do you like it, where do you think it can be improved?