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

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

0 Members and 10 Guests are viewing this topic.

NaCl

  • Newbie
  • *
  • Posts: 18
    • View Profile
Re: Thor 2.0
« Reply #210 on: June 19, 2013, 02:12:26 pm »
Yes and yes.
/MDd was already enabled, in every project.  :-\

Salt

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6287
  • Thor Developer
    • View Profile
    • Bromeon
Re: Thor 2.0
« Reply #211 on: June 19, 2013, 07:50:54 pm »
Are you absolutely sure that all three of SFML, Thor and your project use the same CRT configuration, and you link the correct libraries? That is, you don't link Thor in static debug and SFML in release (or dynamic) mode? I ask because these two lines
Quote
1>LINK : warning LNK4098: defaultlib 'MSVCRTD' conflicts with use of other libs; use /NODEFAULTLIB:library
1>LINK : warning LNK4098: defaultlib 'LIBCMTD' conflicts with use of other libs; use /NODEFAULTLIB:library
indicate that two CRT configurations are mixed, namely /MTd and /MDd. Check my previous link.

If this is not the case, rebuild all three projects, after cleaning up their CMake build folders and cache completely. Sometimes there are options which are not correctly applied if you change them later on.

Do not enable either SFML_USE_STATIC_STD_LIBS or THOR_STATIC_STD_LIBS.
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

NaCl

  • Newbie
  • *
  • Posts: 18
    • View Profile
Re: Thor 2.0
« Reply #212 on: June 19, 2013, 08:45:31 pm »
It works now, thanks.
I reinstalled VS and recompiled SFML + Thor directly after a new download.
Thanks

Salt

tyrion

  • Newbie
  • *
  • Posts: 6
    • View Profile
Re: Thor 2.0
« Reply #213 on: July 07, 2013, 04:06:52 pm »
Hi,

how do i get the actions back from the map list?

e.g.
map[Run] = (Action(XE::IPT::Keyboard::LShift) || Action(XE::IPT::Keyboard::RShift)) && Action(XE::IPT::Keyboard::R);

How do i get LShit ... RShift .. R back?

Thx!  :)

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6287
  • Thor Developer
    • View Profile
    • Bromeon
Re: Thor 2.0
« Reply #214 on: July 07, 2013, 06:59:34 pm »
Currently, you don't. The original action is abstracted away, thor::Action acts as a type-erasure front end. An interface would be difficult anyway, what return type should a getter have? I would have to do something more complicated, something like it is used in typical type-erasure classes such as std::function or boost::any.

From the PM, I assume you need it for serialization. But it's not that easy anyway -- if you want to support arbitrary boolean-arithmetic expressions, you need a parser to interpret them.
« Last Edit: July 07, 2013, 07:02:47 pm by Nexus »
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
Re: Thor 2.0
« Reply #215 on: July 13, 2013, 11:22:04 pm »
Hey there Nexus, I'm having a little bit of a problem with your library. For my engine, I have an event manager defined here:

    class CEventManager
    {
    public:
        CEventManager();
        ~CEventManager();

        enum EC_Events
        {
            m_closeWindow,
            m_leftMouseButtonClicked
        };

        void clearEvents() { m_eventMap.clearEvents(); }
        void pushEvent(sf::Event& event) { m_eventMap.pushEvent(event); }

        bool isActive(const EC_Events& event) { return m_eventMap.isActive(event); }

    private:
        thor::ActionMap<EC_Events> m_eventMap;
    };

The manager has the Action map, where I have my events. For some reason, the actions never trigger (yes the enumerator stuff is defined.) I have part of my button class here:

    const bool CButton::checkIfMouseHovered(const float x, const float y) const
    {
        if (m_usingTexture)
        {
            if (m_sprite.getGlobalBounds().contains(x, y))
                return true;
        }

        else if (!m_usingTexture)
        {
            if (m_text.getGlobalBounds().contains(x, y))
                return true;
        }

        return false;
    }

    const bool CButton::checkIfMouseClicked(const float x, const float y, CEventManager manager) const
    {
        if (checkIfMouseHovered(x, y) && manager.isActive(CEventManager::EC_Events::m_leftMouseButtonClicked))
            return true;

        return false;
    }

Obviously, for checkIfMouseClicked, I want to check if the left mouse button is clicked. This registers nothing though. Here's part of my intro state class:

    void CIntroState::update()
    {
        m_game.m_eventManager.clearEvents();

        m_game.m_gameGUI.update(sf::Mouse::getPosition(m_game.screen).x, sf::Mouse::getPosition(m_game.screen).y,
                                m_game.m_eventManager);

        while (m_game.screen.pollEvent(m_event))
            m_game.m_eventManager.pushEvent(m_event);

        if (m_game.m_eventManager.isActive(CEventManager::EC_Events::m_closeWindow))
            m_game.quit();

        if (m_game.m_gameGUI.buttonClicked("playbutton"))
            std::cout << "Coming soon" << std::endl;

        else if (m_game.m_gameGUI.buttonClicked("optionbutton"))
            m_next = m_game.build<COptionsState>(true);

        else if (m_game.m_gameGUI.buttonClicked("quitbutton"))
            m_game.quit();
    }

I hope you could help me fix this. Thanks for making a great library!
Current Projects:
Technoport

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6287
  • Thor Developer
    • View Profile
    • Bromeon
Re: Thor 2.0
« Reply #216 on: July 14, 2013, 05:20:59 pm »
I don't directly see a mistake, but there are a lot of questionable things in the code. Can you reproduce the problem in a minimal and complete example? Then it would be easier to see if you missed something obvious.

Maybe some tips regarding the use of Thor:
  • You can directly use ActionMap::update() instead of clearEvents() and pushEvent()
  • I don't see the point of your CEventManager, all it does is forwarding calls to thor::ActionMap.
And some general C++ tips:
        if (m_usingTexture)
        {
            if (m_sprite.getGlobalBounds().contains(x, y))
                return true;
        }

        else if (!m_usingTexture)
        {
            if (m_text.getGlobalBounds().contains(x, y))
                return true;
        }

        return false;
This can be simplified a lot:
if (m_usingTexture)
    return m_sprite.getGlobalBounds().contains(x, y);
else
    return m_text.getGlobalBounds().contains(x, y);
The same applies to checkIfMouseClicked().

const bool CButton::checkIfMouseHovered(const float x, const float y) const
Don't overuse const. Only the last const is meaningful, the other three don't improve const-correctness. See here for detailed explanation.

m_game.m_gameGUI.update(...);
It looks like the class of m_game is badly encapsulated, you shouldn't need to access its members directly. Maybe provide functions to hide the members.

void pushEvent(sf::Event& event) { m_eventMap.pushEvent(event); }
Since the parameter is not changed in the function, prefer using a reference to const: const sf::Event& event.

        CEventManager();
        ~CEventManager();
Defining constructor and destructor is not necessary, only do it if you need them. The rule of three (or five in C++11) should also be considered.

class CEventManager { enum EC_Events {...}; };
CEventManager::EC_Events::m_leftMouseButtonClicked
Accessing an enumerator via scope of the enum is unusual (in C++03 forbidden), since they are spread into the surrounding scope. CEventManager::m_leftMouseButtonClicked would be enough. But I don't think the m_ prefix is appropriate here; enumerators are constants, not member variables.

In general, the C prefix comes from an ancient idea (which was already wrong at that time) and shouldn't be used. See here for more information.
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6287
  • Thor Developer
    • View Profile
    • Bromeon
[Thor] New particle affector/emitter API
« Reply #217 on: July 19, 2013, 06:32:26 pm »
New particle affector and emitter API

I have finally had time to work again on Thor, and I came up with a new design for particle emitters and affectors. Basically, as already announced long ago, I wanted to make affectors and emitters uniform with the animation API.

As a result, I have removed the following parts:
  • Inheritance relation for emitter and affectors
  • Abstract base classes thor::Emitter and thor::Affector
  • Object access via std::shared_ptr
  • Static create() factory functions
The affectors and emitters are now represented by function objects that have value semantics (like animations). This simplifies the usage a lot, as can be seen in the following example. First, the old API:
thor::UniversalEmitter::Ptr emitter = thor::UniversalEmitter::create();
emitter->setEmissionRate(30.f);
emitter->setParticleLifetime(sf::seconds(5.f));

thor::ParticleSystem system(texture);
system.addEmitter(emitter);
system.addAffector(thor::TorqueAffector::create(100.f));

With the new API, the indirect access via pointers and the factory functions are no longer necessary:
thor::UniversalEmitter emitter;
emitter.setEmissionRate(30.f);
emitter.setParticleLifetime(sf::seconds(5.f));

thor::ParticleSystem system(texture);
system.addEmitter(emitter);
system.addAffector(thor::TorqueAffector(100.f));

Instead of overwriting virtual functions affect() and emit(), a functor with overloaded operator() needs to be defined. As a nice side effect, this modification allows you to use lambda expressions to create emitters and affectors on-the-fly:
system.addAffector([] (thor::Particle& p, sf::Time dt)
{
    p.scale *= (1 - dt.asSeconds()); // shrinks particle over time
});

Shared ownership is no longer used. By default, function objects are copied to the particle system. If you need access to the original object after passing it to the particle system, it is possible to pass references using the functions thor::refAffector() and thor::refEmitter() -- again consistent with thor::refAnimation():
system.addEmitter(thor::refEmitter(emitter));
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 11030
    • View Profile
    • development blog
    • Email
Re: Thor 2.0
« Reply #218 on: July 20, 2013, 12:24:57 am »
Nice changes!

Arg why do you guys always change stuff, just as I've finished the new Nightly Builds! At least now it's really worth pushing out new builds for Thor. ;D
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6287
  • Thor Developer
    • View Profile
    • Bromeon
Re: Thor 2.0
« Reply #219 on: July 20, 2013, 12:42:17 am »
Just wait some time, there will probably be further changes soon :D

I don't think it matters to have always the most recent version. If it does, people are still able to pull from GitHub directly. In my opinion, your Nightly Builds do a very good job at giving users binaries in regular intervals -- but these intervals needn't correspond to single commits ;)
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 11030
    • View Profile
    • development blog
    • Email
Re: Thor 2.0
« Reply #220 on: July 20, 2013, 12:53:25 am »
Just wait some time, there will probably be further changes soon :D
*excited*

I don't think it matters to have always the most recent version. If it does, people are still able to pull from GitHub directly. In my opinion, your Nightly Builds do a very good job at giving users binaries in regular intervals -- but these intervals needn't correspond to single commits ;)
I know, then again all it takes for me is double clicking that build script and waiting till everything is finished... :D
Though I usually always look at the commit and decide on my own scale how important the change was.
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

FRex

  • Hero Member
  • *****
  • Posts: 1848
  • Back to C++ gamedev with SFML in May 2023
    • View Profile
    • Email
Re: Thor 2.0
« Reply #221 on: July 21, 2013, 02:32:51 am »
Are there any plans about changing something in Thor.Input?
Back to C++ gamedev with SFML in May 2023

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6287
  • Thor Developer
    • View Profile
    • Bromeon
Re: Thor 2.0
« Reply #222 on: July 21, 2013, 12:33:29 pm »
You can see the list of planned changes here.

For the Input module, the focus lies on two parts: Allowing more customization (for better support for input such as mouse wheel) and simplifying the API where possible.

The second point aims at action maps and callbacks, which now require rather a lot to set up:
thor::ActionMap<MyAction> map;
map[a] = ...;
map[b] = ...;  

thor::ActionMap<MyAction>::CallbackSystem system;
system.connect(a, &onA);
system.connect(b, &onB);

for (;;)
{
        map.update(window);
        map.invokeCallbacks(system, &window);
        ...
}
This is the most flexible way, as it allows multiple callback systems to be handled independently. I am not sure whether it's appropriate to have two separate classes ActionMap and ActionMap::CallbackSystem. One possibility would be to embed the latter into the former. But I still have to think about this...

Do you consider the current way user-friendly? Or would you like a different API?
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

FRex

  • Hero Member
  • *****
  • Posts: 1848
  • Back to C++ gamedev with SFML in May 2023
    • View Profile
    • Email
Re: Thor 2.0
« Reply #223 on: July 22, 2013, 01:23:33 am »
I'd say it's quite okay now. It's not really 'a lot' of set up code and amount of code to load/create actions and bind the callbacks and (possibly) filter events out from (sf)gui and push them manually will dominate over that little set up. It's nice that the functionality of several callback systems is there, it could get useful in a real app, like letting different menus, game modes, etc. have different callback systems but using same action map so for example: action esc in menu maps to back, in game maps to pause, wsad/arrows/whatever-is-in-settings works both for selecting options and movement in game etc.
Of course it'd be some performance hit to have all actions and callback attempts run all the time but it might be irrelevant because menus/options have time in their main loop to spare and most callback would belong to game class so it's actual overhead would be very little. I like the flexibility and the code is really not bloated or full of boilerplate. It couldn't really get much shorter: removing instancing of callback system and maybe invoking callbacks in update.
« Last Edit: July 22, 2013, 01:33:27 am by FRex »
Back to C++ gamedev with SFML in May 2023

Hiura

  • SFML Team
  • Hero Member
  • *****
  • Posts: 4321
    • View Profile
    • Email
Re: Thor 2.0
« Reply #224 on: July 23, 2013, 07:29:14 pm »
I'm just throwing a thought here. I haven't had the chance to use Thor yet so take it carefully – maybe it doesn't apply at all.

A few years back, I used boost::program_options and I liked the way you can set it up :

po::options_description desc("Allowed options");
desc.add_options()
    ("help", "produce help message")
    ("compression", po::value<int>(), "set compression level")
;

Maybe something similar could be done (for the connect part) ?
SFML / OS X developer