Discussion :

[dcmo5]

Pourquoi pas la SFML ?

Il y a un point positif pour la SFML : elle utilise la (bonne) fonction GetAsyncKeyState(), contrairement à SDL qui utilise la (mauvaise) fonction GetKeyState(). Malheureusement le code ne permet pas de distinguer LSHIFT et RSHIFT. De plus, l'état SHIFT est uniquement testé lors d'un évènement KEYUP ou KEYDOWN. Ca ne peut pas marcher dans le cas des deux touches SHIFT simultanées, à cause du bug (connu) de Windows : l'évènement KEYUP n'est pas généré pour une touche SHIFT si la deuxième reste enfoncée.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
00587         // Keydown event
00588         case WM_KEYDOWN :
00589         case WM_SYSKEYDOWN :
00590         {
00591             Event Evt;
00592             Evt.Type        = Event::KeyPressed;
00593             Evt.Key.Code    = VirtualKeyCodeToSF(WParam);
00594             Evt.Key.Alt     = GetAsyncKeyState(VK_RMENU)    || GetAsyncKeyState(VK_LMENU);
00595             Evt.Key.Control = GetAsyncKeyState(VK_RCONTROL) || GetAsyncKeyState(VK_LCONTROL);
00596             Evt.Key.Shift   = GetAsyncKeyState(VK_RSHIFT)   || GetAsyncKeyState(VK_LSHIFT);
00597             SendEvent(Evt);
00598             break;
00599         }
00600 
00601         // Keyup event
00602         case WM_KEYUP :
00603         case WM_SYSKEYUP :
00604         {
00605             Event Evt;
00606             Evt.Type        = Event::KeyReleased;
00607             Evt.Key.Code    = VirtualKeyCodeToSF(WParam);
00608             Evt.Key.Alt     = GetAsyncKeyState(VK_RMENU)    || GetAsyncKeyState(VK_LMENU);
00609             Evt.Key.Control = GetAsyncKeyState(VK_RCONTROL) || GetAsyncKeyState(VK_LCONTROL);
00610             Evt.Key.Shift   = GetAsyncKeyState(VK_RSHIFT)   || GetAsyncKeyState(VK_LSHIFT);
00611             SendEvent(Evt);
00612             break;
00613         }
00614

Finalement, toutes ces bibliothèques soi-disant portables ne le sont pas. Elles peuvent convenir pour une application bureautique simple, genre traitement de texte. En revanche, dans un émulateur, on doit avoir un contrôle précis du clavier. C'est très simple : chaque touche est un contact, il faut savoir si les contacts sont ouverts ou fermés. Peu importe ce qui est écrit sur la touche (A ou Q, Z ou W, 1 ou &). C'est sa position physique qui compte.

J'ai déjà perdu beaucoup de temps à tester des outils généraux qui ne marchent pas. Finalement j'irais beaucoup plus vite en écrivant une version du programme pour chaque plateforme : Windows, Unix et MacOS pour commencer. Dans mon émulateur, les fonctions spécifiques au système d'exploitation représentent moins de 5% du code, l'adaptation est donc très rapide.

Daniel

[loka]

Pour ce qui est de la SFML, elle est encore en développement et récente. C'est le responsable de cette rubrique (laurent gomila) qui l'a développé donc il est possible de lui parler de ton problème de distinguer les 2 touches shift.

Cependant si c'est le système d'exploitation qui ne permet pas cette fonctionnalité, je ne vois pas ce qu'on pourrais faire pour y remédier.

[dcmo5]

Cependant si c'est le système d'exploitation qui ne permet pas cette fonctionnalité, je ne vois pas ce qu'on pourrais faire pour y remédier.

- Windows permet de distinguer les deux touches SHIFT grâce à la fonction GetAsyncKeyState().
- Linux permet de distinguer les deux touches SHIFT (voir code de fearyourself).
- MacOS je ne sais pas.

Le problème n'est pas dans les systèmes d'exploitation, mais dans les bibliothèques SDL et SFML, qui ne savent pas bien tester les touches, au moins dans Windows.

Avec l'API Win32 les évènements WM_KEYDOWN sont bien générés. L'absence d'évènement WM_KEYUP pour une touche SHIFT quand l'autre est enfoncée nécessite une scrutation par GetAsyncKeyState(). C'est ce que je fais depuis toujours dans mes programmes Windows. Il suffirait de l'expliquer aux programmeurs de SDL et de SFML pour qu'ils corrigent leur code.

Il y a aussi d'autres subtilités dans Windows, en particulier la touche AltGr envoie deux évènements : un pour LCTRL et un autre pour RALT. C'est un piège qu'il faut habilement contourner, sinon les résultats sont très surprenants : par exemple AltGr-C génère un CTRL-C. Mon impression est que les développeurs de SDL sont à l'origine des utilisateurs de Linux et qu'ils connaissent mal la gestion du clavier dans Windows. Mais je peux me tromper...

Daniel

[loka]

Pour le gars qui développe SDL, maintenant il est très occupé chez blizzard, mais pour la SFML, il suffit de poster un message sur ce forum :

http://sfml.sourceforge.net/forum-fr/

Explique bien le problème comme tu l'as fais ici et je pense qu'il résoudra ça (enfin du moins il pourra au moins te donner une date pour la correction sans doute ^^).

[dcmo5]

On peut lire ceci dans le forum de SFML :

Laurent
Administrator
Inscrit le: 30 Mai 2007
Messages: 715
Localisation: Singapore

MessagePosté le: Sam Oct 06, 2007 3:32 am Sujet du message: Répondre en citant
Oui oui, je suis bien là et je prends note de toutes les remarques. Pour l'instant je n'ai pas d'ordinateur, donc je ne peux pas avancer.
_________________
Laurent Gomila - SFML developer


Funto
Inscrit le: 19 Aoû 2007
Messages: 12

MessagePosté le: Sam Oct 06, 2007 3:10 pm Sujet du message: Répondre en citant
Ok, no pb , tu n'as pas à être à temps plein sur la SFML que je sache ! ^^

Je voulais juste m'assurer que le support des touches Ctrl et Alt (et Maj tant qu'à faire ^^) sera assuré pour la prochaine version, pour savoir si je dois continuer avec la SFML pour notre (ouep on est plusieurs ^^) projet de jeu vidéo ou pas

Notez la date des messages : il n'y a pas de réponse depuis le 6 octobre sur le support des touches Ctrl, Alt et Maj
Les problèmes des touches SHIFT simultanées, de la touche AltGr, et aussi l'appui simultané sur plus de trois touches, sont beaucoup plus subtils. J'ai l'impression de perdre mon temps en postant, donc je vais m'abstenir.

Ce sont pourtant des sujets intéressants, vu le nombre de problèmes qu'ils posent aux développeurs (pour corriger des bugs) et aux utilisateurs (qui subissent les bugs non corrigés). Au hasard de recherches voilà ce que j'ai trouvé :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
//========================================================================
// GLFW - An OpenGL framework
// File:        win32_window.c
// Platform:    Windows
// API version: 2.5
// Author:      Marcus Geelnard (marcus.geelnard at home.se)
// WWW:         http://glfw.sourceforge.net
//------------------------------------------------------------------------
// Copyright (c) 2002-2005 Marcus Geelnard
//
 
....
 
            // Here is a trick: "Alt Gr" sends LCTRL, then RALT. We only
            // want the RALT message, so we try to see if the next message
            // is a RALT message. In that case, this is a false LCTRL!
            msg_time = GetMessageTime();
            if( PeekMessage( &next_msg, NULL, 0, 0, PM_NOREMOVE ) )
            {
                if( next_msg.message == WM_KEYDOWN ||
                    next_msg.message == WM_SYSKEYDOWN )
                {
                    if( next_msg.wParam == VK_MENU &&
                        (next_msg.lParam & 0x01000000) &&
                        next_msg.time == msg_time )
                    {
                        // Next message is a RALT down message, which
                        // means that this is NOT a proper LCTRL message!
                        return GLFW_KEY_UNKNOWN;
                    }
                }
            }

RE: [BUG] Shift key not released

* From: Harold L Hunt <huntharo at msu dot edu>
* To: cygwin-xfree <cygwin-xfree at cygwin dot com>
* Date: Fri, 07 Jun 2002 08:54:44 EDT
* Subject: RE: [BUG] Shift key not released

Stuart,

Actually, my fix for this was a little easier. All I did was enter a fixup
for the non-extended VK_SHIFT... I set the fixup to KEY_ShiftL.

That seemed to take care of the problem.

Harold

Stuart Adamson <stuart.adamson@evolution.net> said:

> It appears that windows isn't sending us a WM_KEYUP message for the release
> of
> the first shift key.
>
> Maybe what we need to do is to call GetKeyState() when we see a shift key
> release
> and fake a release of the other key if required (can use the key state table
> in my
> patch yesterday to see if we think the other shift key is still down).
>
> Stuart
>
> > -----Original Message-----
> > From: Jehan [mailto:jehan_something@hotmail.com]
> > Sent: 07 June 2002 01:12
> > To: cygwin-xfree
> > Subject: [BUG] Shift key not released
> >
> >
> > Hi again,
> >
> > I know that this bug has already been mentionned (April 18
> > from bkarnd)
> > but there hasn't been much followup so I would like to know
> > what is the
> > status on it:
> >
> > 1. press and hold both shift at the same.
> > 2. release one of them (lets call it shift1)
> > 3. release the other one.
> > 4. press a letter: notice that you get the capitalize version (or, if
> > capslock is on, the lowercase one).
> > 5. press and release shift1.
> > 6. press a letter: now you get the correct case.
> >
> > Jehan
> >
>

Ce lien prouve que le problème des touches SHIFT simultanées touche aussi les MacIntosh.

Avec Google on peut trouver des centaines d'autres exemples du même type, et pas seulement avec Windows et SDL. Je suis surpris d'être le seul à chercher une solution.

Daniel

[Laurent Gomila]

Notez la date des messages : il n'y a pas de réponse depuis le 6 octobre sur le support des touches Ctrl, Alt et Maj

Ce problème a été réglé il y a longtemps ; j'ai peut-être juste oublié de le signaler sur le forum. Ceci-dit il y a maintenant la roadmap pour voir ce qui évolue.

Je serais ravi d'avoir tes retours concernant les éventuels problèmes avec les touches ; je ne peux pas tester tous les cas de figure moi-même et j'ai donc besoin du retour des utilisateurs pour améliorer la bibliothèque

Et ne t'inquiète pas tu ne perds pas ton temps, ma priorité est bien de corriger les problèmes rencontrés par les utilisateurs, avant d'avancer sur les nouvelles fonctionnalités.

[dcmo5]

Finalement j'ai trouvé le contournement

Dans la version Windows du programme SDL, j'ai ajouté un include de windows.h et je peux donc appeler la fonction GetAsyncKeyState().

Pour scruter la position des touches SHIFT, j'utilise la routine audio.callback = Playsound. Dans dcmo5, les paramètres audio sont : audio.freq = 22050 et audio.samples = 1024, donc Playsound est appelée un peu plus de 20 fois par seconde, ce qui est largement suffisant.

GetAsyncKeyState(VK_LSHIFT) et GetAsyncKeyState(VK_RSHIFT) me donnent la bonne position des touches SHIFT. Je la stocke dans le tableau représentant l'état du clavier, et le tour est joué. Au passage j'ai ajouté les tests des touches VK_LCONTROL, VK_RCONTROL et VK_LMENU, VK_RMENU, car même si je ne les utilise pas simultanément, ça permet de masquer le bug de SDL sur les SDL_KEYDOWN et SDL_KEYUP de AltGr.

Bien entendu les puristes pourront protester qu'appeler une fonction windows dans un programme portable n'est pas très intelligent. Mais pour d'autres raisons (scancodes) j'ai déjà été obligé de faire des traitements différents en fonction du système d'exploitation, donc ce n'est pas grave. Et surtout le résultat est excellent.

Voilà, je suis très content d'avoir trouvé, et je vous remercie pour votre aide. Je considère le sujet résolu (pour moi). En revanche, il est loin d'être résolu pour les développeurs de SDL.

Daniel

[shenron666]

Bien entendu les puristes pourront protester qu'appeler une fonction windows dans un programme portable n'est pas très intelligent.

sauf que un programme portable, s'il veut tourner sous windows, il faut qu'il contienne du code windows
le tout étant de bien délimiter le code avec des options de compilation #define #ifdef etc...

tu devrais peut-etre parler de ta correction à l'auteur de la SDL
histoire que ça soit inclus dans les versions futures

[dcmo5]

tu devrais peut-etre parler de ta correction à l'auteur de la SDL histoire que ça soit inclus dans les versions futures

La gestion du clavier dans la SDL est une véritable catastrophe. Je crois que les auteurs en sont conscients mais ne veulent rien faire. Il faudrait parler des scancodes différents pour le même clavier en fonction du système d'exploitation, des touches système, de l'appui simultané sur deux touches SHIFT ou CTRL ou ALT, de l'appui simultané sur plus de trois touches normales, et bien d'autres bugs encore car je n'ai pas tout testé.

D'après des discussions lues ailleurs, j'ai vu qu'ils préparent une amélioration pour la version 1.3, mais je doute que tous les problèmes soient résolus. La gestion du clavier a toujours été une plaie pour les développeurs et je n'ai aucun espoir de résolution définitive.

Quelques citations de leur groupe de discussion :

From: Sylvain Beucler <beuc <at> beuc.net>
Subject: Portable keycodes?
Newsgroups: gmane.comp.lib.sdl
Date: 2007-08-18 19:22:04 GMT (12 weeks, 11 hours and 39 minutes ago)

Hi,

I just ran some keycodes tests with 2 platforms (W2K and X11) and 2
keyboard layours (US and French).

My question is: is there a way to get consistent keycodes across
platforms with SDL? For example, I'd like to use the 0-9 digits
(those in the top line of the keyboard) the same way whatever the OS
and whatever the keyboard layout. E.g. in Duke Nukem 3D and most FPS
that's how you select weapons.

The main problem is that under X11, SDL_sim returns essentially the
same thing than the SDL unicode field.

I think the DirectX keycodes or the xev "keycode" field (see below)
are a good thing: they do not rely on the current keyboard mapping,
they always refer to the same physical location on the keyboard (from
what I can tell). For games, the physical location of the key is what
matters. If the application needs to get the actual letters, not the
keys, the unicode field is already perfect.

Any clue?

-----

Here are the tests:

Background: on a French keyboard:

- Q and A are swapped.

- Pressing 2 gives a E+accent (é), you need Shift+2 to get the
digit. That's similar for 0-9.

Properly naming the keys:
- US-Q == "top-left letter" - Q for QWERTY
- US-2 == "first line, 3rd key with a '2' on it" - 2 for QWERTY

Now for the tests:

SDL - X11 - SDL_sim or Unicode:
EN
US-Q -> 113 'q'
US-2 -> 50 '2'
FR
US-Q -> 97 'a'
US-2 -> 233 'world 73'

-> What was typed as text, without caps
The only difference I see between SDL_sim and Unicode is when using
dead keys (such as ^+a).

SDL - W2K - SDL_sim (are those DirectX keycodes?):
EN
US-Q -> 113 'q'
US-2 -> 50 '2'
FR
US-Q -> 113 'q'
US-2 -> 50 '2'

-> Always US

SDL - W2K - Unicode:
EN
US-Q -> 113 'q'
US-2 -> 50 '2'
FR
US-Q -> 113 'q'
US-2 -> 233 'world 73'

-> What was typed as text, without caps

(W32API - GetAsyncKeyState - for reference)
EN
US-Q -> 81 'Q'
US-2 -> 50 '2'
FR
US-Q -> 65 'A'
US-2 -> 50 '2'

Digits -> Always US
Letters -> Locale, with caps
Rest -> Huge mess
-> Don't use

(xev - X11 - for reference)
US-Q - US
KeyPress event, serial 30, synthetic NO, window 0x3800001,
root 0x47, subw 0x0, time 2051508871, (217,167), root232,263),
state 0x0, keycode 24 (keysym 0x71, q), same_screen YES,
XLookupString gives 1 bytes: (71) "q"
XmbLookupString gives 1 bytes: (71) "q"
XFilterEvent returns: False

KeyRelease event, serial 30, synthetic NO, window 0x3800001,
root 0x47, subw 0x0, time 2051508955, (217,167), root232,263),
state 0x0, keycode 24 (keysym 0x71, q), same_screen YES,
XLookupString gives 1 bytes: (71) "q"

US-Q - FR
KeyPress event, serial 26, synthetic NO, window 0x3800001,
root 0x47, subw 0x0, time 2051433631, (794,532), root809,628),
state 0x0, keycode 24 (keysym 0x61, a), same_screen YES,
XLookupString gives 1 bytes: (61) "a"
XmbLookupString gives 1 bytes: (61) "a"
XFilterEvent returns: False

KeyRelease event, serial 29, synthetic NO, window 0x3800001,
root 0x47, subw 0x0, time 2051433692, (794,532), root809,628),
state 0x0, keycode 24 (keysym 0x61, a), same_screen YES,
XLookupString gives 1 bytes: (61) "a"

US-2 - US
KeyPress event, serial 30, synthetic NO, window 0x3800001,
root 0x47, subw 0x0, time 2051576843, (72,33), root87,129),
state 0x0, keycode 11 (keysym 0x32, 2), same_screen YES,
XLookupString gives 1 bytes: (32) "2"
XmbLookupString gives 1 bytes: (32) "2"
XFilterEvent returns: False

KeyRelease event, serial 30, synthetic NO, window 0x3800001,
root 0x47, subw 0x0, time 2051576896, (72,33), root87,129),
state 0x0, keycode 11 (keysym 0x32, 2), same_screen YES,
XLookupString gives 1 bytes: (32) "2"

US-2 - FR
KeyPress event, serial 31, synthetic NO, window 0x3800001,
root 0x47, subw 0x0, time 2051594850, (284,365), root299,461),
state 0x0, keycode 11 (keysym 0xe9, eacute), same_screen YES,
XLookupString gives 2 bytes: (c3 a9) "é"
XmbLookupString gives 2 bytes: (c3 a9) "é"
XFilterEvent returns: False

KeyRelease event, serial 31, synthetic NO, window 0x3800001,
root 0x47, subw 0x0, time 2051594934, (284,365), root299,461),
state 0x0, keycode 11 (keysym 0xe9, eacute), same_screen YES,
XLookupString gives 2 bytes: (c3 a9) "é"

-> The "keycode" field is constant

--
Sylvain

Et voici la réponse (abrégée) :

From: Alissa Sabre <alissa_sabre <at> yahoo.co.jp>
Subject: Re: Portable keycodes?
Newsgroups: gmane.comp.lib.sdl
Date: 2007-08-19 11:59:46 GMT (11 weeks, 6 days, 19 hours and 14 minutes ago)

> My question is: is there a way to get consistent keycodes across
> platforms with SDL?

I don't think you can get the keycode with the feature you want.

....

I don't think it is the way SDL is to go.

--------------------------------------

Une autre citation pour montrer que le problème n'est pas limité à Windows :

From: Max Horn <max <at> quendi.de>
Subject: Problems with keymapping on AZERTY keyboards on Mac OS X
Newsgroups: gmane.comp.lib.sdl
Date: 2007-06-27 11:13:26 GMT (19 weeks, 3 days, 20 hours and 4 minutes ago)

Hi folks,

some of our Mac OS X users are having problems with ScummVM <http://
www.scummvm.org> running on a machine with an AZERTY keyboard, a
layout that is standard in many french-speaking countries (France and
Belgium for example). The tricky thing about that keyboard layout is
that in it the "number row" differs considerably from that on a
QWERTY keyboard.In particular, the key which "normally" is labeled
"1" instead is labeled "&", and to get a "1" you have to press "Shift-
&", i.e. the opposite of a what happens in "normal" keyboard layouts.
To see what I mean, see here: <<http://en.wikipedia.org/wiki/AZERTY>.

Now, we offer our users certain hotkeys, among them are the Ctrl-
NUMBER and Alt-NUMBER hotkeys (for quick saving/loading). No issue,
you might say now -- just use the keysym and be done with it, it
should return "1" for that key on AZERTY, too.

However, this is not the case on Mac OS X, due to some "clever" code
which tries to correct the default hard-coded keymap to accommodate
for non-US keyboards. The idea for adding that code back then (I was
involved in that) was to compensate for changed letter key positions
on non-QWERTY keyboards. For example I am using a QWERTZ keyboard
where y and z are swapped. That code in the Mac OS X variant of SDL
makes sure the keysyms for these two keys are swapped, too.

Why doing so? Because the purpose of keysyms is not completely well-
defined in SDL (and I think Sam is aware of that and maybe 1.3 will
improve in that regard). There are two different roles it tries to
support: One is to represent the symbol that is printed on the key
(which is what the OS X port currently tries to do). The other is to
represent the "position" of the key (so you don't care whether the
key between "t" and "u" is labeled "y" or "z", you you always want
SDLK_y, meaning "the key between t and u").

Both functions have their merits, depending on what you are trying to
do, I guess... But at least for AZERTY keyboards, the fact that
pressing the "& resp. 1" key generates not a SDLK_1 keysym, but
rather SDLK_AMPERSAND. As a result, the above-mentioned quick save/
load hotkeys don't work for those users. (see also ScummVM bug report
#1643848, "MACOSX: Unable to save/load using numbers on AZERTY
keyboard", <https://sourceforge.net/tracker/index.php?
func=detail&aid=1643848&group_id=37116&atid=418820>)

My question now is: How should I resolve this "best" ? Several
possibilities come to mind. But I am not sure which to choose, and
maybe I am also missing some possible solutions. Finally, it would be
interesting to know how other SDL ports (e.g. on Windows on Linux)
behave in this regard, to make sure we get uniform behavior across
ports). My ideas so far:

1) Do not remap the keysyms for the keys in the number row, like "1/
&". The attached patch does that. It's simple, but is it "the right
thing" to do? Are there maybe keyboard layouts where this produces
bad results? Is there any code that will suffer from it

2) Don't perform any of the "remap to try to accommodate for
international keyboard" voodoo, i.e. get rid of the "KCHRPtr" code in
src/video/quartz/SDL_QuartzEvents.m

3) Call SDL's behavior "correct" and somehow fix the problem inside
of ScummVM. Maybe by allowing the user to define a custom remapping,
defining "quicksave to slot 1" as "Alt-&"

4) Tell our users to use Ctrl/Alt+KEYPAD -- although of course not
all machines *have* a numerical keypad :/

5) ... ? Your idea here :-)

Cheers,
Max

J'arrête les citations, il y en a plusieurs dizaines du même type. Les développeurs de la SDL ne veulent pas comprendre ce besoin très simple des programmeurs : un clavier est composé de touches. Chaque touche est un contact. Nous voulons savoir si ce contact est ouvert ou fermé.

Avec la SDL, vous n'aurez jamais la bonne réponse. Et le roadmap de la version 1.3 ne me donne aucun espoir.

Daniel

[fearyourself]

Effectivement, c'est un problème connu et comme toujours dépendant de ce qu'on veut faire, la SDL est une bonne solution ou non. Dans ce cas présent, je dirais que ce n'est pas le cas.

Par contre, dans beaucoup d'autres cas, je le conseille toujours et encore,
Jc

[dcmo5]

Effectivement, c'est un problème connu et comme toujours dépendant de ce qu'on veut faire, la SDL est une bonne solution ou non. Dans ce cas présent, je dirais que ce n'est pas le cas.

Je ne vais pas jusque là, car finalement je garde la SDL pour tout ce qu'elle apporte sur l'affichage et les autres évènements. En revanche pour une maîtrise du clavier il faut écrire ses propres fonctions dépendantes du système, et ne pas compter sur les évènements et les fonctions clavier de la SDL.

Daniel

[fenkys]

Tu peux aussi modifier la SDL et poster la correction au mainteneur de la lib pour que la correction sont mise en place dans une prochaine version.