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

Author Topic: Mouse movement causing framerate drop  (Read 10520 times)

0 Members and 1 Guest are viewing this topic.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
Mouse movement causing framerate drop
« Reply #15 on: March 18, 2011, 07:57:28 am »
Quote
Easy fix for Laurent is to add a bool to mouse moved event that tells the end user if this is the last mouse moved event currently in the queue

I think we should wait for more feedback before writing a fix for this. Let's see if all users that suffer from this problem have a high mouse events rate.
Laurent Gomila - SFML developer

Groogy

  • Hero Member
  • *****
  • Posts: 1469
    • MSN Messenger - groogy@groogy.se
    • View Profile
    • http://www.groogy.se
    • Email
Mouse movement causing framerate drop
« Reply #16 on: March 18, 2011, 02:26:30 pm »
Quote from: "Laurent"
Quote
Easy fix for Laurent is to add a bool to mouse moved event that tells the end user if this is the last mouse moved event currently in the queue

I think we should wait for more feedback before writing a fix for this. Let's see if all users that suffer from this problem have a high mouse events rate.


Well just thinking, even though if it is not the problem, isn't it more desirable for most developer to only handle the latest mouse moved event? The other ones aren't interesting anyway.

I'm guessing Brendon does some mediocre/heavy game logic with every mouse moved event. Thus when we face a high DPI mouse, he will do this work several time unnecessary.

Brendon try something like this on:
Code: [Select]

sf::Event lastMoveEvent;
sf::Event event;
while( window.GetEvent( event ) == true )
{
        switch( event.Type )
        {
         case sf::Event::MouseMoved:
                lastMoveEvent = event;
        }
}
HandleMouseMoveEvent( lastMoveEvent );

Though you'll of course have to adapt it to SFML.NET and your framework but I think you get the picture. Sumarization: Only work with the latest MouseMove event in the queue :P
Developer and Maker of rbSFML and Programmer at Paradox Development Studio

devlin

  • Full Member
  • ***
  • Posts: 128
    • View Profile
Mouse movement causing framerate drop
« Reply #17 on: March 18, 2011, 02:40:35 pm »
Quote from: "Groogy"
Well just thinking, even though if it is not the problem, isn't it more desirable for most developer to only handle the latest mouse moved event?

Not really - especially if you use the buffered input for gesture recognition and the like.

What would be useful though is a way to limit the amount of messages processed per frame. I.e. a way to manually loop through the internal messages and save anything that takes too much time to a later frame.

That way you might end up with a serious backlog of events - if the computer playing the game is too slow - but the same computer would choke even with the current system. What it lets you do is smooth out framerate over time instead of having stalls.

Brendon

  • Jr. Member
  • **
  • Posts: 83
    • View Profile
    • http://blendogames.com
Mouse movement causing framerate drop
« Reply #18 on: March 18, 2011, 11:30:53 pm »
@Groogy - thanks for the tip.  I'm poking around the sfml.net build, but can't find the equivalent to the "GetEvent(event)" call.

At any rate, the problem is solved - though it introduced a new one.

It turns out I was using sfml v1.5.  I'm using v1.5 because v1.6 has a graphics bug I wasn't able to work around.

I asked my users to copy the v1.6 SFML libraries into the game folder. It worked!  The mouse-event framerate drop is no longer an issue.

But, using the v1.6 libraries introduced the graphics issue mentioned above
v1.5: http://blendogames.com/dev/capture-normal.jpg
v1.6: http://blendogames.com/dev/capture-38.png

So my question now is -
1. Can I use the v1.6 Window component, but retain using the v1.5 Graphics component?
2. Anyone know of a workaround for that v1.6 graphics offset?

I tried running with the v1.6 Window dll and v1.5 Graphics dll, but that seems to disable the mouse input.

Any ideas?

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
Mouse movement causing framerate drop
« Reply #19 on: March 18, 2011, 11:37:10 pm »
Quote
I'm poking around the sfml.net build, but can't find the equivalent to the "GetEvent(event)" call.

There's none, event handling is done the .Net way with DispatchEvent().

Quote
I asked my users to copy the v1.6 SFML libraries into the game folder. It worked! The mouse-event framerate drop was no longer an issue.
:shock:

Quote
1. Can I use the v1.6 Window component, but retain using the v1.5 Graphics component?

I don't know. 1.x versions are not supposed to be binary compatible, but 1.6 was mainly a bug fix release so it might be binary compatible with 1.5.

Quote
2. Anyone know of a workaround for that v1.6 graphics offset?

Don't use scale if you can, or "fix" it in source code and recompile. I can tell you what to do if you want.
Laurent Gomila - SFML developer

Brendon

  • Jr. Member
  • **
  • Posts: 83
    • View Profile
    • http://blendogames.com
Mouse movement causing framerate drop
« Reply #20 on: March 18, 2011, 11:42:17 pm »
@Laurent - Sure, I'd absolutely love to know how to make the fix in the source code.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
Mouse movement causing framerate drop
« Reply #21 on: March 19, 2011, 10:14:18 am »
Remove line 191 in src/SFML/Graphics/Sprite.cpp
Code: [Select]
GLCheck(glTranslatef(0.375f, 0.375f, 0.f));
If your sprites get uglier, there will probably be something to modify in sf::Image as well.

Then recompile SFML, CSFML and SFML.Net ;)
Laurent Gomila - SFML developer

Brendon

  • Jr. Member
  • **
  • Posts: 83
    • View Profile
    • http://blendogames.com
Mouse movement causing framerate drop
« Reply #22 on: March 19, 2011, 11:29:44 pm »
You're my hero!  Removing that line and recompiling the libraries fixed it.

Thanks, Laurent.