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

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Senzaki

Pages: [1]
General discussions / Re: Better keyboard handling
« on: April 14, 2014, 10:28:11 am »
Well, if someone needs scancodes before SFML 2.2 comes out, I implemented their support because I needed them in my project. See this pull request for more details. The way scancodes are translated to "SFML scancodes" is exactly the same as in SDL. (Note : I don't expect it to be directly integrated in SFML, but at least it could give ideas for a better implementation.)

Window / Re: Slow Event Polling (Linux x64)
« on: August 26, 2013, 07:41:11 pm »
You're right, if anything changes users can just restart the application.
But about the high-res mouse problem, I must admit I don't really understand why it would be inconveniant to offer the option of having mouse motion synced with the display() call, since it's an option offered by several famous commercial games (like Starcraft II).

Window / Re: Slow Event Polling (Linux x64)
« on: August 26, 2013, 05:48:09 pm »
In this case, would it be possible to add a function that would unset this flag ? It may be useful in some cases.

Window / Re: Slow Event Polling (Linux x64)
« on: August 26, 2013, 04:02:21 pm »
Actually, it is not detected as a joystick in the end, because the open call fails. But if SFML tries to open it, it is because it is detected as a joystick at first. I've added printf when open is called, and it is called once per pollEvent call.

Window / Re: Slow Event Polling (Linux x64)
« on: August 26, 2013, 03:32:49 pm »
You're right, I looked at the SDL code and it uses /dev/input, but it also uses Udev. But according to this, you had a few problems implementing it. Maybe a quick look at the way SDL works would help ?

Window / Re: Slow Event Polling (Linux x64)
« on: August 26, 2013, 03:03:57 pm »
I have exactly the same issues. Here's what I found :

- Deactivating ButtonMotionMask and PointerMotionMask in WindowImplX11.cpp removes bad performance caused by the motion of the mouse, but also disables MouseMove events. It's still possible to retrieve mouse position thanks to sf::Mouse::getPosition(). A better fix would be to offer the user an option to sync internal mouse event retrieving with display() (thus getting the mouse position with sf::Mouse::getPosition() and putting it into memory so that it can be used later by pollEvent()). This way, only one mouse event would be retrieved per frame. Actually, this is option is granted by many recent STR games : you usually have an option to "reduce mouse latency", which makes the game behave like SFML : less mouse latency, but bad performances on low-end computers with high-resolution mices. (Actually, I think many of these games still limit the amount of mouse events retrieved per frame, since the framerate isn't SO bad.)

- The way joysticks are handled is really an issue. I also have an accelerometer incorporated in my computer, and this is also causing slowdowns. it's because of the way joysticks are detected. Every time pollEvent is called, the list of joysticks is updated, and SFML tries to find if new joysticks were plugged in. This detection is performed updatePluggedList in Linux/JoystickImpl.cpp. When this function tries to know if /dev/input/js0 is plugged in, it calls the syscall "stat" to know if /dev/input/js0, and it actually exists, even if the user doesn't have the rights to open it. Then JoystickImpl::open calls the syscall open("/dev/input/js0") even if it doesn't have the right. And I think this is this syscall that takes time.

- If SDL and Allegro don't have the same issue, it may be because they us XInput instead of using directly the /dev/input files, because XInput KNOWS it cannot use this "joystick" (=internal accelerometer). But I have to read the sources of SDL to be sure they really use XInput.

I think the first thing to do is to let the programmer choose if SFML should try to use Joysticks, because even if joysticks may work fine on many computers, SFML still calls "stat" Joystick::Count time for EVERY pollEvent call on these computers. I think this is bad because it uses the hard drive, which is a slow device (well, i must admit i don't know how "stat" works, maybe it's optimized and it doesn't use the HDD for every call, but still...).
As you said, the best way to solve this may be to look at the way SDL finds joysticks.

Hope this helps, and thank you for having created this amazing library !

EDIT : Appearently, SDL doesn't use XInput to handle joysticks. I'm currently trying to understand how it's done.

General / Re: SFML freezes when mouse moves (VS 2010)
« on: December 15, 2012, 05:31:39 pm »
It seems that this problem is still not corrected :( I'm using Linux, and everytime I use pollEvent, there are SO MANY events that are generated when I move the mouse (sometimes more than 100 in one frame). Wouldn't it be possible to give the option to synchronize pollEvent() and display() ? I mean, is it possible to generate only one "global" mouseMove event (that would be the addition of all mouseMove events) per frame ?


I have encountered the problem of the digital keys on the top of the keyboard (Num0, Num1...) on Linux. I have (partly) fixed this problem. You can find the patch I have made linked to this message. If you use the git version of the SFML, you can apply it thanks to the command "git apply fixnumkeys.patch". I said I had partly fixed this problem because I had to use the keycodes, which are sometimes different on strange keyboards (I have not encountered such keyboard yet, and no new problem should appear on these keyboards, except the fact that the "NumX" keys won't work better than before). I have tested several layouts (qwerty, azerty...) and all of them seemed to be working. All the keys that were properly managed before should still work the same way : I have not changed the way they were handled. I hope this will give ideas to fix the issue thanks to a "cleaner" method than the one I used ;)

(PS : Sorry if some of the sentences of this message seem weird, English is not my native language.)

[attachment deleted by admin]

Pages: [1]