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

Author Topic: SFML 1.5: Bug in window.GetInput().IsKeyDown() ?  (Read 13165 times)

0 Members and 1 Guest are viewing this topic.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
SFML 1.5: Bug in window.GetInput().IsKeyDown() ?
« Reply #15 on: February 12, 2010, 08:05:24 am »
So to be able to use sf::Input, one would have to pop all the corresponding events in his event loop, even if he doesn't use them? That doesn't make sense.

sf::Input is real-time while events are queued, so I can't do anything to force sf::Input to be synchronized with your own event handling, which could happen a long time after the event was actually triggered.

If you want a "pressed" state that exactly matches the events, don't use sf::Input.
Code: [Select]
bool pressed = false;
...
if (event.Type == sf::Event::MouseButtonPressed)
{
    pressed  = true;
}
else if (event.Type == sf::Event::MouseButtonReleased)
{
    pressed = false;
}
else if (event.Type == sf::Event::MouseMoved)
{
    if (pressed)
    {

    }
}
Laurent Gomila - SFML developer

model76

  • Full Member
  • ***
  • Posts: 231
    • View Profile
SFML 1.5: Bug in window.GetInput().IsKeyDown() ?
« Reply #16 on: February 12, 2010, 08:46:26 pm »
To me, this is not a discussion about my particular application, but about the workings of SFML. I hope this is OK, and maybe even encouraged?

The reason I keep posting about this is not to annoy you, but because, the more I look at this, the more inconsistent it seems.

Quote
So to be able to use sf::Input, one would have to pop all the corresponding events in his event loop, even if he doesn't use them? That doesn't make sense.
I am not sure what you mean. Since one can't pick and choose which event type will be popped next, all of them will be popped in order, whether they are handled or not. You still need to pop "unused" events for sf::Input to work, as it is.

Quote
sf::Input is real-time while events are queued, so I can't do anything to force sf::Input to be synchronized with your own event handling, which could happen a long time after the event was actually triggered.
I will refrain from commenting on the first part of the sentence, since that is entirely up to the implementation, which is exactly what we're discussing. The second part, about your inability to ensure when the event handling takes place, seems equally true for both approaches, though.

Maybe the problem is that I don't understand the purpose of sf::Input completely, because I am less experienced, or maybe even not as clever as you. But it was this part of the documentation that gave me the the understanding that sf::Input could be used as a substitute for manually handling "is down":
Quote
A better strategy for this is to set a boolean variable to true  when the key is pressed, and clear it when the key is released. Then at each loop, if the boolean is set, you move your character. However it can become annoying to use extra variables for this, especially when you have a lot of them. That's why SFML provides easy access to real-time input, with the sf::Input class.
When I read that I thought "Oh, wow! That is so cool!", because I too think it is annoying to have to bloat my program code with redundant bool values to see if a key is down. But as it stands, sf::Input does not free users from that task - at least not in all situations.

But even if you should happen to agree with me on all points, I understand why you might still be reluctant to change it: You might be breaking someone else's code, in ways I can't even begin to imagine, and you might be opening up a new can of worms in the form of new bugs to solve, when you really would rather get on with SFML 2.

So my recommendation still stands:
Document when sf::Input is unsuitable for handling "is down" in SFML 1, with the added recommendation that you also document that a proper GetEvent loop must be in place for sf::Input to work. This is not obvious from the documentation, and might lead a beginner to try handling events with sf::Input only.

Figure out a better, easier to understand approach for SFML 2. My personal wish would be for a true automatic "is down" bool substitute.

And lastly, thank you for taking the time to listen to my arguments. I hope you will appreciate and consider my input. I only took the time to put it forward because I appreciate SFML so much.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
SFML 1.5: Bug in window.GetInput().IsKeyDown() ?
« Reply #17 on: February 12, 2010, 11:29:02 pm »
Quote
To me, this is not a discussion about my particular application, but about the workings of SFML. I hope this is OK, and maybe even encouraged?

It is, and I really appreciate that you don't just say "ok, you created SFML so you must be right and I must be wrong, thank you bye bye" :)
I really need this kind of discussions, because I can't focus on every detail of SFML, and I can't be right about everything.

I think you're right, the update of sf::Input and the call to GetEvent are tied together anyway, so there's no reason not to synchronize them properly. It's just a matter of sending an event to you and to sf::Input at the same time, rather than sending all of them (I mean, all that is in the queue) to sf::Input first and then to you. Not a big deal, and it will ensure a perfectly consistent behaviour when sf::Input and events are mixed.

I'll think about it again later, in order to ensure that there's no special case that we forgot, and then I'll probably write a better implementation in SFML 2.

And I totally agree on the documentation, many important details like this one need to be added.

Quote
And lastly, thank you for taking the time to listen to my arguments. I hope you will appreciate and consider my input

I really do, thank you ;)
Laurent Gomila - SFML developer

model76

  • Full Member
  • ***
  • Posts: 231
    • View Profile
SFML 1.5: Bug in window.GetInput().IsKeyDown() ?
« Reply #18 on: February 15, 2010, 09:03:14 pm »
Very good, Laurent, that makes me a little proud, actually. :)

Let me know what your final decision is, will you?

Thanks again!

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
SFML 1.5: Bug in window.GetInput().IsKeyDown() ?
« Reply #19 on: February 15, 2010, 09:06:19 pm »
Quote
Let me know what your final decision is, will you?

Sure :)
Laurent Gomila - SFML developer

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
SFML 1.5: Bug in window.GetInput().IsKeyDown() ?
« Reply #20 on: February 17, 2010, 11:51:29 am »
It's done (in SFML 2) ;)

I did the simple modification that you suggested: sf::Input is now notified only when the event is popped by the user, not when it is pushed into the event queue.
Laurent Gomila - SFML developer

model76

  • Full Member
  • ***
  • Posts: 231
    • View Profile
SFML 1.5: Bug in window.GetInput().IsKeyDown() ?
« Reply #21 on: February 17, 2010, 04:31:11 pm »
OK, cool :)

So SFML 1 will stay as it is?

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
SFML 1.5: Bug in window.GetInput().IsKeyDown() ?
« Reply #22 on: February 17, 2010, 04:39:28 pm »
Yes.
Laurent Gomila - SFML developer

petersvp

  • Newbie
  • *
  • Posts: 6
    • View Profile
SFML 1.5: Bug in window.GetInput().IsKeyDown() ?
« Reply #23 on: June 09, 2010, 01:12:54 am »
I got confused about it.. for now, I haven't any problems with sf::Input. I am calling the empty getEvent loop before using sf::Input class, and it works as expected (version 1.6, MingW 4.4.0 under Windows)

Should I change my code after I update to SFML 2?

Or empty GetEvent loop is enough?

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
SFML 1.5: Bug in window.GetInput().IsKeyDown() ?
« Reply #24 on: June 09, 2010, 08:21:27 am »
No, this modification won't change anything in SFML 2 from the user point of view.
Laurent Gomila - SFML developer