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

Author Topic: Scancodes Round 3 & Release Readiness  (Read 1371 times)

0 Members and 1 Guest are viewing this topic.

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10505
    • View Profile
    • development blog
    • Email
Scancodes Round 3 & Release Readiness
« on: February 23, 2023, 10:46:30 am »
Already some weeks ago, we've merge the scancode implementation to the 2.6.x branch and thus closing the final feature of SFML 2.6
You can use the pre-built binaries or the SFML CMake Template to get started quickly.

Now, we're looking for people to help us test the version further and especially also try and make use of scancodes.
If you have a game or other project using SFML, I recommend to update to the 2.6.x branch and see how you can add keyboard layout independent keyboard handling with scancodes.

There are essentially four additions or enhancements to the existing API:

  • Introduction of a new enum for scancodes: sf::Keyboard::Scancode
  • Enhancement of the KeyEvent event union to also return the scan code: event.key.scancode
  • Real-time querying of the keyboard state: sf::Keyboard::isKeyPressed(sf::Keyboard::Scancode)
  • Best effort translation from scancodes to the current keyboard layout: sf::Keyboard::Key localize(sf::Keyboard::Scancode code)
  • Best effort translation from the current keyboard layout to scancodes: sf::Keyboard::Scancode delocalize(sf::Keyboard::Key key)
  • Retrieving of a human readable key description (e.g. for in-game UIs): sf::String getDescription(sf::Keyboard::Scancode code)

If you want to test the inputs independently, there's also the existing SFML-Input example.

Let us know how things work out for you and report any issues encountered.
Happy testing! :)
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

Hapax

  • Hero Member
  • *****
  • Posts: 3135
  • My number of posts is shown in hexadecimal.
    • View Profile
    • Links
Re: Scancodes Round 3 & Release Readiness
« Reply #1 on: February 27, 2023, 05:39:58 pm »
Now that I know there's a binary available, I'll switch and do some testing :)
Selba Ward - SFML drawables
Kairos - Timing Library
Rectangular Boundary Collision - Rectangular SAT Collision

Hapaxia Links

Hapax

  • Hero Member
  • *****
  • Posts: 3135
  • My number of posts is shown in hexadecimal.
    • View Profile
    • Links
Re: Scancodes Round 3 & Release Readiness
« Reply #2 on: May 10, 2023, 07:28:44 pm »
I've created a visual tool to test scancodes for keys. All keys can be set however you like and it highlights ones that have been pressed. It can also show you the codes set for the keys.

It is what I used to test the scancodes. Remember you'll need SFML v2.6.x for this if you build from source.

It looks like this:


Here it is:
https://www.mediafire.com/file/g4uq783rb8kbdvy/TestSfmlScancodes.zip/file
It is a zip file that contain 3 things:
the source code (one .cpp file that contains instructions at the top),
a compiled executable for 64-bit Windows (built from the exact source source above),
an Arial font (for the executable or for the code - needs to be in same folder).

In case you don't trust me - and why would you? ;D - I'll provide the entire source code here to build it for yourself without downloading my zip. You'll need an "arial.ttf" font in the same folder (the working directory, at least).

(click to show/hide)

(click to show/hide)
Selba Ward - SFML drawables
Kairos - Timing Library
Rectangular Boundary Collision - Rectangular SAT Collision

Hapaxia Links

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10505
    • View Profile
    • development blog
    • Email
Re: Scancodes Round 3 & Release Readiness
« Reply #3 on: May 12, 2023, 12:02:21 am »
Oh wow, that's really cool, thank you! :)
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

Hapax

  • Hero Member
  • *****
  • Posts: 3135
  • My number of posts is shown in hexadecimal.
    • View Profile
    • Links
Re: Scancodes Round 3 & Release Readiness
« Reply #4 on: May 15, 2023, 08:52:46 pm »
You're welcome.

Hope it comes in useful!
Selba Ward - SFML drawables
Kairos - Timing Library
Rectangular Boundary Collision - Rectangular SAT Collision

Hapaxia Links

kojack

  • Full Member
  • ***
  • Posts: 228
    • View Profile
Re: Scancodes Round 3 & Release Readiness
« Reply #5 on: May 16, 2023, 05:49:50 am »
(Testing on windows 10 with a Wooting Lekker keyboard)

In the test app above, using the default auto mapping the R Sys key is mapped to the Menu key instead of RSystem. Both menu and rsystem do work correctly if manually mapped though.

I couldn't get printscreen to work in the app. It couldn't manually map it, it thought no key was being pressed.
But looking online I see that windows intentionally doesn't send keydown events for Printscreen, it only sends keyup. I tested in my own SFML 3.0 app and I do get the correct scancode for printscreen on keyup.



Garwin

  • Newbie
  • *
  • Posts: 26
    • View Profile
Re: Scancodes Round 3 & Release Readiness
« Reply #6 on: May 16, 2023, 02:09:51 pm »
I have tested in on Win10 and 2 keys map same.
left CTRK and right ALT  (Alt Gr) have same mapping 127.

kojack

  • Full Member
  • ***
  • Posts: 228
    • View Profile
Re: Scancodes Round 3 & Release Readiness
« Reply #7 on: May 16, 2023, 02:19:55 pm »
Right alt is 133 for me. Do you have any keyboard software in the background?

I thought the menu key wasn't working, but it turned out by default my wooting software had mapped the menu key to function layer 1.

Garwin

  • Newbie
  • *
  • Posts: 26
    • View Profile
Re: Scancodes Round 3 & Release Readiness
« Reply #8 on: May 16, 2023, 03:49:51 pm »
Right alt is 133 for me. Do you have any keyboard software in the background?

No. In any other software LEFT CTRL and right ALT is correct. I use QWERTZ keybord with only difference switching "Z" and "Y" and those works correctly. Another change is that on this keyboard layout the numbers are with SHIFT key as without it there are literals with diacritics.

I try some on-line test codes and:
https://keyboard-test.space/ - incorrectly too, even more that SFML test
https://keyboardtester.io/tester/ - this one is correct, but does not show LEFT, RIGHT for CTRL and ALT

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10505
    • View Profile
    • development blog
    • Email
Re: Scancodes Round 3 & Release Readiness
« Reply #9 on: May 16, 2023, 04:04:07 pm »
Another change is that on this keyboard layout the numbers are with SHIFT key as without it there are literals with diacritics.
I don't quite understand what you mean with this. The keys should be reported the same regardless of modifier key, that's kind of the point of scancodes :)
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

Garwin

  • Newbie
  • *
  • Posts: 26
    • View Profile
Re: Scancodes Round 3 & Release Readiness
« Reply #10 on: May 16, 2023, 04:19:05 pm »
Yes, not important for scancodes. It is wat is written after some keys are simultaneously pressed which is not about scan codes.

Hapax

  • Hero Member
  • *****
  • Posts: 3135
  • My number of posts is shown in hexadecimal.
    • View Profile
    • Links
Re: Scancodes Round 3 & Release Readiness
« Reply #11 on: May 16, 2023, 08:26:48 pm »
(Testing on windows 10 with a Wooting Lekker keyboard)

In the test app above, using the default auto mapping the R Sys key is mapped to the Menu key instead of RSystem. Both menu and rsystem do work correctly if manually mapped though.
Indeed. The "auto-fill" keys are setup for my own keyboard and my key there is the Menu key. I don't actually have a "right system" key on my current keyboard :(

I couldn't get printscreen to work in the app. It couldn't manually map it, it thought no key was being pressed.
But looking online I see that windows intentionally doesn't send keydown events for Printscreen, it only sends keyup. I tested in my own SFML 3.0 app and I do get the correct scancode for printscreen on keyup.
Is this a thing? Maybe I'll change it slightly to reflect keys that have been released as well.

I have tested in on Win10 and 2 keys map same.
left CTRK and right ALT  (Alt Gr) have same mapping 127.
It's worth checking with the pre-filled set. AltGr should be 133 but it also triggers a Control press (127). Using this test app, it's impossible to set a key to AltGr manually if the Control key event comes through first, which it seems to do during my tests.
This means that if you use 133 (Right Alt) in your own programs, it will recognise AltGr as being pressed but Control (127) will also be considered to be pressed.
If you want to track AltGr as a separate key, you might have to ignore Control events that happen at the same time - or just treat it as AltGr (which is Control + R Alt) instead of R Alt separately.

It's worth noting that I've already noticed and mentioned this issue to the team.
Selba Ward - SFML drawables
Kairos - Timing Library
Rectangular Boundary Collision - Rectangular SAT Collision

Hapaxia Links

kojack

  • Full Member
  • ***
  • Posts: 228
    • View Profile
Re: Scancodes Round 3 & Release Readiness
« Reply #12 on: May 17, 2023, 12:39:53 am »
I couldn't get printscreen to work in the app. It couldn't manually map it, it thought no key was being pressed.
But looking online I see that windows intentionally doesn't send keydown events for Printscreen, it only sends keyup. I tested in my own SFML 3.0 app and I do get the correct scancode for printscreen on keyup.
Is this a thing? Maybe I'll change it slightly to reflect keys that have been released as well.
I had searched around a bit, there are posts on places like stack overflow going back 12 years saying key down isn't sent by the printscreen key because Windows captures it, you need to use an input hook to intercept it. I also found a unity forum post about the same thing, Unity's input can't see printscreen key down.
I couldn't find any official info on it from microsoft.
Although this page from MS says Keyboard LANG1 and Keyboard LANG2 (scan codes 0x72 and 0x71) don't send key down events, only key up: https://learn.microsoft.com/en-us/windows/win32/inputdev/about-keyboard-input