This could possibly be used to determine the keyboard layout at runtime, allowing the game to properly set a default layout that makes sense at the very start, rather than having the user figure out what you actually intended from a layout that they may not even recognize. However, there are a fair amount of layouts around...
... so detecting them all reliably is probably really hard. Considering that this may apply to a lot of games out there, we might be able to reduce duplication and errors by providing this in FNA. My intention is to both reduce errors while also making it appealing to developers who would like to have this in their engine, potentially increasing the number of multinational-keyboard-friendly titles. Much like how operating system support is helpful in preservation, hardware support is equally important.
The question is, what keyboard layouts are really out there, and how do we support this without breaking our own API? We could in theory use an enum, but if we add more values that can actually break ABI compatibility, making it difficult to update the FNA DLL separately from the game itself (I learned this the hard way when making the Graphics enums XNA4-accurate). It may be better to just use const int8_t values, but that's not quite as readable (and it means having a lot of spec-breaking values rather than just one, in addition to the extra method).
I'd like to hear feedback on this, ideally from developers who have experience with shipping for multiple keyboard layouts.
This is tangentially related to issue #274, reported by @elisee, and the USE_SCANCODES build option found in SDL2_GamePlatform:
https://github.com/flibitijibibo/FNA/blob/master/src/SDL2/SDL2_GamePlatform.cs#L10
While talking to @AxiomVerge about keyboard layouts I remembered that there's an SDL2 function called SDL_GetKeyFromScancode:
https://wiki.libsdl.org/SDL_GetKeyFromScancode
This could possibly be used to determine the keyboard layout at runtime, allowing the game to properly set a default layout that makes sense at the very start, rather than having the user figure out what you actually intended from a layout that they may not even recognize. However, there are a fair amount of layouts around...
http://en.wikipedia.org/wiki/Keyboard_layout
... so detecting them all reliably is probably really hard. Considering that this may apply to a lot of games out there, we might be able to reduce duplication and errors by providing this in FNA. My intention is to both reduce errors while also making it appealing to developers who would like to have this in their engine, potentially increasing the number of multinational-keyboard-friendly titles. Much like how operating system support is helpful in preservation, hardware support is equally important.
The question is, what keyboard layouts are really out there, and how do we support this without breaking our own API? We could in theory use an enum, but if we add more values that can actually break ABI compatibility, making it difficult to update the FNA DLL separately from the game itself (I learned this the hard way when making the Graphics enums XNA4-accurate). It may be better to just use const int8_t values, but that's not quite as readable (and it means having a lot of spec-breaking values rather than just one, in addition to the extra method).
I'd like to hear feedback on this, ideally from developers who have experience with shipping for multiple keyboard layouts.