timestamps for events

[Nexus]

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.

[Mr. Wonko]

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]

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>

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.