Using SFML 2.0 and OIS

[Kalith]

Hi !

I have some trouble with SFML inputs (no mouse grab, among other) and I've been using OIS for some time instead.
Unfortunately, I don't recall when, but the combination of those two libraries (SFML and OIS) stopped working on Ubuntu with the following error :

Code: [Select]

X Error of failed request:  BadAccess (attempt to access private resource denied)
  Major opcode of failed request:  2 (X_ChangeWindowAttributes)
  Serial number of failed request:  7
  Current serial number in output stream:  9

while initializing OIS with a window created by SFML :

Code: [Select]

mWindow_.Create(sf::VideoMode(800, 600, 32), "Test");

There must be something that troubles OIS in the way SFML creates its window, because OIS works very well with Ogre on the same machine, and it also works if I create manually my window then send it to SFML :

Code: [Select]

Display *xDisp = 0;
Window xWin = 0;

//Connects to default X window
if(!(xDisp = XOpenDisplay(0)))
    throw Exception("Error opening X!");

//Create a window
xWin = XCreateSimpleWindow(xDisp,DefaultRootWindow(xDisp), 0,0, 800, 600, 0, 0, 0);

//bind our connection to that window
XMapWindow(xDisp, xWin);

//Select what events we want to listen to locally
XSelectInput(xDisp, xWin, StructureNotifyMask);
XEvent evtent;
do
{
    XNextEvent(xDisp, &evtent);
} while(evtent.type != MapNotify);

//Create sf::Window
mWindow_.Create(xWin);
(code taken from OIS samples)

I don't know X11 at all, so I have no clue of what could be wrong...
Do you have an idea ?

Thank you,

[Lynix]

(Looking at your location) There's a french forum here : http://www.sfml-dev.org/forum-fr/

[Kalith]

I know, but English ones are more visited. More people seeing the problem, more chances of getting it fixed ?

[Kalith]

I found the answer on OIS forums : click.
"The problem is the X11 mouse. Only one listener can be registered at any time on X11."

Right now, I barely fixed the problem by adding a "SetInputEnabled(false)" function to sf::Window, which propagates to WindowImpl, and disables all input related code. It is horribly messy so I won't post it here.

I don't know if that's asking too much, but could you integrate such a function into SFML ? A better option would be to decouple the input and windowing code like you did with graphics, audio, etc, but that'd probably be too much trouble...

[Laurent]

It is horribly messy [...]
[...] could you integrate such a function into SFML ?

Are you asking me to integrate a messy function? :roll:

A better option would be to decouple the input and windowing code like you did with graphics, audio, etc, but that'd probably be too much trouble...

What would that mean? Global inputs are already separated from windows, but input events are generated by windows, I can't separate them. Unless you want something like window.DisableEvents(MouseMove | MousePressed).

[Kalith]

You could do something like :

Code: [Select]

sf::Window myWindow(...);
sf::Input myInput(myWindow);

sf::Window would take care of creating a window, like it is supposed to.
Then, when sf::Input is instantiated, it registers all the required events and stuff for input.

This is not a solution, windows events must be handled -- otherwise the window is frozen.

But for this issue :

Code: [Select]

window.DisableEvents(MouseMove | MousePressed)
would work quite as well I think.

Disabling only certain types of events would be a better solution, but... the only use case for such a feature would be this X11/mouse problem.

In my opinion, the real problem is that you're trying to mix two incompatible things. Tell me what features you need, and we'll see if they can be implemented or worked around. And by the way, can't you implement what's missing outside SFML with the native window handle (window.GetSystemHandle())?

[Kalith]

Whoops, sounds like you edited my message instead of quoting it

This is not a solution, windows events must be handled -- otherwise the window is frozen.

I don't understand. Input events are not required to use a window, are they ?

Tell me what features you need, and we'll see if they can be implemented or worked around.

The main feature I miss is the "free look", also called mouse grabbing.
I've just implemented it into SFML 2.0's old sf::Input class (which I see you have removed recently) using OIS' algorithm. When the cursor leaves the window (or approaches too close from its borders), it is warped to the center of the render window. This behavior is mainly used when you only care about relative mouse movement, when you don't want to be stuck by screen borders.
I think this is the "hack" you are referring to in this thread. But as long as you check for the MouseLeft event to prevent the cursor from actually going out of the screen, I see absolutely no problem with it.

And by the way, can't you implement what's missing outside SFML with the native window handle (window.GetSystemHandle())?

Propably yes. But I'm no X11 programmer, and it seems to be very hard to get into. I don't want to do anything wrong.
Anyway now that I have implemented what I was missing, I don't need OIS anymore, so the problem is solved for me.
But other people could still need it (I hear it supports Xbox controllers, WiiMotes and has touchscreen capabilities).

[Laurent]

Whoops, sounds like you edited my message instead of quoting it

:lol:  :lol:  :lol:
I'm really sorry.

I don't understand. Input events are not required to use a window, are they ?

The (internal) event queue has to be processed, so that the (internal) events can reach their target window, and the window can react to them. That's what's needed for the window to be responsive. Then it doesn't matter what SFML (and you) does with the events.

[Kalith]

The (internal) event queue has to be processed, so that the (internal) events can reach their target window, and the window can react to them. That's what's needed for the window to be responsive. Then it doesn't matter what SFML (and you) does with the events.

I must be dumb, but I don't see how this is affected by the code sample I provided.
If the user decides not to use sf::Input, then the sf::Window is only registered to a minimal handful of events (that is, excluding mouse and keyboard ones), which can be processed as usual.
Else, input events are registered to the sf::Window when the sf::Input class is instanciated and, when the user calls sf::Window::PollEvent(), you can use sf::Window::FilterEvent() (for example with a generic callback function) to transfer these to the sf::Input class without sf::Window knowing a single thing about sf::Input.

You'd get something like :

Code: [Select]

class Input
{
public :

    Input(const Window& window)
    {
        // Register needed events
        for (needed events)
            window.RegisterEvent(event);
           
        // Add a "OnEvent" callback to the sf::Window
        // which will be called by FilterEvent for example.
        window.AddOnEventCallBack(bind(&Input::OnEvent, this));
    }
   
    void Capture()
    {
        // Reset some flags (to be called on each frame)
    }
   
    int GetMousePositionX() const {}
    int GetMousePositionY() const {}
    // ...
   
    void OnEvent(const Event& event)
    {
        // Read usefull events, mouse movement etc.
    }

    // You could also add a PollEvent fonction like in sf::Window
    // to allow people to use event based input if they prefer.
    // You'd then have to handle a new event stack in this class too.
   
private :

    // ...
};

That way, input is dependent on the window, but not the opposite, and can be enabled/disabled at will.
Is there a problem with this approach ?

[Laurent]

Your solution is ok. I thought that you wanted to completely disable event handling in windows by default, and use an external class to enable/process them. Now I see that you were only talking about input events.

[Kalith]

Eh, I'm sorry. Now that I read my phrase again I see it's not obvious indeed.
Now what do you think ?

[Laurent]

I think it's becomes quite complicated for very little gain. SFML works perfectly when used alone, I'm not going to make more complicated in order to be able to mix it with other libraries that watch mouse events on X11.

[Kalith]

Alright then. Thank you for your answers