Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Thor 2.0 released!  (Read 354219 times)

0 Members and 1 Guest are viewing this topic.

The Terminator

  • Full Member
  • ***
  • Posts: 224
  • Windows and Mac C++ Developer
    • View Profile
Re: Thor 2.0
« Reply #315 on: January 31, 2014, 03:54:28 am »
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.
Current Projects:
Technoport

dabbertorres

  • Hero Member
  • *****
  • Posts: 506
    • View Profile
    • website/blog
Re: Thor 2.0
« Reply #316 on: January 31, 2014, 05:40:43 am »
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

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
Re: Thor 2.0
« Reply #317 on: January 31, 2014, 10:23:58 am »
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;
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

The Terminator

  • Full Member
  • ***
  • Posts: 224
  • Windows and Mac C++ Developer
    • View Profile
Thor 2.0
« Reply #318 on: January 31, 2014, 01:44:26 pm »

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.
Current Projects:
Technoport

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
Re: Thor 2.0
« Reply #319 on: January 31, 2014, 01:59:29 pm »
You're full-quoting again :P

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.
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Lo-X

  • Hero Member
  • *****
  • Posts: 618
    • View Profile
    • My personal website, with CV, portfolio and projects
Re: Thor 2.0
« Reply #320 on: January 31, 2014, 02:17:41 pm »
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

  • Hero Member
  • *****
  • Posts: 1848
  • Back to C++ gamedev with SFML in May 2023
    • View Profile
    • Email
Re: Thor 2.0
« Reply #321 on: January 31, 2014, 02:58:50 pm »
Quote
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'.
Back to C++ gamedev with SFML in May 2023

FRex

  • Hero Member
  • *****
  • Posts: 1848
  • Back to C++ gamedev with SFML in May 2023
    • View Profile
    • Email
Re: Thor 2.0
« Reply #322 on: February 05, 2014, 10:37:28 pm »
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).
« Last Edit: February 05, 2014, 10:41:29 pm by FRex »
Back to C++ gamedev with SFML in May 2023

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
Re: Thor 2.0
« Reply #323 on: February 05, 2014, 10:56:24 pm »
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() :P
(see doc)
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Dante12129

  • Newbie
  • *
  • Posts: 24
    • View Profile
Re: Thor 2.0
« Reply #324 on: February 23, 2014, 07:16:15 am »
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

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
Re: Thor 2.0
« Reply #325 on: February 23, 2014, 12:14:43 pm »
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.
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Svenstaro

  • Full Member
  • ***
  • Posts: 222
    • View Profile
Re: Thor 2.0
« Reply #326 on: February 27, 2014, 01:01:56 pm »
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

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
Re: Thor 2.0
« Reply #327 on: February 27, 2014, 01:10:19 pm »
Not at the moment... What functionality and API would you imagine?
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Svenstaro

  • Full Member
  • ***
  • Posts: 222
    • View Profile
Re: Thor 2.0
« Reply #328 on: February 27, 2014, 01:22:13 pm »
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

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
Re: Thor 2.0
« Reply #329 on: April 02, 2014, 01:00:56 pm »
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?
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development: