Programme Multi-plateforme et OpenGL

Bonsoir,

Avec des amis nous avons développé un programme en Java avec un serveur en mode texte et un client qui utilise Nifty et JmonkeyEngine pour avoir un rendu 3D des calculs qui sont fait en réseau.

Toujours est-il que même en optimisant notre code et en multi-threadant au maximum il y a des lags qui sont du à Java... On lui en demande peut être un peu trop.

Du coup, on recherche à savoir si on peut développer de manière Multi-plateforme un serveur et un client en C++ pour Windows, Mac et surtout Linux. Cela amène plusieurs questions :

- Peut-on compiler nos sources C++ de manière transparente sur les différentes plates formes ?
- Quels moteurs 3D OpenGL conseillerez-vous ?
- Quels GUI me proposez-vous ?
- Existe-il une surcouche haut niveau des Socket en C++ ? Comme RMI par exemple.

Je sais que Qt est "multiplateforme", ou en tout cas supporte les différents systèmes.

J'attends vos conseils.

Merci d'avance.

Bonjour

A partir du moment où tu fais du code standard, il compilera sans problème sur les différentes plateformes. En général, les problème de compatibile arriveront si tu utilises des bibliothèques non portable (par exemple, utiliser system() ou utiliser les fonctions win32 ou utiliser les MFC, etc.)
Avec Qt, tu n'auras pas de problème normalement. De plus Qt fournit les outils pour OpenGL (voir là http://gbelz.developpez.com/remi-ach...vance-avec-qt/), pour le réseaux, etc. De plus, si tu veux utiliser un moteur plus avancé que OpenGL, tu peux intégrer d'autres moteur dans Qt (par exemple avec Ogre : http://irmatden.developpez.com/tutor...ation-ogre-qt/)
Tu peux même t'amuser à compiler vers toutes les plateformes d'un coup avec la cross compilation sous linux (http://mtodorovic.developpez.com/lin...ss-compil-qt4/) ou par exemple utiliser cmake pour compiler, enpaqueter et deployer automatiquement

Citation:

---

Envoyé par akrogames

- Peut-on compiler nos sources C++ de manière transparente sur les différentes plates formes ?

---

Tant que tu fais attention a ce que tu fais oui. Le langage est bien standard, mais il existe de nombreux moyens de casser la compatibilité, notamment en utilisant une lib typique d'un OS. Le meilleur moyen pour évite ca, c'est une bibliothèque qui fournit de manière portable pas mal de trucs dont on a besoin de tout le temps : thread, fenetrage, mesure du temps...
Pour ca, Qt, SDL, SFML par exemple seraient pas mals.

Citation:

---

Envoyé par akrogames

- Quels moteurs 3D OpenGL conseillerez-vous ?

---

Ca dépend de ton usage. Tu as Ogre, crystal space, Open scene graph par exemple.

Citation:

---

Envoyé par akrogames

- Quels GUI me proposez-vous ?

---

Ca dépend quel genre de GUI. Qt, GTK pour une GUI standard, crazy eddie's gui ou GuiChan pour une GUI en opengl.

Citation:

---

Envoyé par akrogames

- Existe-il une surcouche haut niveau des Socket en C++ ? Comme RMI par exemple.

---

Surement, mais la je connais moins bien.

Citation:

---

Envoyé par akrogames

Je sais que Qt est "multiplateforme", ou en tout cas supporte les différents systèmes.

---

En effet, Qt est une des bonnes options. Mais il ne te fournira pas une interface de haut niveau par dessus opengl, ni de GUI en opengl. C'est idéal si tu veux un widget 3D dans une fenêtre qui contient d'autres widgets graphiques.
Si tu veux une fenetre opengl avec une GUI dedans, il vaut mieux SDL ou SFML combiné avec un moteur opengl.

Citation:

---

Envoyé par Rewpparo

En effet, Qt est une des bonnes options. Mais il ne te fournira pas une interface de haut niveau par dessus opengl, ni de GUI en opengl. C'est idéal si tu veux un widget 3D dans une fenêtre qui contient d'autres widgets graphiques.
Si tu veux une fenetre opengl avec une GUI dedans, il vaut mieux SDL ou SFML combiné avec un moteur opengl.

---

En fait, si. Il est tout à fait possible d'utiliser l'accélération matériel avec OpenGL pour l'ensemble des widgets de Qt. J'en ai parlé sur mon blog récement : OpenGL dans Qt5

Je connais pas assez la SDL et la SFML, mais j'ai pas l'impression qu'il manque de fonctionnalités dans Qt par rapport à ces bibliothèques. Pour les moteurs 3D (Ogre, etc.) Qt ne propose pas (encore) d'équivalent. Mais ça va changer avec Qt 5 et le module Qt3D ;) (mais il faudra quand même du temps pour que Qt soit aussi aboutie que les moteurs 3D plus anciens, forcement)

J'ai hâte de voir le moteur 3D Qt !
Sinon avec Qt peux tu avoir des widgets skinés (pas juste les couleurs, mais utiliser des images pour faire les widgets ? Je pense typiquement au menu jeu vidéo.
Peux tu avoir des widgets au milieu d'un dessin opengl, voire avec de la transparence ?
et une dernière, pour moi : est il possible d'incruster des widgets Qt dans une fenêtre opengl existante ?

Citation:

---

Envoyé par Rewpparo

J'ai hâte de voir le moteur 3D Qt !

---

Facile : http://labs.qt.nokia.com/2012/04/11/...-and-releases/
http://doc.qt.nokia.com/qt-quick3d-snapshot/index.html
Tu peux même installer Qt5 et tester tout de suite Qt3D : http://www.developpez.net/forums/d12...ie-qt-5-alpha/

Citation:

---

Envoyé par Rewpparo

Sinon avec Qt peux tu avoir des widgets skinés (pas juste les couleurs, mais utiliser des images pour faire les widgets ? Je pense typiquement au menu jeu vidéo.
Peux tu avoir des widgets au milieu d'un dessin opengl, voire avec de la transparence ?
et une dernière, pour moi : est il possible d'incruster des widgets Qt dans une fenêtre opengl existante ?

---

Oui pour toutes les questions. Le plus simple est d'utiliser QtQuick et le module QtComponent dans une vue QGLWidget. Dans Qt5, ça sera encore plus simple, QtQuick2 est déjà intégré dans OpenGL par défaut.

Le point qu'il faut bien comprendre, c'est que lorsque Nokia a racheté Qt, il a misé beaucoup sur l'embarqué et donc sur les performances.D'où une optimisation très importante de Qt et donc l'utilisation au maximum de l'accélération matérielle avec OpenGL quand c'est possible (en particulier, les devs ont développé un moteur de rendu OpenGL équivalent au moteur de rendu Raster)

Merci pour toute vos réponses. Je pense qu'on va utiliser Qt avec des biblio multiplateformes. On devrait s'en sortir. Merci de votre analyse.