- la répétition du clavier entraine des à coups dans l'émulation: accélération, ralentissement, blocage, reprise. Impossible de tester un jeu en développement, les déplacements/animations crapotent, gameplay injouable/intestable. Même observation dans Wizord aussi (ou toute autres application), on voit nettement le vaisseau contrôlé faire des bonds. Idem sous Exelbasic en maintenant une touche, ça saccade (sans parler des touches à renfoncer, blocage, utiliser le clavier devient une prouesse en édition). Aucun soucis dés qu'aucune touche n'est enfoncée.
- La gestion du retour VBL dysfonctionne: il ralentie énormément la machine lorsqu'on le teste pour gérer un affichage, par exemple basculement entre deux buffers (double buffering)... plus de 10 fois plus lent que sans VBL (???)
Ces problèmes n'apparaissent pas sur vrai Exl100: répétition de touche sans impact sur la vitesse et aucune saccade, peu ou pas de blocage de touches, VBL marche normalement en imposant la fréquence de balayage sur l’affichage/animation.
Le problème de la répétition de touche n'apparait pas dans dcexel 2010 (version 13102010 par exemple), Bug VBL toujours présent (mais moins prioritaire).
A noter aussi une régression sur le réalisme dans l'affichage: sans contrôle VBL on peut avoir des cassures de l'image pendant les redraws... on l'observe sur Exl100 et sur dcexel 2010, mais plus sur dcexel2012 qui conserve une image parfaite ou presque dans tous les cas... très gênant dés lors qu'on désire mettre au point des moteur de jeux/démos, la encore le teste sur machine réelle devient vite rédhibitoire.
Imaginons q'une petite équipe développe un jeu d'action/platforme pour Exl100 et pas un éternel jeu d'aventure à deux de tension... et bien ils pourraient(voir sont) très embêtés. Le Pb de gestion du clavier est une régression majeure qui impacte toutes les applications. Retour à la version 2010, je ne me souviens plus les correctifs internes depuis qui pourraient faire apparaitre de faux bugs (pas les améliorations grand public) ?

