Thor 2.0 released!

[Hiura]

Hey Nexus, I've spotted an issue with unsigned int/size_t being mixed in header and source files with the current master.

Here's a quick patch that makes sure the declaration and implementation signatures match (I chose to keep unsigned int but that was totally arbitrary):

diff --git a/src/Emitters.cpp b/src/Emitters.cpp
index 6af1b27..1887689 100644
--- a/src/Emitters.cpp
+++ b/src/Emitters.cpp
@@ -105,12 +105,12 @@ void UniversalEmitter::setParticleColor(Distribution<sf::Color> particleColor)
        mParticleColor = std::move(particleColor);
 }
 
-void UniversalEmitter::setParticleTextureIndex(Distribution<std::size_t> particleTextureIndex)
+void UniversalEmitter::setParticleTextureIndex(Distribution<unsigned int> particleTextureIndex)
 {
        mParticleTextureIndex = std::move(particleTextureIndex);
 }
 
-std::size_t UniversalEmitter::computeParticleCount(sf::Time dt)
+unsigned int UniversalEmitter::computeParticleCount(sf::Time dt)
 {
        // We want to fulfill the desired particle rate as exact as possible. Since the amount of emitted particles per frame is
        // integral, we have to emit sometimes more and sometimes less. mParticleDifference takes care of the deviation each frame.
diff --git a/src/ParticleSystem.cpp b/src/ParticleSystem.cpp
index 4cb024c..5a61c5d 100644
--- a/src/ParticleSystem.cpp
+++ b/src/ParticleSystem.cpp
@@ -112,7 +112,7 @@ void ParticleSystem::setTexture(const sf::Texture& texture)
        mNeedsQuadUpdate = true;
 }
 
-std::size_t ParticleSystem::addTextureRect(const sf::IntRect& textureRect)
+unsigned int ParticleSystem::addTextureRect(const sf::IntRect& textureRect)
 {
        mTextureRects.push_back(textureRect);
        mNeedsQuadUpdate = true;

[Nexus]

Thanks! I fixed that.

Did you test on OS X? If so, are there other configuration issues or compiler warnings/errors on that platform?

[Hiura]

Actually it was on Ubuntu 15.04 x86_64 with clang 3.6 & libc++ 3.6 (so it should be very similar to OS X). Once my mac is repaired I will test it. 

But that was the only error I got. I didn't add any specific warning flags though. If you want me to build it with some additional warning flag let me know.

[Nexus]

I can eventually test Ubuntu, just not after every single commit

But I'd be really glad about feedback from OS X... Also regarding compiler warnings. Important are those that occur when compiling Thor (without changing flags) as well as when using it (with -Wall and possibly others). But having a look at the SDK examples is more than enough, I'd truly appreciate that

Do you have a rough estimate when your Mac is repaired? I'm asking because I've been planning to release Thor 2.0 for some time already of course, if there's anybody else with OS X, that would be very nice, too!

[Hiura]

I'll try to remember to test it when I get my mac back but it might take a while; they told me it can stay in shop for about a month but I'll also need to reinstall everything when I get it back because when I gave it to them the HDD got corrupted.. like having some battery issue wasn't enough. ^^'

Additionally, I just started a new job so I don't know how much time I'll have during this summer. So it's probably safer not to delay Thor 2.0 just for my feedback.

Anyhow, if someone else's got a mac close by, it's really easy to set it up and test it so you should do it! 

[Nexus]

Don't worry... If needed I can still adapt things after Thor 2.0. I think I'll focus on that release for the next time

[Foaly]

Hello there!

I don't know if this is the right thread for this, but I have a problem compiling Thor.
I have pulled the lasted github version, configured cmake to point to SFML (2.3.0) and then generated two seperate debug and release projects (codeblocks).
When I open the debug project, compile and install it everything works as intended. But when I try to compile the release project, I get the following compile error:

Code: [Select]

cd /d F:\Librarys\Thor\Build\Release\src && C:\MinGW\bin\g++.exe   -DTHOR_EXPORTS -Dthor_EXPORTS -std=c++0x -O3 -DNDEBUG @CMakeFiles/thor.dir/includes_CXX.rsp   -o CMakeFiles\thor.dir\Action.cpp.obj -c F:\Librarys\Thor\Thor\src\Action.cpp
In file included from c:\mingw\lib\gcc\mingw32\4.8.1\include\c++\cmath:44:0,
                 from c:\mingw\lib\gcc\mingw32\4.8.1\include\c++\random:38,
                 from c:\mingw\lib\gcc\mingw32\4.8.1\include\c++\bits\stl_algo.h:65,
                 from c:\mingw\lib\gcc\mingw32\4.8.1\include\c++\algorithm:62,
                 from F:/Librarys/official_SFML/install/include/SFML/System/Utf.hpp:32,
                 from F:/Librarys/official_SFML/install/include/SFML/System/String.hpp:32,
                 from F:/Librarys/official_SFML/install/include/SFML/Window/Joystick.hpp:32,
                 from F:/Librarys/Thor/Thor/include/Thor/Input/Joystick.hpp:34,
                 from F:/Librarys/Thor/Thor/include/Thor/Input/Detail/ActionOperations.hpp:29,
                 from F:/Librarys/Thor/Thor/include/Thor/Input/Action.hpp:32,
                 from F:\Librarys\Thor\Thor\src\Action.cpp:26:
c:\mingw\include\math.h: In function 'float hypotf(float, float)':
c:\mingw\include\math.h:635:30: error: '_hypot' was not declared in this scope
 { return (float)(_hypot (x, y)); }
                              ^

According to this SO its a MinGW compiler bug (I am using gcc 4.8.1 on windows). I fixed it like the first answer sugessted, but I was wondering, why is Thor using the flag -std=c++0x and not -std=c++11 ? It doesn't make a difference in this case, but I just noticed that. (also I wanted to show other people a solution, who might run into the same problem)

[eXpl0it3r]

The simple solution to your problem is to upgrade GCC. If a software has a bug that's preventing your from working on things and there's a newer version of said software released, it's better to upgrade than to work around the bug.

I assume Thor uses -std=c++0x to be compatible with older compilers which do not have the -std=c++11 flag.

[Nexus]

Code: [Select]

... C:\MinGW\bin\g++.exe   -DTHOR_EXPORTS -Dthor_EXPORTS -std=c++0x ...

Why are you defining those export macros, of which one is even wrong? They're not documented for a reason, CMake and Config.hpp take care of everything.

I was wondering, why is Thor using the flag -std=c++0x and not -std=c++11?

Early C++11 compilers did not recognize -std=c++11.

[eXpl0it3r]

Why are you defining those export macros, of which one is even wrong? They're not documented for a reason, CMake and Config.hpp take care of everything.

I doubt that he wrote these commands. This is one of the command generated by CMake.

[Nexus]

In that case, I don't remember giving CMake the instruction of defining thor_EXPORTS, there's only THOR_EXPORTS.

Is that another one of these implicit CMake "features"?

[eXpl0it3r]

I just mark it as "CMake magic" and forget about it. You'd hope that CMake generates clean make and project files, but truth be told, the generated build files are messy and not really "reusable". It's fine if you just want to build and forget, but if you want to see what's going on, you better buckle up.

[dabbertorres]

its a MinGW compiler bug (I am using gcc 4.8.1 on windows)

I recommend upgrading too. I like this distro. It's not ancient (it's gcc 5.1.0, which has support for almost all of C++11 and 14) (*cough* "official" mingw and mingw-64 *cough*), doesn't have any odd quirks (*cough* TDM *cough*), and it's much more... friendly to Unix users (no weird "gotchas" of being on Windows), in my experience.

[Jesper Juhl]

This is where I just can't help myself and have to mention SCons 
Yeah, CMake does work and solves a problem, but its internals are nasty and their own custom scripting language just makes me go "yuck". SCons is so much nicer and uses a sane scripting language (Python) rather than inventing their own.. Check it out; you'll be glad you did

[Nexus]

I plan to release Thor 2.0 in the next days, so if you still see serious issues with the latest commit, you should tell me now

Feedback/testing is of course highly appreciated!