User input events queue about ash

[BigPhilCombo]

User input events should just change a value on a component. The
appropriate systems will handle the component in the appropriate order.
On Jun 8, 2013 4:14 PM, "Gaen" [email protected] wrote:

Hi!

The thing that bothers me is that while all the systems operate within
main update loop, user input events such as clicks and key hits are
happening out of it. This means that a click, for example, can happen *
between* the updates. Or even if a user is fast enough, he can manage to
hit and release the mouse multipe times, still between the updates. And if
a user input handling system is checking inside it's update() if the button
is pressed, such clicks will be simply lost.

[image: clicks]https://f.cloud.github.com/assets/1899551/628051/28bcd172-d077-11e2-92ee-4027d4448f18.png

It would be great to have some util that collects such events into a queue
and then allows systems to handle them correctly.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/25
.

[Gaen]

Let's assume we have two asteroids overlapping each other, and click should destroy the asteroid. When user clicks twice in the area which belongs to both of the asteroids between the updates, some out-of-update-loop code will record two clicks into the first asteroid. After the update this asteroid will be destroyed by the first click and the second click will be lost, leaving the second asteroid intact. Or, if clicks are recorded into all asteroids that match the coordinates, both asteroids will be destroyed by the first click, which is wrong too.

But your answer gave me an idea to create some ClickComponent instance for every click and allow systems to iterate through ClickNodes, that might work.

[Gaen]

Here's the system I've implemented: https://gist.github.com/Gaen/5737335

It catches the events out-of-the-loop, converts them into entities and adds them to the engine, which allows other systems to process those events inside the loop and remove used events from the engine. The system itself executes in the loop after all input processing is done and removes all remaining event entities. So all mouse events live from the moment they happen to the mouse handling system update.

I don't think it's good for perfomance to create a new entity with a new component and then get it through the NodeList and destroy it for every mouse move, but at least it works.

[nadako]

Wow dude, this looks so over-engineered. I'm not sure that it's a good idea to try to fit everything in the boundaries of ash style. You could just implement some kind of click manager that operates outside of system update loop, reacts to clicks and sets a "clicked" flag to a relevant asteroid entity component to be processed by the system later. And for your overlapping asteroids case, just get the first one without the "clicked" flag set and toggle it. KISS, you know :)

[Gaen]

After having a good sleep I've realized all the crazyness of my code (: Yeah, I'm gonna rewrite it into something simple.
But I don't like the idea of putting game-related click processing logic into click manager, because click can select something, or destroy something, or build something depending on context - these are different kinds of logic that should be in a different systems.
I still do like the idea of putting events into some queue, handling this queue by systems and then clearing it for every update. It just shouldn't work through the engine, simple vector is good enough.

[richardlord]

Since you implemented this outside of the core code and simply include one line in the core code to initialise it, I suggest there's no need to edit the core code at all, you can initialise your mouse tracking independently of the core code and there's no need to add it to the core project.