Thor C++ Library – An SFML extension

[Laurent]

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.

Does this really need a class? Obviously, it won't require Start/Stop/Reset methods, so basically a simple variable can do the job.

Code: [Select]

float accumulatedTime = 0;

while (running)
{
    if (!paused)
        accumulatedTime += elapsedTime;
}
And it doesn't solve the problem, it's just shifted to the calculation of elapsedTime.

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.

I think that using a timing function that calculates the CPU time rather than the real time would be enough. According to the OgreTimer implementation that I saw this morning, std::clock() behaves likes this.

[Nexus]

Does this really need a class?

Not necessarily, but with its encapsulation it provides protection against accidental modifications, and it allows convenient methods to set/get different time units. Plus, code gets more expressive with meaningful method names.

And it doesn't solve the problem, it's just shifted to the calculation of elapsedTime.

This is true. Does sf::RenderWindow::GetFrameTime() use sf::Clock internally? In this case, how can one get the "real" frame time (e.g. without the time the window is moved/resized, or the computer is in standby mode)?

According to the OgreTimer implementation that I saw this morning, std::clock() behaves likes this.

The problem with the standard clocks is that they're unprecise (or at least, the standard doesn't require high resolution). Maybe, Boost.DateTime is an alternative. But I don't like its complexity...

[Laurent]

Does sf::RenderWindow::GetFrameTime() use sf::Clock internally?

Yes.

In this case, how can one get the "real" frame time (e.g. without the time the window is moved/resized, or the computer is in standby mode)?

You can't. I don't think that you can magically skip these things, you have to detect and handle them one by one.

[Nexus]

Okay. For a workaround, one can also cheat and set an upper limit for the frame time. This could also be handled automatically by a class.

Maybe one class is enough, something like thor::ManualClock with a basic sf::Clock-like interface. The ultimative flexibility could be achived by making thor::StopWatch and thor::Timer templates and by letting them choose the underlying clock. But this becomes too complicated very fast.

[Ceylo]

The problem with the standard clocks is that they're unprecise (or at least, the standard doesn't require high resolution).

Could you tell more about this? Why do you say it's not precise?

[Nexus]

The precision of std::clock() depends on CLOCKS_PER_SEC, which is usually about 1000, so one can't measure less than one millisecond. It may be good for many use cases, but standard clocks don't offer high-resolution measuring like sf::Clock does.

I have also come across Boost.Chrono, it looks more suitable for time measuring than Boost.DateTime. And, it is part of the C++11 standard, in the header <chrono>

[Haikarainen]

I found a problem.

Was setting up my development environment on my new laptop, downloaded latest SFML2, CMake, SVN and Thor1.1, and after setting up SFML successfully and creating cbp-files to build thor, I get compiler errors.

You're trying to include

Code: [Select]

#include <SFML/Graphics/Transformable.hpp>
#include <SFML/Graphics/ConvexShape.hpp>

probably others as well, these files aren't present on the lastest git of SFML.

Is this known? Should I D/L 1.0 instead?


Thanks

[Laurent]

You need the 'drawables' branch of SFML 2, not the master one.

[Ceylo]

The precision of std::clock() depends on CLOCKS_PER_SEC, which is usually about 1000, so one can't measure less than one millisecond. It may be good for many use cases, but standard clocks don't offer high-resolution measuring like sf::Clock does.

Well.. we'd need to check the value for the other OSs but starting from Mac OS X 10.5 CLOCKS_PER_SEC is defined as 1000000. Thus you can measure up to one microsecond.

I have also come across Boost.Chrono, it looks more suitable for time measuring than Boost.DateTime. And, it is part of the C++11 standard, in the header <chrono>

Boost.Chrono.. humm.. I'll have a look at it. Thanks

[flackez]

Hello

I try to compile thor from svn (r71) with latest sfml from git on archlinux x64 and got this error...

Code: [Select]

Found SFML: /usr/local/include
-- SFML and OpenGL found.
-- Configuring done
-- Generating done
-- Build files have been written to: /local/buildpkg/sfml-thor/src/trunk
[  3%] Building CXX object src/CMakeFiles/thor.dir/Arrow.cpp.o
In file included from /local/buildpkg/sfml-thor/src/trunk/src/Arrow.cpp:26:0:
/local/buildpkg/sfml-thor/src/trunk/include/Thor/Multimedia/Arrow.hpp:35:43: fatal error: SFML/Graphics/Transformable.hpp: No such file or directory
compilation terminated.
make[2]: *** [src/CMakeFiles/thor.dir/Arrow.cpp.o] Error 1
make[1]: *** [src/CMakeFiles/thor.dir/all] Error 2
make: *** [all] Error 2
==> ERROR: A failure occurred in build().
    Aborting...

it seem like no file Transformable.hpp anymore in latest sfml build.  

edit: how i miss that above post lol :shock:

[Laurent]

The answer is three posts above...

[excrulon]

I can't get cmake working with this. I read previous posts in the first few pages of this thread but it didn't help. Also read the tutorial on your site. I've installed SFML, and it's in c:\program files\sfml and my FindSFML.cmake is in C:\Program Files\SFML\cmake\Modules. CMake has two similar variables to set -- SFMLDIR and SFML_DIR. SFML_DIR keeps getting reset to have the value of SFML_DIR-NOTFOUND but SFMLDIR doesn't. I just checked out the latest version of thor from trunk. I get this error no matter what I do:

CMake Warning at CMakeLists.txt:86 (find_package):
  Could not find module FindSFML.cmake or a configuration file for package
  SFML.

  Adjust CMAKE_MODULE_PATH to find FindSFML.cmake or set SFML_DIR to the
  directory containing a CMake configuration file for SFML.  The file will
  have one of the following names:

    SFMLConfig.cmake
    sfml-config.cmake



CMake Error at CMakeLists.txt:92 (message):
  SFML directory not found.  Set SFMLDIR to SFML's top-level path (containing
  "include" and "lib" directories).

[Laurent]

You must either copy FindSFML.cmake to <CMake install>/share/cmake-2.8/Modules, or set CMAKE_MODULE_PATH to "C:\Program Files\SFML\cmake\Modules".

[Nexus]

On the future of Thor

As Laurent announced to change SFML's naming convention, I have to decide how to continue with Thor. Since Thor and SFML have a similar API (some SFML classes are inherited by Thor or have the same member functions) and the former is officially an extension of the latter, it is standing to reason that I need to adapt the new convention.

I want to exploit this opportunity to improve the general API in Thor and to break some other interfaces. Ideas I have had so far:

• Simplification of the whole smart pointer module
• MovedPtr is doomed. I remove this class template, because it is an error-prone and inefficient workaround to emulate move semantics in C++98.
• CopiedPtr becomes smarter and more flexible: I plan to add support for separate cloner/deleter functors (instead of the compile-time policies) and derived-to-base conversions.
• ScopedPtr is either removed or changed to a CopiedPtr, but without cloner functors in order to remain noncopyable.
• Resources and ownership
• Replace thor::ResourcePtr with std::tr1::shared_ptr. Currently it is only a wrapper anyway, the change to shared_ptr allows people to work with standard library classes and to reduces dependencies.
• I must decide how classes depending on resources hold them. There are two extremes: Simple pointers and reliance on the user to keep resources alive, or overall reference counting with shared_ptr. Involved resource customers are ParticleSystem, FrameAnimation, BigSprite.
• General reorganization
• Rename some classes with too general names or move them in a separate namespace. I'm thinking of Vertex (specific to triangulation), Connection (specific to events) and maybe the Geometry classes. This preserves the ability to introduce new classes (for example for network connections) without API breaks.
• Reorder modules. I'm not completely happy with Geometry, Multimedia and Math; their application fields are blurry. I have no clue yet, ideas are welcome!
• I have even considered to split parts of the Tools module, which are not directly connected to multimedia programming, into a separate library. This concerns smart pointers, dynamic dispatchers, the NonCopyable base class and foreach macros. Doing so would render this functionality more interesting for people that don't use SFML. It would still be used by Thor.
• Possibly C++11 features (optional or unconditional). Implementation as well as usage gets easier and more efficient. Rvalue references for the smart pointers are a popular example.

Please tell me what you think about those points. I'm also open to other suggestions regarding the API. What do you find unintuitive? Are there things you consider unnecessary/useless? Don't hesitate to post your opinions, unfortunately I recently receive only few feedback from the people using Thor. I'm happy about all inputs, even if you yourself don't use my library.

Concerning the addition of new features, I will wait until a stable code base is established. If you have ideas, please still mention them, this allows me to plan more exactly and to make future integration easier.

Perhaps I am going to release a version 1.1 with the current API, if there are people wishing it.

[N1ghtly]

Does the the latest Thor version work with the latest Git snapshot yet?