Messages

1

Window / Re: SFML2: MouseMove events stalling event loop

« on: July 01, 2012, 05:13:29 am »

It gets stranger.

Hoping to get to the bottom of this, and because I'm not 100% comfortable working from a repo snapshot, I rolled back to the release candidate. Now, mouse events seem to magically work fine, but I can only link the libs statically. Otherwise I get Entry Point Not Found errors when I load my app, suggesting that the precompiled lib files in the RC download are mismatched with the included DLLs. And funnily enough, the DLLs I built myself work fine with the precompiled libs in the RC.

I'm happy with static linking but if anyone has any thoughts on why I can't seem to use the DLLs in the RC download, they would be much appreciated.

2

Window / Re: SFML2: MouseMove events stalling event loop

« on: June 30, 2012, 06:13:29 pm »

Ok, fixed, kinda.

It doesn't seem to happen if I build the libs from the latest snapshot of the git repo.

I'm happy with that as a solution for now, but this suggests there's something that needs to be addressed in the release candidate.

3

Window / Re: SFML2: MouseMove events stalling event loop

« on: June 29, 2012, 03:50:53 pm »

I use this mouse, which has an adjustable resolution. The same effect happens whether the mouse resolution is set to 400 or 5000 dpi. Also, I notice the same behaviour while using another less-fancy mouse. It also seems to happen on the SFML examples packaged with 2.0.

I notice a similar but not quite so pronounced effect if I play with the joystick axes while running the same 2.0 program, but nowhere nearly as bad as the mouse. It might stall 30 ms at worst.

4

Window / SFML2: MouseMove events stalling event loop

« on: June 29, 2012, 12:52:57 am »

Today I decided to make the jump to the SFML 2.0RC from 1.6, but since I have I've noticed a serious problem with MouseMove events causing my event loop to stall until I stop moving the mouse. Here are some code samples to demonstrate what I mean:

#include <SFML/Window.hpp>
#include <iostream>

int main() {
    sf::Window win(sf::VideoMode(1024, 600), "SFML 1.6");
    sf::Clock clock;

    while (win.IsOpened()) {
        sf::Event e;

        float elapsed = clock.GetElapsedTime();
        clock.Reset();

        std::cout << elapsed << std::endl;

        while (win.GetEvent(e)) {
            if(e.Type == sf::Event::Closed) win.Close();
        }

        win.Display();
    }
    return 0;
}

Simple program using SFML 1.6. The 'elapsed' variable is assigned a consistent value (about 0.016) every iteration even when I move the mouse around the window, so this works as expected.

#include <SFML/Window.hpp>
#include <iostream>

int main() {
    sf::Window win(sf::VideoMode(1024, 600), "SFML 2.0");
    sf::Clock clock;

    while (win.isOpen()) {
        sf::Event e;

        sf::Time elapsed = clock.getElapsedTime();
        clock.restart();

        std::cout << elapsed.asMilliseconds() << std::endl;

        while (win.pollEvent(e)) {
            if(e.type == sf::Event::Closed) win.close();
        }
        win.display();
    }
    return 0;
}

The same program's SFML 2.0RC 'equivalent'. If I leave the window alone, the program prints out a consistent 16 ms every iteration, as I expect. If I start moving the mouse around the window, though, it gets stuck in the event loop until the mouse pointer either leaves the window or stays completely still. The result is that the next printout of the elapsed time is much longer (2000 ms if I move the mouse around continuously for 2 seconds, etc).

Any thoughts? I'm using Windows 7 x64, the most recent SFML 2.0RC from the downloads page, dynamically linking to the SFML libraries, and this happens in both debug and release modes.

edit: Oh yes, I'm also using the GCC DW2 version of the SFML libs. My compiler is GCC 4.4.0.