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

Author Topic: timestamps for events  (Read 9457 times)

0 Members and 1 Guest are viewing this topic.

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6287
  • Thor Developer
    • View Profile
    • Bromeon
timestamps for events
« Reply #15 on: September 19, 2010, 03:05:45 pm »
Quote from: "Mr. Wonko"
I can understand that. Well, there's nothing keeping me from adding it to SFML myself, right?
No, as long as you respect the license. :)

Although you risk incompatibilities with newer SFML versions or other user's code. If you find a way to handle it non-intrusively, you should probably prefer that.
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Mr. Wonko

  • Newbie
  • *
  • Posts: 10
    • View Profile
timestamps for events
« Reply #16 on: September 19, 2010, 07:11:13 pm »
Quote from: "Nexus"
If you find a way to handle it non-intrusively, you should probably prefer that.

I thought I had found one.

I thought I could inherit from (Render)Window and overwrite the OnEvent() method.

The problem is: Events are not received (and subsequently sent to the EventListeners, like the (Render)Window) in realtime (via callback). Events are received on request (via WindowImpl::ProcessEvents(), called by Window::GetEvent()).

So I'm not going to do this. We'll see whether I regret this decision in a couple of years.

Spodi

  • Full Member
  • ***
  • Posts: 150
    • View Profile
    • http://www.netgore.com/
timestamps for events
« Reply #17 on: September 19, 2010, 08:13:17 pm »
Quote from: "Nexus"

Although you risk incompatibilities with newer SFML versions or other user's code. If you find a way to handle it non-intrusively, you should probably prefer that.


I was just coming here to say that same thing. ;) That is why I proposed a workaround that doesn't change SFML itself. Its best to, whenever possible, avoid altering external code. Otherwise, it just becomes harder to update the external code since now it is cluttered with your own code. If you really must alter external code, though, the I recommend at least heavily commenting it so you know where your changes took place and why. I usually use a comment with a unique tag, such as:

Code: [Select]

// !!CHANGE: <reason>


Quote from: "Nexus"
The problem is: Events are not received (and subsequently sent to the EventListeners, like the (Render)Window) in realtime (via callback). Events are received on request (via WindowImpl::ProcessEvents(), called by Window::GetEvent()).


And that is why you'd want to grab them using an external thread - so you call it as frequently as you want.