Programmation OpenGL multi-Os : quoi à part le C/C++ ?

Bonjour à tous :),

Je dispose déjà d'une certaine pratique personnelle d'OpenGL, que j'ai utilisé en Java grâce à la bibliothèque JOGL. Evidemment, en Java, c'est du moitié compilé, avec le système de byte code. Donc, je pense que niveau performances, quand bien même JOGL est une librairie native, je suis perdant.

C'est pourquoi je voudrais me tourner vers un langage compilé pour réaliser les programmes OpenGL. Malheureusement, en C/C++ : je produis trop souvent de "segmentation fault", et le prometteur langage Go de Google ne semble pas avoir de librairie multi-os (Windows/linux/Mac) mature.

J'ai vu qu'il y a lazarus pour programmer en Pascal, mais l'ide est encore buggé (testé sous Ubuntu 12.10 64 bits) : notamment quand je tente d'accéder à l'explorateur d'évènements d'un composant.

Ma question est donc la suivante : connaissez-vous d'autre langage Orientés Objet, multi-OS, et qui auraient une version satisfaisante d'OpenGL (mature/multiOs et au moins OpenGL >= 2) dans ses librairies (bien sûr, que ce soit une librairie interne au langage, ou tierce partie) ?

Edit : que pensez-vous de SmallTalk ? Puis-je y gagner en performances par rapport à ce que produit le langage Java ?

Je vous remercie d'avance.

Python correspond parfaitement à ce que tu cherches. Cela dit, je te conseille de rester dans le C/C++. Un segfault c'est ce qu'il y a de plus facile à debugger car le débogeur te dira où exactement le programme a planté. Et ça t'apprend des trucs.

Citation:

---

Envoyé par Melem

Python correspond parfaitement à ce que tu cherches. Cela dit, je te conseille de rester dans le C/C++. Un segfault c'est ce qu'il y a de plus facile à debugger car le débogeur te dira où exactement le programme a planté. Et ça t'apprend des trucs.

---

Bonjour, merci pour ta réponse :)

Mais Python, en faisant du bytecode (en fait il me semble juste), n'est-il pas aussi performant que Java ?

En fait, le C/C++ me font toujours aussi peur (j'ai plus d'expérience en Java : sauf en ce qui concerne le JNI, où je n'y connais vraiment rien) : surtout la POO et la gestion des exceptions en ce qui concerne C++. Par contre je concède à ces langages une efficacité maximale. J'ai donc pensé au GO : mais ses spécifications (notamment pour les librairies statiques, j'ai cru comprendre) ont rendu difficiles l'adaptation d'un framework OpenGL pour tous les OS. Peut être devrais-je encore attendre un peu et continuer en attendant de le faire en Java / Python.

Mais je ne ferme pas la porte à une version "épurée" du C++ que représente le GO.

Ben python et Java c'est en effet un peu pareil. Sauf que python peut être directement interprété aussi, sans passer par du bytecode. Il faut aussi savoir que les deux langages permettent la compilation en code natif des programmes. C'est-à-dire que tu peux créer de véritables exe avec du code Python ou Java. Tu auras alors des perfs qui se rapprocheront de celles d'un équivalent C bien écrit. Mais entre Java et Python, je choisirais Python.

Citation:

---

Envoyé par Melem

Ben python et Java c'est en effet un peu pareil. Sauf que python peut être directement interprété aussi, sans passer par du bytecode. Il faut aussi savoir que les deux langages permettent la compilation en code natif des programmes. C'est-à-dire que tu peux créer de véritables exe avec du code Python ou Java. Tu auras alors des perfs qui se rapprocheront de celles d'un équivalent C bien écrit. Mais entre Java et Python, je choisirais Python.

---

Evidemment, je suis plus adepte du bytecode que du tout interprété.

Après pour la compilation en code natif, j'avais entendu parler de programmes pour faire des *.exe à partir de fichiers semi-compilés java (*.class), mais j'ignorais que c'était du vrai code natif, et pas seulement une manière astucieuse de simplifier la tâche à l'utilisateur lors du lancement du programme. Ce que je peux regretter par contre, c'est que cela ne me semble disponible que sur Windows (je suis un vrai fan de linux, au point d'en faire le système sur lequel je passe le plus grand de mon temps).

Enfin, même si la syntaxe de Java est plus permissive et plus complexe, c'est le langage de bytecode que je préfère, notamment parce que j'y ai une plus grande expérience, et que le déploiement d'applications me semble plus simple (notamment avec les archives jars auto-éxécutables).

Mais je me plains des performances Java : alors que la différence à l'heure actuelle n'est peut être pas si grande que cela. L'impression que j'avais venait peut être, et je viens de me rendre compte aujourd'hui, du fait que j'utilisais une classe de JOGL limitant volontairement le nombre de FPS. Pourquoi ? Tout simplement pour obtenir le même résultat (la même vitesse) sur un maximum de cartes graphiques / d'OS / de processeurs. C'est sûr qu'en choississant 60 FPS en Java, et en le laissant par défaut sur un IDE comme Gambas3 ... la différence ne pouvait qu'être notable (j'ai une ATI Radeon HD4330 et un processeur 3Ghz Double coeur => je peux obtenir bien plus que du 60 FPS en temps normal !)

Donc je pense que ma question n'est finalement pas aussi pertinente que cela, et que développer un jeu 3D sur un langage basé sur le bytecode (Java et ses nombreux dérivés : Ruby, Scala ..., notamment) n'est pas forcément pénalisant. Je mets donc en résolu. ( :mrgreen: )

Bon j'ai été sur la page de GCJ, le compilateur gratuit adaptant GCC mais pour les programmes Java, et cela m'a l'air tout à fait prometteur. Je vais sûrement m'y mettre au cours des prochains jours.