Discussion :

[kripteks]

Salut à tous.
J'aimerais détecté les inputs de clavier et souris sous linux.

Je sais que x11/xlib m'offre cet possibilité, mais j'aimerais gérer cela en dehors de x11/xlib (et bien entendu des bibliothèque plus haut niveau).

Et surtout rester en c++.
Plus je veux quelque chose de bas niveau plus je me trouves avec des outils en C et sa me soul, à savoir si on doit réécrire tout en c++. À ce rythme je crois que je vais apprendre et utiliser le C une bonne fois pour toute.


Avez vous des conseils sur le sujet (et/ou le langage sans troller et rester dans l'environ du sujet) ?

[Joker-eph]

Si vraiment tu ne veux pas appeler du C (c'est vraiment si pénible ??), tu peux peut-être regarder du côté des wrapper sur ncurses, par exemple : http://sourceforge.net/projects/ndk-xx/

[Bousk]

BOnjour,

sache que la très grande majorité (pour ne pas dire la totalité ?) des API bas niveaux sont en C, pour leur portabilité entre les systèmes et leur réusabilité entre les langages au-dessus.

[kripteks]

Mon but est situé dans un niveau moyen: une application qui va utiliser de l'opengl sans dépendre d'autres bibliothèques.
J'aimerais ajouter les inputs clavier/souris, puis m'attaquer à l'affichage le plus bas possible sans avoir un environnement graphique ouvert.

Je pourrais bien utiliser le C dans mes projets (bien que je connais pas le langage au point d'en programmer).
Mais j'aimes pas l'idée de programmer du C dans mes projets en C++.

Je vois pas d'autres solution, je vais m'y mettre en C.

[Bousk]

Pour travailler avec OpenGL, le fenêtrage le plus simple que j'ai trouvé et qui me satisfait pour les évènements liés est glfw

On ne parle pas de programmer en C mais d'inclure du code en C, ou plutôt d'en appeler.

[kripteks]

Salut à tous et encore merci pour vos réponses.
J'avais bien compris d'inclure le C.

Sinon, pensez vous qu'il est bien d'inclure du C dans un projet C++, y a t il des avantages/inconvénients ?

Pourrais-je manipuler facilement ces codes C inclus dans mon projet C++ ?

[Kalith]

OpenGL c'est déjà du C, à la base. Donc comme tu peux le constater, on peut tout à fait utiliser du code C dans du code C++. Ce n'est pas "mal", c'est juste un peu pénible parfois.

Maintenant il existe une tonne de bibliothèque C++ qui permettent d'encapsuler tous les appels au code C avec des classes et autres concepts propres au C++. Certaines ont plus ou moins de dépendances... Pour encapsuler OpenGL par exemple, tu as la SFML (en plus c'est made in France!), mais d'un côté c'est peut être déjà trop pour ce que tu veux faire (dépend de Freetype pour afficher du texte, de libjpeg pour charcher les images JPEG, etc.), ou alors pas assez, dans le sens où il faut revenir aux appels OpenGL pour faire de la 3D. Dans le genre plus complet, tu as Ogre3D (qui supporte aussi DirectX), mais là le nombre de dépendance monte en flèche... Et tu peux oublier tout ce que tu sais sur OpenGL : Ogre3D a sa propre manière de faire les choses, et le niveau d'abstraction est parfois très élevé (on a du mal à prévoir quels vont être les appels OpenGL sous le capot).

Le soucis, c'est que l'interface d'OpenGL est très permissive et elle fait assez peu d'hypothèse sur les données qu'on traite et les opérations qu'on veut faire dessus : on peut vraiment tout faire avec. Essayer de faire rentrer ça dans une interface objet à la C++ est difficile, et on se retrouve souvent à brider les possibilités offertes par OpenGL, ou à avoir un surcoût en performance du fait qu'on veut essayer de traiter tous les cas possibles sans pouvoir se spécialiser (ou alors à grand frais : il faut bien connaître l'API objet pour savoir comment rajouter une fonctionnalité, et bien connaître Ogre3D par exemple, c'est pas du gâteau...).

Donc à mon sens, si on ne veut pas faire du code trop haut niveau comme ça a l'air d'être ton cas, le mieux est de trouver ou d'écrire sois-même un petit ensemble de classes qui vont gérer les ressources OpenGL automatiquement (l'exemple typique étant celui des textures, avec le couple glGenTextures et glDeleteTextures, les shaders, ou encore les fenêtre avec GLFW que je recommande aussi), mais guère plus. De ce point de vue là, la SFML est presque parfaite, mais ce n'est pas qu'un simple wrapper autour d'OpenGL, et donc on se traîne potentiellement des fonctionnalités/dépendances dont on peut ne pas avoir besoin (le texte, les JPEG, etc), et une interface taillée pour la 2D. Après, le code est open source, simple, et plutôt bien écrit : tu peux ne garder que ce qui t'intéresse et rajouter ce qui te manque (à condition de respecter les termes de la licence en matière de redistribution du code source modifié). Ça ne devrait pas être trop dur je pense.

Enfin, un autre avantage de la SFML est qu'elle dispose aussi d'une interface (cross-platform, n'utilisant que des appels systèmes) pour créer une fenêtre et gérer l'input clavier/souris/joystick. A priori, tu peux obtenir l'input sans avoir de fenêtre ouverte, mais à vérifier (cf. la documentation).

Bon courage !