-
Hi guys !
I have a (probably stupid) question about the event. Let's suppose this:
sf::RenderWindow window(parameters)
while(window.isOpen()
{
while(window.pollEvent(Event)
{
doSomething();
}
doSomethingElse();
}
Ok, now without any surpise, pollEvent will dequeue all queued event. Now suppose I'm superman and I can trigger an event faster than light. The result will be that I will be stuck in the pollEvent loop. Now suppose a stupid superman and a only press the same key. Will I be still stuck in the pollEvent loop?
I think the logical answer will be yes but just be sure ^^
Cheers !
-
If you can somehow generate events faster than they can be processed, then "yes" you could theoretically be stuck.
In real life this doesn't happen. Don't worry about it.
-
The answer depends on the timing properties of the physical input devices and the operating system that's generate events, but Jesper's basically right.
I'm fairly sure it's at least theoretically possible to type or click faster than your mouse or keyboard will notice, even if no normal person would ever do that by accident. You can certainly do it faster than your operating system can respond if your computer is running particularly slowly, but then you've got other problems.
I did find this chart of mouse response times (http://www.blackboxtoolkit.com/responsedevices.html) which should give you an idea how quick you'd have to be to actually cause "missed" click events:
(http://www.blackboxtoolkit.com/images/resp_dev_summary.png)
tl;dr if Superman can click multiple times within ~50 milliseconds, and not destroy his mouse in the process, yes a click event might get missed.
-
You asked if you would be stuck in the event loop if there are constantly events added to the queue before it is cleared. The answer is, as you guessed, yes, and is one good reason to keep the event loop code as "light" as possible. If you had "heavy" code (such as constantly taking screenshots, for example), it could slow down the event loop considerably, which is (one reason) why it is recommended to do "heavy" stuff outside of the event loop.
-
@Hapax : what I said???
-
I felt the need to mention that it was probably quite possible and one reason why. I'm sure there have been actual times that this has happened, though, even if by accident.
-
Thanks guyz for your answers!
You're confirm what I was thinking. Of course I know I'm not superman (uhu!) but in fact I think it's possible to be stuck in the event loop. It could be easy done with macros only if, of course, you trigger an event faster than the cpu could "dequeued" it.
Now let's suppose game (like Street fighter), 2 players are fighting one against the other. If they press "A" to Attack the opponent, the last one will lose 1 HP. Both players have 100 HP and the game is over when one of them reach 0 HP.
We can confirm that the player who will win will be the one who pressed (like a retarded) "A" faster than the other one. But know let's suppose one of them "cheat" and use a macro.
Let's program it as : do { press "A", release "A" } every 10 ms when press F1 for example and then when I press F1 once again stop it. He could kill his opponent in 1 sec.
My question was in fact to understand clearly the behavior of events in SFML in order to prevent a user to use macro.
@Hapax: Let's take my previous example this:
sf::RenderWindow window(parameters)
while(window.isOpen()
{
while(window.pollEvent(Event)
{
doSomething();
}
doSomethingElse();
}
If doSomethingElse() takes a "long" time to be done, it will also slow down event response time. So does it really matter if "heavy" code is done outside? In any case, what could you propose to avoid this?
Cheers
-
Let's assume you do heavy work in the event loop regardless of what event was triggered. During each heavy work one event get generated by the OS. Thus after the heavy work is done you poll the new event and start over again with the heavy work.
That way you'll be stuck in an infinite loop and your rendering/updating etc. outside the event loop never gets executed.
Of course that was an extreme case, but it shows that every event generated during heavy work will immediately afterwards get processed again and might trigger further heavy work.
Besides that in the end one is usually just interested in one "set" of input for each frame and as such it's better to gather input (events), update the "physics" according to the input, render and repeat.
Instead of get "some" input, update the physics, get some more input, update the physics again, repeat until there's really, really no new input anymore, then render and repeat.
-
I understand what you're talking about eXpl0it3r but I'm not really sure how to deal it. Are you meaning something like that?
sf::RenderWindow window(parameters)
while(window.isOpen()
{
while(window.pollEvent(Event)
queue_event(Event);
while(deque_event(event))
doHeavyStuff();
}
-
The question is by now, what are you trying to do?
Your general game/main loop would look something like that:
// Game loop
while(window.isOpen())
{
// Handel events
sf::Event event;
while(window.pollEvent(event))
{
switch(event.type)
{
case sf::Event::Closed:
window.close();
break;
// Cache inputs
default:
break;
}
}
// Update entities and everything else
entity_system.update();
// Render
window.clear();
window.draw(entity_system);
window.display();
}
Besides don't over engineer and over think stuff. If you're not sure, just try them out, that way you won't get stuck with theories and possibilities forever and at the same time actually learn on your own whether something works or not. ;)
Programming is never about be right or wrong, but it's about finding a good and working solution to a problem.
-
mmh the question now is more, how could I easily avoid the use of macros ^^. It's something that scared me. I want to do a game as fair as possible. I'm doing some search before the development of the solution that's why I'm here ^^ to have a better understanding on it and to get your point of view on that question.
My game loop is exactly like that more ore less. But what you were talking about the heavy stuff was interesting . I was thinking of how could you do a heavy stuff related to an event outside the event loop ^^. that's it.
Cheers
-
how could I easily avoid the use of macros
Just not using them would be the solution to this ;)
I was thinking of how could you do a heavy stuff related to an event outside the event loop
possible basic scenario in broken pseudo code:
game loop
{
event loop
{
if keyPressed(spacebar)
player.jump(); // informs the player class that it should jump during the next update
}
update section
{
player.update(); // would do the actual calculations of what happens to make it jump
}
render;
}