Thor 2.0 released!

[Nexus]

I have again tried to find out the reason of this crash, to no avail so far. Interestingly, the problem only occurs when Thor/SFML are linked dynamically (in either debug or release mode). The application also crashes without the m_callbackSystem.connect() call (I also omitted operator|| and replaced sf::RenderWindow with sf::Window). I haven't been able to further reduce the code:

#include <SFML/Window.hpp>
#include <Thor/Events.hpp>

int main()
{
        sf::Window window(sf::VideoMode(640, 480), "window");
        thor::ActionMap<std::string>::CallbackSystem m_callbackSystem;
        thor::ActionMap<std::string> m_actionsTable(window);

        m_actionsTable["exit"] = thor::Action(sf::Keyboard::Escape, thor::Action::PressOnce);

        while (window.isOpen())
        {
                m_actionsTable.update();
                m_actionsTable.invokeCallbacks(m_callbackSystem);

                window.display();
        }
}

There occurs a heap corruption at the destruction of the result variable in thor::ActionMap::invokeCallbacks(). To be more precise, the operator delete deallocation in std::vector fails.

From my experience, heap corruptions most often occur when something is deleted twice or incorrectly. Since Thor uses zero direct delete operations in its code (everything is encapsulated), this is very improbable. I even changed the thor::Action implementation to use std::unique_ptr instead of aurora::CopiedPtr, just to exclude bugs in my smart pointers. The result remained the same.

As mentioned earlier, I still guess it is a configuration/library issue, furthermore this is enforced by the fact that Thor with dynamically linked runtime runs well. I have checked the verbose linker output and apparently, SFML, Thor and the project use the same runtime DLLs (libcmt.dll and libcmtd.dll, respectively).

So the only thing I could imagine is that there are specific compiler flags that are incompatible to each other. Does SFML change specific VS project properties, except for /MT or /MTd flags? Or maybe CMake? I will also try with a CMake-generated application.

[Laurent]

Does SFML change specific VS project properties, except for /MT or /MTd flags? Or maybe CMake?

I don't think so.

You should check the final executable dependencies, and make sure that there's no VC++ DLL there.

[Nexus]

I will also try with a CMake-generated application.

Didn't work either.

You should check the final executable dependencies, and make sure that there's no VC++ DLL there.

I already did that with Dependency Walker, and the project doesn't link any VC++ DLL directly. However, msvcrt.dll is referenced from various other dynamic libraries, such as OpenGL32.dll.

Multiple runtime versions result in different heaps, maybe allocation and deallocation don't take place in the same one. The relevant code itself is defined in the header, but other operations on result (like a push_back() which needs the allocator) occur in a Thor .cpp file.

In fact that sounds like a reasonable theory, but if I have multiple runtime versions, how can I avoid them? I'm going to compare compiler flags manually now...

The C libraries upon which SFML depends are not an issue?

[Nexus]

Okay, the problem is indeed that both .exe and .dll have their own CRT instance, and thus a separate freestore/heap. This is also why the issue doesn't happen when Thor is linked statically: A static library doesn't have its own CRT, so the final .exe only uses a single runtime environment.

In order to avoid undefined behavior, code that invokes common allocation/deallocation routines (or that accesses other shared global data) must remain inside the same CRT. This implies that corresponding functions must be either defined completely in the .dll or completely in the .exe. Inline functions (and compiler-generated member functions) are a special case, it depends on the compiler whether their binary code is placed into the .dll or the .exe file. Therefore, the only reliable way to avoid mixed CRT access is to define every function in the .cpp file.

This wouldn't be such a huge issue if it didn't include the Big Three (or Big Five in C++11). In Thor, they are almost always compiler-generated, often thanks to aurora::CopiedPtr. I have only two classes that define a copy constructor, one of them is internal and the other is never used

Alas, the only way to fix this consists of writing masses of boilerplate-code. This is not only a pain, but is likely to introduce bugs and places an additional maintenance burden. I will not do this for the sake of a configuration that is almost never used. Note that even if I fixed everything, SFML would still have the same problem.

In conclusion, I am going to forbid the combination of static CRT linkage and dynamic Thor linkage. I believe this decision is reasonable, considering that people who link CRT statically usually do it because they want to have everything in the .exe, so they can as well link Thor statically.

[Nexus]

It is time to announce again something interesting, after many boring updates of bugs with specific configurations.

I have implemented an idea the user gavintlgold gave me a long time ago, namely to combine animations and particle affectors. And thor::FrameAnimation is no more alone! What has changed:

• Added the new animation classes ColorAnimation and FadeAnimation.
  
• Added a class AnimationAffector which takes an animation and applies it to particles.
  
• Removed FadeInAffector, FadeOutAffector and ColorAffector, they are redundant.

This effectively allows users to write an animation which animates sprites, texts, particles and other interface-conforming classes. Since thor::Particle and sf::Sprite have completely different APIs, I provide basic adapter functions in Graphics/UniformAccess.hpp (there are more to come).

I don't know whether the Animation and Particles modules are going to remain unchanged until the Thor 2.0 release. I have already considered std::function for particle emitters and affectors. To define a new affector or emitter, one could take a simple function or lambda expression, no class hierarchy is required.
Usage is also simpler because affectors and emitters have value semantics.

On the downside, I lose shared ownerhip semantics, which has some drawbacks:

• Performance: In fact, this is already a problem at animations. Currently, every thor::Animator copies all the referenced animations, even if animators differ only in the animation progress. This can become a speed and memory issue for application fields like tilemaps.
  
• Reference semantics: Changing an animation afterwards doesn't affect the places where it is already in use.
• Type erasure: It is not meaningfully possible to extract the original functor or function from std::function. Therefore, finding, removal in and iteration through containers of animations is difficult.

Maybe there is a way to combine the advantages from both worlds, something towards std::ref(). In case I should come across a solution, it is probable that affectors and animations are even further unified.

[thePyro_13]

So I've been hooking as much of my game up with thor::Action as possible over the past few days and have run into an issue.

When subscribing joystick buttons, we provide the joystick ID and the button. However, the joystick axis movement seems like it can only be subscribed with the JoyMoved Event. I had hoped that I'd be able to subscribe specific axis from specific joysticks, but this doesn't appear to be possible with the current thor::Action API.

This isn't a problem with MouseMove events, as their can only be one logical mouse cursor, but that isn't the case with joysticks and their axis.

Is a more specific subscription available for joystick axis? Or does Thor not currently provide anything like this?

[Nexus]

Thanks for your feedback

At the moment, you can only create an action associated with joystick axis as follows:

thor::Action action(sf::Event::JoystickMoved);

If you use callbacks, you can then react in this way:

void callback(thor::ActionContext<X> context)
{
    sf::Event::JoystickMoveEvent = context.event->joystickMove;
    // do something
}

It is not possible to connect a specific axis and joystick ID directly to a callback, but it would be a good idea. Some parts of the Thor.Events module can be improved, for example a similar action for mouse wheels would be appropriate. If you have further ideas or reports, for example whether the callback system is easy enough to use, don't hesitate to tell me! Just note that I probably won't have time to implement a lot in the next few weeks.

[Tank]

Long time no news from Thor!

I've always stated that I want to give Thor a try, and the time finally came: I'm doing a neat little 2D game for getting back into C++ after weeks full of annoying must-do work in other crappy languages.

Just wanted to say thanks for a nice library. It makes a lot of things much easier and game creation more fun. Here's a little demo of what I'm using it for (for now at least ):

[Nexus]

Cool demo! What parts of Thor have you used? I assume the clouds have been created with the particle system?

In about a month, I should again have more time to work on Thor. I already have some important changes in mind

[FRex]

Could you please add default constructor to ActionMap and let me connect the window later/just use pushing?

[Tank]

Exactly, the particle module and the distribution stuff from the math module.

[Nexus]

Could you please add default constructor to ActionMap and let me connect the window later/just use pushing?

The problem is, you pay a high price for some convenience of default constructors: You take invalid objects into account. A thor::ActionMap without a window is not fully functional. Its update() can't poll the events, and thor::ActionContext in the callbacks can't be initialized correctly. I am sure that people would run into runtime errors (update() failing, or dereferencing null pointers), while at the moment I provide compile-time safety.

May I ask why you can't initialize the ActionMap only when you have a window available? To convince me, I always need use cases

[FRex]

May I ask why you can't initialize the ActionMap only when you have a window available?

Because I was using it as a member, now I have member std::unique_ptr to it instead and init it later with a method. Also, the pain of cascading init lists:

I have a game class that has in it a controller class that has action map in it. If I have to pass a window to there, I'd have to pass the reference to game class constructor(which I didn't write because every member is smart enough to have default constructors), then pass it to controller constructor(which I'd have to write too) in the init list, then in the controller init list I need to pass it to action map. That's a lot of work for tiny action map class.

[Nexus]

That's a lot of work for tiny action map class.

True, but only very simple classes don't need a constructor. As soon as you have scalar members or perform an actual initialization, the constructor needs to be there. At least if you want the object to be completely operational after the constructor call, and don't rely on other methods to be invoked.

Anyway, I have an idea for a potential solution: Making the sf::Window no longer a part of thor::ActionMap's state. If the window is only used to poll events, one possibility comprises that the window is passed to ActionMap::update(), and the ActionContext::window member variable is removed. Then I might get around the invalid object issue. I have to investigate this...

[Nexus]

As planned in my previous post, I decoupled the window from the object state. ActionMap can now be used as follows. Thanks for the feedback, FRex.

thor::ActionMap<...> map;
...

map.update(window);
map.invokeCallbacks(callbackSystem, &window);

Furthermore, I renamed the Events module to Input. This is more general, the name "Events" comes from the beginnings of Thor where only functionality for SFML events was provided. Now the module covers also real-time input and conversions from and to SFML's enums (like sf::Mouse::Left).

I updated the Action tutorial and the online documentation correspondingly.