Projet d'interface graphique avec OpenGL
Spootnik
Membre
[size=16pt]Interface graphique avec OpenGL[/size]
[size=12pt]Présentation[/size]
[size=9pt]J'ai l'habitude de prendre le pseudo de Spootnik (quand il est disponible...). J'ai 17 ans et j'apprends à programmer depuis déjà près de 5 ans. J'ai commencé quelques mois avec le Basic puis je me suis lancé dans l'objective-C et finallement ces 3 dernières années dans le C. À force de rester dans le C, j'ai commencé à bien maitriser le langage, en particulier les pointeurs, dont je connais nombre de secrets maintenant. J'ai eu envie il y a quelques mois de me lancer dans la création de jeu vidéos avec OpenGL. J'ai voulu lors de mes essais, créer une intreface utilisateur et je me suis rendu compte que ce n'était pas du tout chose facile, d'où ce projet : une interface graphique avec OpenGL.[/size]
[size=12pt]Le projet (bibliothèque)[/size]
[size=9pt]Il s'agit bien d'un GUI entier dont je parle. Je veux créer une interface graphique libre et portable qui utilisera OpenGL pour l'affichage. Le but premier est une intégration complète dans les jeux vidéos. En effet, le style de toute l'interface sera, à terme, personnalisable. Une particularité intéressante sera sa gestion de la réception de clics de souris en fonction de la transparence du pixel désigné. En conséquence, les fenêtres pourront prendre les formes diverses, et non pas seulement l'apparence classique carrée, afin de permettre une fondue dans le décor de n'importe quel jeu vidéo.[/size]
[size=9pt]Si le projet est concluant, plusieurs fonctionnalités sont prévues :[/size]
- [size=9pt]pouvoir charger l'interface à partir de fichiers (probablement sous forme d'arbre XML)[/size]
- [size=9pt]rendre l'interface entièrement personnalisable[/size]
[size=9pt]Pour ce projet, j'ai choisi l'objective-C. Tout d'abord parce que je conais assez bien ce langage, qu'il comporte une couche objet, et qu'il est selon moi beaucoup plus souple que le C++.[/size]
[size=9pt]Le projet en est à ses débuts et j'avance pour l'instant avec l'aide de PsychoH13. Les bases ont été codées (en dehors d'un dernier bug). Le système de gestion des évènement (clavier/souris) est en place, la gestion des fenêtres ainsi que la gestion des objets à l'intérieur des fenêtres est aussi en place.[/size]
[size=9pt]Voici comment est organisée (en gros) l'interface :[/size]
OApplication : gestion des évènements et fenêtres<br /> +<br /> +- OWindow +- OView +- sous-objets...<br /> + +- OView<br /> +<br /> +- OWindow +- ...<br />
[size=9pt]Note: j'utilise le prefix "O" afin d'éviter les conflits avec d'éventuelles autres bibliothèques (mais je n'aime pas trop ce prefix, j'essaie de trouver autre chose en ce moment ::)).[/size]
[size=9pt]Actuellement, le projet est hébergé chez BerliOS et dispose d'une page technique, d'un serveur CVS et d'un site web (par encore construit). Une discussion existe aussi sur le site Developpez afin d'informer de l'avancement.[/size]
[size=9pt]J'ajoute que si des personnes souhaitent voir ce qui a été fait pour l'instant, vous pouvez visualiser ou télécharger les sources (une par une) à partir de BerliOS par ce lien : http://cvs.berlios.de/cgi-bin/viewcvs.cgi/aigl/[/size]
[size=9pt]Enfin, après avoir légèrement trimé dans l'utilisation de autoconf et automake, j'ai réussi à créer un 1e paquet avec script 'configure' intégré afin de faciliter l'installation.[/size]
[size=9pt]Le code a pour l'instant été testé avec Mac OS X PPC 10.3.9 et je compte sur vous pour m'aider à trouver les bugs, d'une part dans l'installation mais aussi dans la bibliothèque elle-même. Le code n'est probablement pas encore entièrement portable pour Linux et Windows (principalement à cause des adresses pour les #include et #import à corriger).[/size]
[size=9pt]Les paquets sont disponibles ici : http://developer.berlios.de/project/showfiles.php?group_id=8755 .[/size]
[size=12pt]Ma demande[/size]
[size=10pt]2 codeurs objective-C maà®trisant OpenGL[/size]
[size=9pt]Ils devront, petit à petit, et dans la mesure du possible:[/size]
- [size=9pt]Coder les sous-classes d'objet pour les fenêtres (zone d'image, de texte, bouton...)[/size]
- [size=9pt]Implémenter la gestion des redimmensions des objets, en répercutant ces redimmensions aux sous-objets[/size]
- [size=9pt]Optimiser l'ensemble afin d'obtenir de bonnes performances[/size]
[size=9pt]Toutes les suggestions (constructives) sont évidemment les bienvenues.
Bon développement à tous,
Spootnik[/size]
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Edit: j'ai trouvé comment modifier 8--)[/size]
Oui mais. OK l'Objective-C est portable sous d'autres systèmes d'exploitation, seulement il n'y a que sous Mac OS X que tu trouveras des programmeurs le maitrisant. Ce que je veux dire c'est que si tu proposes ta bibliothèque à un programmeur Linux, il ne voudra pas l'utiliser (sachant que ça existe déjà ).
Considère l'utilisation d'un autre langage comme le C++ ou le C classique.
Quant au C++, pas suffisament souple pour nos besoins. Pour appeler une méthode sur un objet de type encore inconnu à la compilation l'objective-C est très pratique.
Mon but n'est pas non plus que tous les programmeurs utilisent ma bibliothèque, c'est un projet personnel, pas commercial ; donc je n'ai pas d'obligation de rendement ni de succès. En ce qui concerne les programmeurs le maitrisant, certes, pour l'instant il y en a peu. Mais étant donné que l'objective-C est très facile à apprendre une fois le C maitrisé, je m'attends tout de même à ce que certaines personnes aillent au moins jetter un oeil au langage et qu'ils décident ensuite s'ils veulent l'adopter ou non.
Par contre je ne vois pas ce que tu veux dire par "sachant que ça existe déjà ". Il existe des bibliothèques d'interface utilisateur qui utilisent OpenGL pour l'affichage, mais aucune adaptée aux jeux vidéos, or c'est le but principal de mon projet.[/size]
Donc si tu veux être portable, il te faut un runtime: et là c'est assez amusant. il y a celui de Mac OS X et celui de GNUStep qui sont assez différents. Celui de OS X ne tourne que sous OS X, donc tu devrais te baser sur celui de GNUStep. Mais seulement, lui n'est pas installable sous OS X (les dev GNUStep et qui ont des mac que je connais travaillent dans des machines virtuelles sous Linux plutôt que de tenter de faire marcher le tout nativement sous OS X) et sous Windows ça avance, mais plus lentement que le reste de GNUStep.
Donc niveau portabilité, tu auras à mon avis beaucoup plus de chances avec Ruby ou Python. Si tu veux de l'aide, ces langages disposent déjà de communautés très actives, et en plus il y a déjà des bindings OpenGL qui existent, ce qui peut faciliter les choses.
Un framework est juste un dossier organisé qui contient la bibliothèque... donc on peut très bien utiliser uniquement une bibliothèque. Quant au runtime, c'est GCC qui convertit les symboles, et la bibliothèque objc qui définit ces symboles, donc là aussi ça ne pose pas de problème.
Par contre entre runtime de GNUstep et celui de NextStep on a pas encore choisis. Pour l'instant on réfléchie à la solution pour éviter un crash lors d'un appel de méthode inxexistante (qui déclenche une exception avec Cocoa, mais pas avec GNUstep et NextStep).[/size]
J'essayais de soulever le paradoxe de ta demande: vouloir l'aide de tiers pour faire un projet perso.
Si en plus il est écrit dans la langage exotique pour la plupart des programmeurs, je ne lui promet pas un grand succès. Je comprends que ce succès ne t'intéresse pas, mais il est difficile de motiver des gens s'il n'y a pas la promesse de créer quelque chose d'utile à beaucoup de gens.
Et sinon, Ruby ou Python, c'est effectivement une bonne idée.
Non je ne compte pas utiliser Ruby ou Python pour le projet.[/size]
[size=9pt]J'ai aussi lancé ce projet dans le but d'apprendre ce que représente gérer ce type de projet, et afin d'approfondir mes connaissances sur l'objective-C et OpenGL.[/size]
D'un côté, tu espères convaincre avec la qualité du projet et de l'autre, tu dis le fais pour apprendre la gestion de projet ET l'intégration de 2 environnements dont un est super marginal?
Et quand je dis marginal, je suis gentil. Ce qui fait la popularité de l'objective-c, ce n'est pas la langage, mais les librairies Cocoa. Si tu veux faire quelque chose avec juste la "librairie objective-c" comme tu l'appelles, ça veut dire que tu vas devoir quasi tout refaire (des classes comme NSObject, ça fait partie des frameworks Foundation, pas de la "librairie objc"). C'est une montagne de boulot.
Pour ton info, si j'ai parlé de Python, ce n'était pas innocent: les interfaces de Civilisation IV sont décrites en Python.
En quoi le fait que ce soit un projet d'aprentissage l'empêche-t-il d'être de qualité ?
Quand tu dis 2 environnements tu parles de GNUstep et NextStep ?
Je suis bien conscient qu'il y a du boulot. Mais d'une part, je ne compte pas refaire toute la bibliothèque Cocoa et d'autre part, je trouve que beaucoup d'élements chez Cocoa sont inutiles (pas tout, mais une bonne partie). D'où l'intérêt de faire nos classes avec des besoins adaptés à notre projet.
Parce que la programmation est juste un grand compromis entre lisibilité du code, efficience, souplesse, mise en évidence des forces des frameworks et évitement des faiblesses.... J'ai du mal à imaginer comment il est possible de faire de bons compromis si on ne sais pas de quoi on parle.
Et OpenGL?
C'est un projet est qui déjà ambitieux si on utilise des trucs tout faits (que ce soit du "pur" Cocoa, du .net, du QT, du Ruby, du Python, ou n'importe quel autre langage qui puisse s'interfacer avec OpenGL). Ce n'est certainement pas moi qui vais critiquer quelqu'un parce qu'il veut réinventer la roue, mais le faire en voulant partir de si bas ça me parait démesuré.
Bonne chance en tout cas.
Pour ça que j'ai dit que j'ai aussi fait ce projet pour apprendre. Lorsque les problèmes surviendront ce sera le moment d'y réfléchir. Pour l'instant le code est très facilement modifiable et adaptable, donc je ne m'inquiète pas (tant que je ne vois pas où je me suis planté je ne risque pas d'apprendre, donc je préfère voir le problème le moment venu).
C'est presque la partie la plus simple du projet
J'ai du temps et de la patience
Hé bien moi, si. Croire qu'on peut la réinventer, en faisant mieux que les autres, c'est soit être balèze, soit être bien naà¯f.
Je n'ai pas dit que j'allai faire mieux
Alors là je t'arrête tout de suite... Si le C++ a un énorme défaut, c'est qu'il est justement bien trop souple !
On peut faire tout et n'importe quoi avec.
Ce dont tu parles, on peut le faire en castant à la barbare...
Pour l'interface OpenGL en Objective-C, je ne veux pas être pessimiste, mais je doute que ça soit viable.
Et il se passe quoi à ton avis si on appelle une méthode (en C++) sur un objet qui ne répond pas à cette méthode ? dis moi si je me trompe mais à mon avis c'est le crash assuré.
En plus, tu viendrais implémenter ta propre idée de l'interface avec les objets dont le développeur a besoin et rien de plus, alors que par défaut, la librairie Cocoa, Foundation et tout ça sont inclues dans OS X pour tous les utilisateurs
Tu semblerais oublier que le but de mon projet n'est pas une interface dans l'environnement de Mac OS X mais dans OpenGL. Cela fait une grande différence, d'abord parce qu'il n'existe pas trois tonnes de bibliothèques d'interfaces utilisateurs (je ne connais que GLUI dans ce cas là ), et ensuite parce qu'aucune des interfaces que je connais n'est faite (je veux dire adaptée) pour les jeux vidéos.
Donc si le programmeur a besoin de classes supplémentaires, il va les chercher ailleurs, moi je ne compte fournir que ce qu'il faut pour faire tourner l'interface.
Cocoa a choisi de s'étendre afin de combler des besoins très divers, ce n'est pas le cas de ma bibliothèque.
1) Tu peux tout à faire faire ce que tu décrit en C++. Il suffit de faire une conception OO bien pensée.
On peut utiliser les interfaces de classe par exemple, c'est tout indiqué, même. Ou alors baser toutes tes classes sur une classe mère un peu comme NSObject en Cocoa, ce qui peut amener quelques avantages aussi.
Avec un bon diagramme de classes, et entre autres des classes mères (abstraites ou non) bien organisées, non seulement tu peux savoir si un objet donné est de tel ou tel type, répond à telle ou telle interface, mais tu peux prévoir des comportements par défaut (pouvant être vides d'ailleurs) ce qui te permet de pouvoir répondre à une fonction sans obliger le programmeur à ce que ça fasse qqch. Exactement comme fonctionnent les delegate en ObjC (c'est d'ailleurs comme ça que c'est fait)... bref, y'a bcp de choses qui se retrouvent là dedans.
Après, pour vérifier qu'un objet répond à telle et telle méthode, il suffit de vérifier qu'il implémente l'interface. C'est comme ça que font tous les gros projets en C++. Les dynamic_cast<> peuvent aussi être utile dans ce cas, si besoin, etc.
2) Si "le programmeur fait une bétise" comme tu dis (j'imagine que tu penses aux bétises genre appeler une méthode sur un objet qui ne répond pas à cette méthode), dans ce cas, au moment de la compilation, il y aura une erreur (de compilation, donc) signalant au programmeur qu'il s'est gourré. Comme tu as un warning en ObjC. En aucun cas il y aura crash.
Le seul crash possible en C++ dans le domaine que tu abordes dans ton post, c'est d'appeler une méthode sur un pointeur nul, genre [tt]MonObj * ob = NULL; ob->maFonction[/tt] en C++ là où [tt]MonObj * ob = nil; [ob monSelecteur][/tt] en Obj-C ne plante pas... mais ne fait rien (et tu n'as même pas un warning à la compilation), alors que le programmeur pourrait attendre que qqch se passe.
Mais ça n'a rien à voir avec le fait de pouvoir appeler une méthode (envoyer un message) sur un objet qui ne sait pas y répondre ni avec ce que tu évoques dans ton post
Dernier point, en Objective-C, même si c'est autorisé d'envoyer un message à un objet qui ne sait pas y répondre, normalement faut blinder ce genre d'appel avec un test via "respondToSelector" (et à part pour des cas de compatibilité de version avec le framework Cocoa qui évolue à chaque version d'OSX... et que tu n'utiliseras pas, j'ai rarement d'autre cas d'utilisation)
Après, si tu tiens tant à continuer dans cette voie, c'est comme tu veux, c'est toi qui choisit et c'est ton projet
En fait, ce que Ali essaye de te dire c'est qu'avec le C++ on peut tout faire mais qu'il faut tout se farcir... ;D
J'aurais tendance à considérer qu'il ne faut pas confondre la souplesse d'Obj-C et la permissivité du C/C++ (qui a parlé de casts sauvages?
Trêve de plaisanterie, je vous trouve bien sévère avec notre ami. Ma seule réserve est qu'effectivement Objective-C est un langage très lié au monde Mac et que j'ai peur que l'arrivée de Core Animation rallie massivement la communauté à sa cause au détriment de ton projet. C'est dommage que tout ce qui touche à la Beta de Léopard soit sous NDA car je vous aurais bien montré ce sur quoi je travaille en ce moment pour un client. Pour reprendre l'expression d'un ami PCiste: on est loin des trois pauvres fenêtres 3D de Vista!
Les premiers tests sur ce point sont positifs.
Ah... Je n'ai peut-être pas choisi l'objective-C pour les bonnes raisons alors :-\\.
Oui je sais qu'il y a moyen de vérifier, mais devoir appeler en permanence une méthode de plus pour vérifier la validité ça m'a l'air assez lourd...
Enfin c'est vrai que je n'utilise pas les objets de type inconnus à tout bout de champ... faut que j'y réfléchisse.
Non il n'y a pas eu d'avertissement. Je vais essayer d'expliquer le cas.
Dans l'interface, chaque fenêtre a un objet de type View. Cette vue garde dans un champ (une classe liste) toutes les sous-vues. Ma classe liste, lorsque je demande un objet, renvoie id (d'après le prototype et l'implémentation), donc je peux appeler n'importe quoi sur cet objet sans pour autant avoir d'avertissement.
C'est dans ce cas qu'il serait préférable d'avoir un avertissement plutôt qu'un crash. Et à la limite j'avoue qu'il est envisageable de faire le test du type de l'objet renvoyé ainsi que de l'existence de la méthode voulue.
Tu peux développer ?
Sinon pour en revenir à la question C++ ou objective-C, je pense que ça mérite un débat, afin de voir les avantages et inconvénients de chacun (puisque je me suis planté sur l'objective-C semblerait-il).
Je vais vous dire ce que je sais (et qui est peut-être faux) sur ces deux langages.
Objective-C :
Avantages:
- couche OO
- organisé clairement (subjectif)
- surensemble du C (aucune modification nécessaire du code)
- possibilité d'éviter le crash lors d'un appel de méthode inconnue sans devoir tester l'objet
Inconvénients:
- beaucoup plus lent que le C et le C++ (par les messages)
- géré par aucun EDI sous Windows
- bibliothèque "standard" très limitée
- communauté ayant des connaissances sur l'objective-C "standard" (donc hors Cocoa) assez limitée (je me trompe ?)
C++ :
Avantages:
- couche OO
- beaucoup plus rapide que l'objective-C
- géré par les EDI de tous les OS
- bibliothèque standard riche (à confirmer)
- communauté importante est répartie sur tous les différents OS (principaux)
Inconvénients:
- plus gourmand en mémoire que le C (qu'en est-il de l'objective-C sur ce point ?)
- assez brouillon (subjectif)
- langage ressemblant au C mais différent (modification nécessaire dans le code)
- possibilité d'éviter le crash lors d'un appel de méthode inconnue mais en testant l'objet
Si je me pose ces questions cela veut dire évidemment qu'il est envisageable de changer le principal langage du projet. Que pouvez-vous me dire sur les avantages et inconvénients que j'ai cité, et avez-vous quelque chose à ajouter ? À partir de là je pourrai décider du langage le plus approprié au projet.
C'est là que j'ai bien l'impression que tu n'as pas dû avoir beaucoup d'occasion de pratiquer le C++, me trompe-je ?
En effet, le "assez brouillon" est subjectif : à mon avis si l'Objective-C te semble "moins brouillon" c'est uniquement parce que tu es habitué comme nous tous à l'utiliser dans le cadre de son utilisation conjointe avec Cocoa. C'est le framework Cocoa qui fait l'essentiel de la puissance du couple ObjC/Cocoa, et qui fait surtout que les objets disponibles sont bien organisés : objets, classes disponibles, système de gestion de mémoire... tout ça c'est grace à NSObject et aux autres objets que prodigue Cocoa, pas à l'ObjC en lui-même.
Bon je te consent que le distingo n'est pas simple à faire entre les 2. Mais justement à mon avis c'est une raison de plus pour laquelle le choix d'ObjC n'est pas le plus judicieux : en plus du fait que, comme tu le dis, il y a très peu de personnes maà®trisant l'Objective-C à part ceux du monde mac l'associant ainsi à Cocoa, il est difficile d'identifier les avantages de l'ObjC sans Cocoa, puisqu'on l'associe souvent naturellement à ce framework et il y a certaines fonctionnalités pour lesquelles on a parfois du mal à savoir si c'est ObjC ou Cocoa, donc...
Quand tu dis "langage ressemblant au C mais différent (modification nécessaire dans le code)", je ne comprend pas trop ce que tu entends par "modification nécessaire dans le code" ? On programme son code ou ses portions de code en C, ou en Objective-C, ou en C++, mais on va rarement "convertir" un bout de code d'un langage à un autre et donc devoir modifier du code. Sache qu'on peut tout à fait appeler des librairies C avec du code C++ par exemple. Et que (à de très subtiles exceptions près) un code en pur C pourra tout à fait être utilisé comme si c'était du C++ (et compilé via un compilateur C++) au même titre que du code C peut être compilé avec un compilateur gérant l'ObjC.
Le mariage des 2 langages (C et C++) est donc tout à fait réalisable, comme le mariage du C et de l'ObjC. ou du C++ et de l'Objective-C++.
Enfin, quand on reprend ton exemple de la méthode qui renvoie un objet de type "id", il faut simplement se dire que c'est à voir comme le type aggrégeant tous les autres objets (comme un NSObject, d'ailleurs je crois que la différence entre "id" et "NSObject" est subtile et pas si grande). Un peu comme un "void*".
Mais dans ce cas rien ne t'empêche de prévoir dans les classes de ton framework que tu comptes développer, une classe mère racine, donc qui serait le parent de toutes tes autres classes, à la manière de NSObject.
1) Premier cas : tes méthodes pourraient si c'est nécessaire renvoyer ce type d'objet racine.
Dans ce cas alors, on est tout à fait d'accord qu'il est nécessaire de faire un test sur le type d'objet (soit par un dynamic_cast<>, soit par une variable de classe de ta classe racine indiquant le type terminal de l'objet (c'est ce qui est fait dans la plupart des moteurs graphiques, j'ai déjà vu ça entre autres qd j'ai bossé sur le moteur Torque)
2) Deuxième cas, plus propre au niveau logique objet je trouve, c'est que tes méthodes retourne une interface. L'interface de classe indique la liste des méthodes auxquelles l'objet sait répondre, et ce indépendamment de la classe de l'objet (du moment qu'il implémente l'interface).
Perso j'utilise toujours cette méthode et l'ai vu utilisée maintes fois, pour la bonne raison qu'en pratique tes méthodes retournent un certain type d'objet qui ensuite est utilisé pour un ensemble d'utilisations possibles figé.
Donc, pour reprendre ton exemple avec une classe "Liste" qui pourrait contenir une liste d'objets de type différents, les templates sont faits pour ça (il y a d'ailleurs tout ce qu'il faut côté modèle pour gérer les listes avec les très populaires STL).
Tu peux par exemple te faire une list<Personnes>, une list<Voitures>, une list<RootObj> pour avoir une liste d'objets quelconques basés sur ta classe racine RootObj, ou une list<IRankableObj> où IRankableObj est une interface de classe indiquant que la classe répond par exemple aux méthodes setRank(...) et getRank(), etc, etc.
Et dans tous ces cas de figure, aucun besoin de faire un test sur le type d'objet, puisque soit tu connais sa classe, qu'elle soit terminale (feuille de ton diagramme de classes) ou pas (et donc que ce soit une classe mère aggrégeant plusieurs sous-classes), ou au moins tu connais la ou les interface(s) qu'elle implémente (et donc les méthodes que tu peux appeler sur l'objet récupéré).
Tu peux peut-être t'inspirer de frameworks déjà existants ayant pour vocation d'être crossplatform (je pense à QT et sa hiérarchie de classes et d'objets disponibles, graphiques ou non, je pense à la STL et ses objets pour la partie "modèle" du MVC, à Java, et surtout à des moteurs graphiques comme Ogre ou Torque qui sont plutôt coriaces comme projets et en général bien organisés pour ce genre de choses)
Voilà pour les éléments de réflexion
Après je dis pas que l'Objective-C n'a pas ses avantages, mais personnellement je trouve que ce n'est pas le meilleur choix pour une bibliothèque crossplateforme essentiellement parce que le langage est très loin d'être le plus répandu (à part dans le monde mac mais dans ce cas uniquement couplé à Cocoa) contrairement au C ou C++ que tout ceux qui font du crossplateform maitrisent et utilisent.
C'est pas compliqué, à mon avis pour ceux qui n'ont jamais fait d'Objective-C, s'ils cherchent une lib qui fait ce que fera ta lib, dès qu'ils verront que le langage n'est pas un langage connu (C, C++, Java), je doute fort qu'ils fassent l'effort d'apprendre l'Obj-C juste pour ça, ils vont plutôt passer leur chemin et chercher une autre lib. Même si ta lib est mieux foutue. Car apprendre un langage nouveau ça prend du temps, et autant le C et C++ sont très répandus et donc soit on les maitrisent déjà , soit si on les connait pas ça pourra toujours servir pour d'autres projets car ils sont un peu partout, autant pour l'ObjC et son utilisation pas du tout répandue dans les projets crossplateform, peu de gens franchiront le pas.
That was my two cents
Non tu ne te trompes pas. J'ai fait peu de C++, principalement parce que j'ai préféré garder les "bonnes" habitudes du C.
Je n'utilise pratiquement plus Cocoa. Quant au côté brouillon, tu as peut-être raison, mais pour l'instant je ne suis pas convaincu.
Soit on adapte le code au langage, soit on utilise un bloc "extern C", mais en aucun cas (sauf cas très rare) on utilise le code tel quel.
Je ne suis pas d'accord, on ne mélange pas deux langages comme ça à la légère (on voit que tu n'a pas l'habitude d'entendre Emmanuel Delahaye qui se tue à répéter que le C et le C++ sont deux langages différents). Il est possible de compiler du C avec le compilateur objC car l'objC est un surensemble STRICTE du C ! Ce n'est pas le cas du C++.
Non non non ! Si j'utilise un type générique, que je créé une sous-classe avec de nouvelles méthodes, puis que j'ajoute des méthodes à cette nouvelle classe, lorsque je fais un appel sur un objet renvoyé en tant que NSObject, j'ai un avertissement (qui à priori n'est pas là pour rien...). C'est là que le type "id" est intéressant.
Cela implique le test que je n'ai pas trop envie de faire... mais c'est peut-être la seule solution.
mm... intéressant. ça fait partie des choses que j'ignorais sur le C++ ::)
C'est assez discutable.
Tu oublies que je n'ai trouvé aucun bibliothèque produisant une interface graphique avec OpenGL et adaptée aux jeux. Je pense qu'on peut donc considérer (sans trop prendre de risque), qu'il n'existe pas de bibliothèque concurrente. Dans ce cas, c'est au programmeur de voir s'il préfère créer sa propre bibliothèque ou apprendre un langage très rapide à apprendre (d'après moi) une fois le C maitrisé. Entre les deux, je sais ce que je choisirais sans hésitation...
http://guichan.sourceforge.net/wiki/index.php/About
Trouvé sur la page traitant de SDL sur Wikipedia, donc on ne peut même pas dire que ce soit vraiment caché.
[size=10pt]O_O[/size]
Edit: ça remet en cause l'existence même du projet...
En plus de Guichan en C++/OpenGL, il y a aussi Fenggui avec le couple Java/OpenGL :
http://www.fenggui.org/doku.php?id=doc:examples:examples
mais effectivement je n'en connais pas non plus en ObjC/OpenGL, mais comme te le suggérais Aligator ce n'est pas forcement le langage le plus adéquate pour une solution multi-plateforme. (et sur Mac avec le Core Animation de leopard c'est le bonheur
Mais ce que je voulais dire c'est que faire du C++ (pour les possibilités objet) et y rajouter du code C (pour l'algorithmie en général) est assez courant et tout à fait possible.
En ObjC, c'est certes qu'une "pré-traduction" du code ObjC en C (avec les appels à la fonction C objc_send(...) à chaque fois que le compilo voit un [obj selector], et tout), donc au final ça reste une vraie surcouche du C. Mais c'est trop peu répandu par rapport au C++ que pour être utilisé pour un toolkit crossplateform à mon sens par rapport à ce que l'ObjC peut apporter de plus que le C ou le C++. Certes l'ObjC a des avantages non négligeables, mais est trop méconnu en dehors de la sphère mac et Cocoa pour être utilisé pour un projet à vocation crossplateforme et réutilisable.
Et la plupart des avantages que prodigue l'ObjC sont balancés aussi par les avantages du C++. Par exemple, la notion de templates (cf typiquement la STL) me manque parfois cruellement en ObjC, du genre, on peut faire des NSArray d'objets de types différents, et il n'y a aucune indication dans le type de l'objet (NSArray) pour savoir le contenu du tableau (c'est un tableau de quoi ??). Donc c'est du coup un peu trop permissif, et dans l'absolu si on veut être rigoureux il faudrait ensuite vérifier le type de l'objet (ou tester avec respondsToSelector: ) extrait du tableau avant de l'utiliser... alors qu'en C++ cette vérification n'est pas nécessaire, étant inhérente par le type de l'objet.
Pour résumer, en C++ on peut déclarer une variable de type "tableau d'objets A" genre un tableau de personnes, alors qu'en Cocoa on peut faire des NSArray mais ces derniers pourront contenir tout et n'importe quoi et on n'a aucune garantie de leur contenu. Donc pour bien faire on devrait tester le type. Et ObjC sans Cocoa n'en parlons pas, il n'y a rien de spécial pour gérer les tableaux à part les malloc (nécessitant l'évaluation de la taille d'un objet en mémoire pour créer un tableau desdits objets) bien moins intuitifs que les "new" (genre [tt]Voiture* tabVoitures = new Voiture[nbVoit];[/tt] pour créer un tableau de 1à voitures au lieu de [tt]Voiture* tabVoitures = (Voiture*)malloc( nbVoit * sizeof(Voiture) );[/tt])
Mais bon ce n'est qu'une question de point de vue, encore une fois.
Heu non non non justement, au contraire, là il n'y a pas besoin de test en C++ (alors qu'en ObjC si on veux bien faire il faut faire un test sur respondToSelector avant d'appeller un selecteur sur un objet dont on n'est pas sûr du type). Par exemple tu peux avoir une interface "IEnumerable" qui implémente les fonction "getFirst", "getNext", "getPrevious", "getLast", et ce genre de méthodes. Et ensuite plein de classes, qui n'ont pas forcément un rapport entre elles, peuvent implémenter cette interface : une liste, un tableau, un résultat de requête sur une base de données, etc. Tu peux alors avoir des méthodes retournant des "IEnumerable" : tu t'en fiches alors de savoir quel type d'objet c'est, tu n'as même pas besoin de faire un quelconque test, tu peux alors appeler la fonction "getFirst" sur ces objets sans te poser de question.
C'est un concept un peu similaire aux protocoles que l'on voit dans Cocoa, même s'il y a des petites distinctions, je te laisse lire les multiples tutos sur le net à cet effet.
C'est bien ce qu'il me semblait, je veux dire les gens qui n'ont fait que peu de C++ ne connaissent pas forcément les trucs et astuces parfois utiles et concepts avancés du C++ (tous les concepts de POO qui ne sont pas tous présents en ObjC, l'aspect pointeurs de fonctions pouvant remplacer le type (SEL) de Cocoa, l'aspect templates, la possibilité pour une classe de dériver de plusieurs classes mères, y compris des classes abstraites ou des interfaces, etc)
Ah ben c'est là qu'il y a souci car pour moi cela existe déjà . Je t'en ai cité quelques exemples, au détour des moteurs graphiques de jeux bien connus comme Ogre ou Torque (que j'ai pratiqué) qui ont dans leur toolkit de quoi créer des interfaces en OpenGL, mais aussi ceux qu'ont cité les autres membres, ou GLOW que je ne connaissais pas avant de faire à l'instant une recherche Google (sur les mots clés "OpenGL widgets toolkit")...
Et je ne pensais même plus aux libs se basant sur la SDL et permettant d'y rajouter des widgets pour une GUI, en effet
Bref, il y a le choix... Et du coup entre ces possiblités et un truc fait en ObjC, pour un gars qui n'a jamais fait d'ObjC, le choix est vite fait
Malheureusement non. L'utilisation de la Beta de Leopard est soumise à accord de non divulgation (
On a donc pas le droit d'en dire plus que ce que Apple en dit ici...
http://www.apple.com/macosx/leopard/technology/coreanimation.html
Effectivement, on y prend vite goût. :P
Tu sais que le runtime de l'Objective-C qui autorise ça (car il gère les méthodes par "sélécteurs" ; c'est de l'indirection) le rend particulièrement lent par rapport aux appels C / C++ ? Et que pour faire un Wrapper sur un truc graphique qui demande pas mal de puissance, ça va être un peu la loose.
[Edit] Oui, apparemment tu le sais, puisque tu le spécifies clairement sur un de tes messages par la suite...
Autant j'adore l'Objective-C, je trouve qu'il est pas mal pour gérer une interface... Autant pour de l'algorithmique, bof.