[C++/classe utilitaire] Stk Input

Ayant développé une petite classe qui m'est pas mal utile en dev de jeux en C++, et étant de bonne humeur aujourd'hui, j'ai décidé que j'allais partager ça avec le monde :)

Stk Input 1.1

C'est quoi ?

C'est une simple classe C++ nommée Input qui a pour but d'interfacer l'entrée utilisateur d'une façon non-évènementielle (comme GM) en récupérant les données de façon évènementielle. Elle permet de stocker l'état des boutons (de façon générique, ça marche pour la souris, le clavier, la manette ou autre), le focus et la position actuelle et précédente du curseur/de la souris.

Pourquoi avoir fait cette classe ?

Alors voyez-vous, j'utilise pour mes jeux la SFML (que ce soit avec ou sans OpenGL), et la SFML permet de récupérer l'entrée utilisateur de deux façons: de façon évènementielle (sf::Event) et directe (sf::Mouse, sf::Keyboard...). Le soucis, c'est qu'étant un ancien de GM, je suis habitué et je sais mieux faire avec des appels directs, hors les classes "directes" de la SFML sont assez limitées a ce niveau (on ne peut faire que l'équivalent GM de keyboard_check(...) et mouse_check_button(...)) et ça ne satisfaisait pas mes besoins. Donc j'ai codé une classe (celle-ci) qui me permettait, à partir des données évènementielles de sf::Event (qui en plus prenaient en compte le focus de la fenêtre), de faire des appels directs depuis n'importe-où, et ce de façon plus sécurisées et complètes que les classes de base. Depuis j'ai modifié la classe pour qu'elle soit plus flexible et ajouté le support des positions de la souris.

Avec quoi fonctionne cette classe ?

A la base, la classe a été pensée pour la SFML, mais sa généricité permet la compatibilité avec toute forme de lib fonctionnant de façon évènementielle, comme par exemple l'API Win32, la SDL, Qt, WxWidgets etc...
Oui, des gens font des jeux avec Qt.

Quels sont les prérequis ?

Un compilo C++ et la classe std::queue. La classe ne repose que sur ça. C'est tout. Vraiment.

Tour rapide.

Cliquez ici:

Pour plus de documentation, il faut se fier au doxygen (en anglais).

Liens.

• [7z] Télécharger la classe (.h et .cpp)
  
• [7z] Télécharger l'exemple avec la SFML (sans la classe)
  
• Voir la documentation générée par Doxygen (anglais)
  

Et après ?

La classe est fonctionnelle, mais elle n'est peut-être pas complète ou optimale. Je suis ouvert aux idées que vous pouvez me donner, et si ça me plaît je pourrait implémenter ça en plus. Toute critique constructive est aussi la bienvenue.

Peut-être que je posterais d'autres petits utilitaires que j'utilise pour mon/mes projets ici, mais pour l'instant ça sera tout.

Stk = the Stan ToolKit, un nom que je met dans tous les petits trucs qui sont fait pour être portables. Stan c'est mon prénom :D

Pas grand chose a redire au niveau de l'utilisation.
Pour ma part j'aurais plutôt opté pour des fonctions globales dans un namespace, plutôt que des méthodes statiques (ce qui oblige toujours a utiliser le préfixe Input:: ).

J'aurais aussi pris des choix de noms de fonctions un peu plus courts pour buttonCheckPressed et buttonCheckReleased, genre direct buttonPressed et buttonReleased.

Une petite documentation doxygen ferait pas de mal non plus, étant donné que plusieurs fonctions ne sont pas vraiment explicites.
Genre reportButtonPress & co, on a du mal a se faire une idée de l'utilité sans doc.


Sinon, niveau syntaxe du code je suis pas du tout fan des __ en préfixe. Ça casse pas mal la lisibilité du code je trouve.
Par exemple dans la STL c'est une horreur...
Mais bon après j'imagine que c'est une question d'habitude, y en a bien qui mettent des this-> partout

Merci des conseils.

Ducoup j'ai renommé quelques méthodes pour les rendres plus courtes et/ou plus explicites ainsi que fait une doc. C'est long a faire une doc. (liens mis a jour dans le premier post).

Perso moi j'aime bien les _ pour séparer les membres aux arguments. Mais il est vrai que __instance._x tout le temps c'est pas simple, même pour moi. Donc je pense que je vais devoir me défaire du singleton, là ça sera mieux (plus tard).

Pour le truc du namespace on verra plus tard aussi.

Pour distinguer les attributs des membres c'est dommage que la plupart des IDE ne proposent pas une coloration syntaxique differente.
Je sais plus si Qt Creator le fait btw.

Qt Creator le fait très bien (et j'utilise Qt Creator), c'est plus pour que je puisse utiliser les mêmes noms. Parce-que j'ai tendance a faire des getters sans get devant (par exemple).

Ah ouai, perso j'ai pas encore trouvé ma syntaxe de prédilection a ce niveau.
Pour l'instant je me contente des fameux m_attrib, mais je trouve ça presque aussi moche que _attrib tout court...
Un jour, j'aurais peut être la révélation


Ptetre un truc genre pAttrib... Yéssaispas.

J'ai pas encore regardé le code, mais les double-underscore dans les identifiants sont formellement interdits en-dehors de l'implémentation de std, de même que les underscore-majuscule en préfixe et les underscores en préfixe au scope global. C'était votre interlude standard C++ !

J'ai fait exactement la même chose dans mes codes, mais je l'ai pas posté :/