Discussion :

[iarwain]

Bonjour,

Tout d'abord je tiens à m'excuser car je ne vais pas respecter les règles de présentation de ce forum car il ne s'agit pas d'un recrutement au sens traditionnel du terme!

En effet, je viens chercher ici des personnes qui seraient potentiellement intriguées et/ou interessées par essayer un moteur qui se veut un peu "différent" des autres.

A vrai dire, ce dernier ne prétend pas devenir (et ne le prétendra jamais) le prochain concurrent d'un Irrlicht, d'un Ogre3D ou d'un quelconque moteur graphique ou complet. Le but d'orx (c'est son p'tit nom =) ) étant de réutiliser le maximum ce qui existe déjà et de proposer de nouveaux mécanismes, quand cela est possible, autour d'un noyau rapide et portable.

Il a donc été conçu avec un permanent soucis de modularité et de portabilité. Son noyau est ainsi, le plus possible, indépendant de toute plateforme / bibliothèque externe et fait appel à des plugins pour l'exécution de tâches dépendantes du matériel ou de l'OS (ce n'est pas encore tout à fait vrai, car par manque de temps, il dépend encore pour quelques temps de bibliothèques externes pour certaines fonctions de maths et de gestion de chaînes de caractères). Ces plugins sont actuellement chargés dynamiquement, mais la possibilité de "correspondance statique" sera mise à l'oeuvre pour des plateformes minimalistes comme la GBA, par exemple.

Orx est en cours de développement, et même s'il lui manque encore pas mal de fonctionnalités, il est actuellement fonctionnel pour les curieux et bidouilleurs en tout genre. J'ai réalisé rapidement un test de scrolling différentiel (bien qu'orx soit censé gérer aussi bien 2D que 3D, actuellement mes besoins font que j'ai plus accentué le développement 2D, sachant qu'il suffit grosso modo de rajouter le support des matrices pour avoir la gestion de la 3D) pour montrer sas capacités ainsi que sa souplesse d'utilisation. Son source, ainsi que celui des plugins et diverses démos sont disponibles ici.

Comme je parlais de réutiliser ce qui existe déjà via les plugins permettant au noyau de gérer l'affichage, le son, le temps, les périphériques, etc... pour permettre de rajouter des fonctionnalités plus "originales", en voici quelques exemples :
- la gestion d'horloges indépendantes, cadencées à la demande, permettant une cohésion temporelle et du time-stretching indépendant (ralentir un groupe de NPCs, la musique ou autre de façon transparente);
- la gestion d'un graphe d'animation permettant d'enchaîner automatiquement les animations selon critères, le graphe pouvant s'adapter en temps réel;
- la référenciation automatisée et hiérarchisée des ressources
- l'initialisation/désinitialisation des modules par dépendances : les modules chargent leur prérequis et se mettent en pause si on débranche une brique qui leur est nécessaire jusqu'à son remplacement par une brique équivalent;
- la gestion hotplug des plugins 'core' (ceux qui s'interfacent avec les fonctionnalités prévues dans le noyau mais non implémentées car platform-dependent);
- l'allocation contiguë de mémoire par types de données;
- les noeuds hiérarchiques de positionnement (cf. open scene graph / renderware frames);

Orx est sous licence LGPL et codé essentiellement en C (on peut discuter plus tard du choix du langage, si certains le souhaitent, mais ce n'est pas le but de ce poste ^^) mais est fortement orienté objet.

Voilà pour la présentation technique et en ce qui concerne son principal auteur, rapidement, j'ai commencé en temps que programmeur dans le secteur des jeux video il y a plus de 6 ans, aussi bien en R&D que ce qui est actuellement ma spécialité, programmeur I.A.

Maintenant, concernant ma recherche, j'aimerais trouver des personnes qui voudraient tester tout ça, malgré le fait qu'il soit encore jeune, et qu'il manque des fonctionnalités très importantes comme la possibilité d'utiliser un langage de script pour le piloter et accéder aux plugins utilisateurs (qui rajoutent des fonctionnalités non prévues à la base, comme envoyer un mail, par exemple (pourquoi pas? ^^ ) ) ou le chargement de package : orx est désigné pour être data driven, mais actuellement il faut coder explicitement les inits.
A ce propos, si vous jetez un oeil au source de la demo du scrolling différentiel, la partie 'update' ne prend que qques lignes (le mouvement des vagues, celui de la caméra qui engendre le scrolling différentiel, et celui de l'agrandisement du viewport au lancement) alors que la partie 'init' est plus longues, c'est celle-ci qui disparaîtra lorsqu'orx pourra charger/sauver les packages correctement.

Donc, pour retourner à mes moutons (désolé pour ce post long et brouillon), je cherche des codeurs qui sont à la fois curieux et désireux d'explorer ses possibilités. J'aimerais avoir leur retour afin d'arranger ce qui doit l'être et de le rendre le plus agréable possible à l'usage. J'insiste sur le fait qu'orx n'est pas près pour une réelle 'production' de jeu, ceci dit, les curieux et bidouilleurs de tout poil devraient trouver matière à expérimentation.

Si certains d'entre vous souhaitent développer des plugins pour une architecture particulière (GP32/GP2X, DS, PS2, etc...), vous êtes aussi les bienvenus. Je compte d'ailleurs, pour mes propres besoins, en développer pour la DS, à moyen terme. Les plug-ins qui ont été actuellement développés sont seulement pour PC (win / linux).

Le noyau d'orx, quant à lui, s'il a connu plusieurs contributeurs, n'est actuellement maintenu et développé que par mes soins, donc si vous vous sentez motivés pour y contribuer, il y a de quoi faire, mais autant vous avertir de suite, pour ce poste là je suis assez exigeant, notamment sur le 'coding style' (d'aucun diront casse-c... ^^).

Et pour finir, il y a un projet de plateforme de développement associée à orx (EditOrx), mais celle-ci, par abandon de ses contributeurs, est restée à l'état de conception. Je ne compte pas m'en occuper (j'ai *horreur* de coder qqc qui se rapproche de trop près aux UIs), donc si quelqu'un veut reprendre cette partie du projet (qui est quasi-indépendant, et dont je ne m'occuperai en rien de la gestion), contactez-moi!

Quelques liens : il y a aussi une doc doxygen qui n'a pas été mise à jour depuis des éons (et c'est pas peu de le dire!) ici, ainsi qu'un wiki qui date tout autant là.

Si vous avez des questions/commentaires/retours de quelque sorte que ce soit, concernant orx ou moi-même, je serai très heureux de pouvoir y répondre! =)

En vous remerciant déjà pour cette lecture qui a dû être fastidieuse!

PS : Les derniers plugins d'affichage et de temps implémentés sont basés sur SFML (merci M. Gomila =) ), et probablement assez buggués (mea culpa), car j'ai fait ça vite, sans grande connaissance de cette bibliothèque, excellente au demeurant.

[granquet]

joli projet
j'ai un projet de moteur 3D dans les cartons (à but seulement pédagogique, histoire d'apprendre un peu ) et le tiens se rapproche assez de ce que je souhaite faire (langage, modularité, "philosophie"...).
je vais suivre ton projet de pres, il m'interresse

[iarwain]

Merci pour ton post, ça fait plaisir d'avoir une réponse! =)
Si jamais, dans le futur, tu as envie de participer à l'avancement d'orx, ou que tu désirerais t'en servir pour tes propres besoins et qu'il te manquent pas mal d'info/doc, n'hésite pas à me contacter! Dans les deux cas, je me ferai un plaisir de te répondre!
Pour le moment, je te souhaite bonne continuation avec ton projet! =)

[the-gtm]

Un conseil si tu veux te lancer dans la réalisation d'un moteur de jeu : il faut rapidement qu'en parrallèle il y ait un jeu qui soit construit dessus. Ca te permettra d'avoir un retour au fur et à mesure, par exemple sur des bugs ou des difficultés d'utilisation.

Si tu attends d'avoir une version 'stable' pour trouver un 'client', celui ci va repérer tous les problèmes d'un coup et sera surement tenté de prendre un autre moteur. En plus si tu as un projet pilote à montrer, ça te fait une démo, ça montre que ton moteur est utilisable

[iarwain]

Tout à fait! C'est justement la raison principale de la présence de mon post sur ce forum! =)

Pour la petite histoire, orx est né pour les besoins de la création d'un jeu d'aventure amateur appelé la guerre des pâquerettes, en 2001/2002, mais celui-ci n'aura jamais abouti. Il reste cependant le site en ligne (Arcallians) malgré que ce dernier est abandonné depuis des lustres.
Sinon, en parallèle à ma recherche de "cobayes", je vais moi aussi développer un ou deux petits jeux avec d'autres personnes, notamment sur DS, mais ça prendra pas mal de temps, car mener de front le développement d'orx et de ces jeux demande beaucoup de temps.

Donc avis aux amateurs, j'espère trouver des "aventuriers" parmi vous, qui aimeraient tenter l'expérience! =)

[iarwain]

Mise à jour d'orx, avec les packages disponible ici.

Le package des démos contient maintenant :

- Une version mise à jour de la démo de scrolling différentiel;
- Une démo très simple d'une balle qui rebondit;
- Un début de démo "scénarisée", portant sur l'affichage de plusieurs viewports/cameras à l'écran.

Pour cette dernière démo, le code du deuxième viewport est normalement beaucoup plus simple (au lieu de lier les deux viewports à l'écran, on lie le second à un objet tiers qui lui sera affiché dans la scène globale, ce qui fait qu'on n'a pas à se soucier de la position de ce viewport, ni de rien en ce qui le concerne) sauf que... ça marche très bien avec n'importe quel plugin d'affichage à l'exception de celui basé sur SFML. En effet, ce dernier ne permet pas d'exécuter un rendu sur une texture externe (ie. pas sur l'écran). C'est une limitation volontaire de SFML par son auteur, d'après ce que j'ai pu en lire sur son forum. Ca m'ennuie un peu, car le seul workaround que je puisse faire actuellement nécessiterait une modification de SFML. Cette modif étant légère mais ne servant probablement que moi (ou d'autres rares cas isolés), je doute que son auteur veuille l'intégrer dans ses sources. Je verrai donc en temps voulu.

Sinon, comme lors de mon dernier post, comme orx n'est pas encore data driven, les fonctions d'initialisation de ces démos sont longues mais seront supprimées dès qu'orx pourra sérialiser/désérialiser. Ils ne faut donc pas prendre peur en les regardant, la partie intéressante se situant dans les fonctions d'update qui, elles, sont beaucoup plus concises.

Pour ceux qui aimeraient une change list plus complète, je les invite à lire le log svn, je vais éviter de la copier ici pour ne pas rendre ce message illisible! =) Il y a principalement eu beaucoup de debug sur le pipeline d'affichage, du changement de fond concernant la gestion interne des horloges, pour homogéniser le tout et permettre une meilleure précision et une meilleure modularité concernant le module "main" pour permettre à de futurs utilisateurs d'orx de développer leur jeu/application soit par plugin (comme les demos montrées), soit en utilisant orx comme une bibliothèque avec une approche plus "classique".

Tout commentaire/réaction seront les bienvenus! Je réitère à ce propos ma demande concernant la recherche d'éventuels cobayes et contributeurs. A votre bon coeur, m'sieur, dames, et merci d'avance! =)

[Laurent Gomila]

C'est vrai que du rendu sur texture pourrait être utile dans SFML, je vais voir si ça ne pose pas trop de problèmes de l'ajouter.

Par contre tu parles d'une modification "légère", or à mon avis ce serait plutôt délicat, donc tu avais quoi en tête ?

[iarwain]

Salut Laurent,

Quand je parlais de modification légère, je parlais pour mon utilisation seulement.

Pour permettre le rendu sur une texture liée à un objet, dans orx, il m'aurait suffit d'avoir accès au "MyGLTexture" de ton objet Image, je me serais occupé de la procédure de binding/rendu avec un FBO dans le code du plugin d'affichage d'orx, en appelant directement les fonctions openGL.

Maintenant, pour supporter le rendu sur texture en natif dans SFML, effectivement, c'est plus long au vu de l'architecture actuelle de SFML concernant le rendu (hop, en passant, ça fait plaisir de voir une bibliothèque claire avec des commentaires réguliers). Je ne suis malheureusement pas encore un expert avec SFML, ne l'utilisant que depuis très récemment et pour mes besoins bien précis, donc je n'ai regardé que ce qui m'était utile jusque là. On peut en discuter plus longuement par PM si tu le souhaites.

A ce propos, si tu as l'occasion de regarder le code d'orx (ou du moins celui des plugins basés sur SFML, si tu vois une mauvaise utilisation de ma part de ta bibliothèque, tiens-moi au courant, je ferai les modifications nécessaires au plus tôt).

[Laurent Gomila]

Pour permettre le rendu sur une texture liée à un objet, dans orx, il m'aurait suffit d'avoir accès au "MyGLTexture" de ton objet Image, je me serais occupé de la procédure de binding/rendu avec un FBO dans le code du plugin d'affichage d'orx, en appelant directement les fonctions openGL

Ok, je comprends. En attendant tu peux effectivement mettre en place un petit ajout du genre sf::Image::GetTexture(), ça te permettra de ne pas rester bloqué.

Maintenant, pour supporter le rendu sur texture en natif dans SFML, effectivement, c'est plus long au vu de l'architecture actuelle de SFML concernant le rendu (hop, en passant, ça fait plaisir de voir une bibliothèque claire avec des commentaires réguliers). Je ne suis malheureusement pas encore un expert avec SFML, ne l'utilisant que depuis très récemment et pour mes besoins bien précis, donc je n'ai regardé que ce qui m'était utile jusque là. On peut en discuter plus longuement par PM si tu le souhaites.

Je pense que ça ne posera pas de problème. Mon principal souci sera à mon avis d'écrire du code le plus portable possible, donc en envisageant autre chose que les FBO pour les petites configs.

A ce propos, si tu as l'occasion de regarder le code d'orx (ou du moins celui des plugins basés sur SFML, si tu vois une mauvaise utilisation de ma part de ta bibliothèque, tiens-moi au courant, je ferai les modifications nécessaires au plus tôt).

Je l'ai déjà regardé, et a priori tu utilises SFML correctement
A part ça félicitations pour ce moteur, il a l'air vraiment bien conçu et efficace.

[iarwain]

Ok, je comprends. En attendant tu peux effectivement mettre en place un petit ajout du genre sf::Image::GetTexture(), ça te permettra de ne pas rester bloqué.

Effectivement, c'est la solution la plus rapide que j'ai à ma disposition, mais dans ce cas il faudrait que je redistribue la version modifiée de SFML avec le plugin correspondant d'orx.
Comme le but est que chaque utilisateur d'orx (un jour, il y en aura, un jour! ^^) n'ait pas à dépendre de modifications spécifiques sur des bibliothèques externes, je ne modifierai mon plugin que le jour où tu auras rajouté le support de rendu sur une texture, ce n'est pas du tout pressé de mon côté.

A vrai dire, les petits démos que j'écris sont simplement à but didactique, rien de plus, ce n'est pas une fonctionnalité qui me bloque outre mesure. Je modifierai ces demos (qui sont plus des examples, à vrai dire) au fur et à mesure de l'évolution d'orx. Par exemple, dès que j'aurai créé l'interface pour des plugins de dynamique et de collision, je ferai descendre la balle depuis l'escalier dans la demo "orxCave".

Je pense que ça ne posera pas de problème. Mon principal souci sera à mon avis d'écrire du code le plus portable possible, donc en envisageant autre chose que les FBO pour les petites configs.

Je comprends tout à fait cette contrainte.

Je l'ai déjà regardé, et a priori tu utilises SFML correctement
A part ça félicitations pour ce moteur, il a l'air vraiment bien conçu et efficace.

Merci pour ce retour positif!
Si, dans le futur, tu vois une quelconque anomalie, n'hésite pas à la mentionner, je n'ai malheureusement à ce jour quasiment aucun autre retour.

Je continuerai d'ailleurs à poster ici les divers avancements (les prochaines étapes sont un module d'events mis à jour, la gestion généralisée des inputs, l'ajout des fonctionnalités liées aux collisions et à la dynamique), malgré le peu de retours que j'ai eus jusqu'ici.

Au fait, pour d'éventuels intéressés qui aurait pris peur quand j'ai annoncé qu'orx était codé en C, il est tout à fait possible de développer vos applications en C++, par exemple, en ne se servant d'orx que comme une bibliothèque quelconque ou même en utilisant le système de plugin dynamique. C'était juste histoire de préciser, au cas où!

[LLB]

Cool d'avoir des nouvelles d'Orx !

J'ai suivi de loin le développement de la Guerre des Pâquerettes (et je connais bien un des musiciens, Cyborgjeff) mais j'ai été déçu de le voir abandonné. Il y a une chance que le développement reprenne quand Orx sera plus avancé ?

[iarwain]

Wow, la GdP, c'est pas tout neuf ça! =)

Malheureusement tous les rats (moi y compris) ont quitté le navire. Seul le site perdure (mais j'avoue que finalement je ne sais plus trop pour quelle raison, la nostalgie peut-être?).

Même orx est resté à l'abandon pendant plus d'un an, et je suis le seul à m'y être remis. Les derniers archivages d'autres programmeur se comptent en mois voire même en années, malheureusement. :/

Donc, après ce constat, j'ai bien peur que la Guerre des Pâquerettes ne revienne pas. Dans tous les cas ce n'est pas planifié!

Mes amitiés à CyborgJeff dont je n'ai pas de nouvelles depuis des lustres et merci pour ton msg!

PS : Sympa le blog ASCII! ^^

[LLB]

Donc, après ce constat, j'ai bien peur que la Guerre des Pâquerettes ne revienne pas. Dans tous les cas ce n'est pas planifié!

OK, dommage.

Mes amitiés à CyborgJeff dont je n'ai pas de nouvelles depuis des lustres et merci pour ton msg!

PS : Sympa le blog ASCII! ^^

Je transmettrai le message, et merci pour le commentaire !

[iarwain]

Hello tout le monde!

Hey oui, 10 mois plus tard, enfin une mise à jour! =)

A vrai dire pendant ces 10 mois beaucoup de travail a été exécuté sur le moteur qui permet maintenant de développer sous windows (mingw, msvs2005 & msvs2008) et linux. Un port pour GP2X est en cours, et PSP/DS suivront.

Commençons par le commencement! =)

Tout d'abord, orx a déménagé! Un site principal : http://orx-project.org vient d'être ouvert et manque encore un peu de style et de contenu mais c'est en bonne voie. La page sourceforge quant à elle se trouve maintenant sur http://orx.sourceforge.net.

Arcallians ne se charge plus du développement d'orx depuis le mois de juillet, et la main a été passée à orx-project.

Orx vient tout juste d'être releasé en version 0.9.0b! Il y a eu énormément de changements depuis l'année dernière. En vracs:
- orx est maintenant data driven et tout (ou presque) se paramètre fracilement par fichiers de config. Plus besoin de recompiler et quelques lignes de codes permettent de faire des choses complexes de façon très facile.
- la physique (+collisions) a été rajoutée via un plugin basé sur Box2D
- la gestion du son et de la musique a été rajoutée
- on peut créer aisément des effets visuels en combinant des courbes de formes différentes (sinus, dents de scie, linéaire) et en les appliquant sur des propriétés d'objets telles que couleur, alpha, scale, rotation ou translation. Tout ceci géré par fichier de config et modifiable en cours d'exécution!
- le graphe d'animation est maintenant complètement fonctionnel et permet de facilement animer vos objets/personnages avec très peu de code!
- un système d'évènements vous prévient des changements d'animation, des lectures d'effets sonores ou encore des collisions en physique de façon très simple (pas de polling)
- documentation doxygen à jour
- beaucoup d'autres choses encore!

Mais surtout: 10 tutoriaux "basic" sont disponibles (source + binaires compilés pour windows et linux) et vous permettent de découvrir facilement le moteur, ses possibilités et vous permettent de découvrir pas à pas l'utilisation d'orx qui ne ressemble pas vraiment aux autres moteurs dont vous pouvez avoir l'habitude!

A venir pour la version 1.0: la gestion du scripting et des packages.
Un tutoriel avancé (mini platformer) sera aussi ajouté pour la version 0.9.1 ainsi que quelques autres fonctionnalités comme la gestion de la vitesse des objets via les données d'animation...

Tout commentaire est le bienvenu et n'hésitez pas à poser vos questions directement sur le forum du site!

PS: Si quelqu'un dispose d'un mac sous Mac OSX et qu'il serait intéressé par packager orx pour cette plateforme, qu'il me fasse signe! =) De même si quelqu'un souhaite écrire des wrappers pour des langages tels que python, C++ ou D!

En espérant avoir de vos nouvelles très prochainement! =)

- iarwain

[screetch]

Salut, j'ai une question au sujet de ton projet ; je fais moi meme un projet assez similaire. Il a ete construit, de ce que je comprend, a partir des memes idées (plugins, modularité, services). J'ai commencé par le systeme de scripting (la brique C++ du moins) avant de faire beaucoup d'autres choses. la premiere difficulté rencontrée a ete le systeme de construction; comme toi, on peut construire a partir de mingw, vs 2005 et vs 2008 (mingw 32 et 64) et je regarde passivement comment faire avec la GP2X et la PSP. ca compilait aussi, il fut un temps, sous linux, et je le remettrai quand j'aurai le temps. Neanmoins, pour developper, j'utilise visual C++, et c'est un cauchemar de maintenir les solutions a jour
as tu eu recours a un generateur de solutions ? ou comment as tu fait ?

[iarwain]

Salut screetch,

Effectivement on se servait d'un générateur de build file appelé bakefile (celui du projet wxwidgets). Par contre il a longtemps été buggé et il n'est pas souvent mis à jour. On s'en sert néanmoins encore pour générer les makefiles pour mingw, visual (cl) linux et aussi la version autoconf de linux.
J'ai laissé la création des projets pour xcode active mais n'ayant pas accès à un mac je n'ai jamais pu la tester.

Par contre, j'ai désactiver la création des projets pour msvs2005, car le projet que celà créé ne faisait pas vraiment sens, que ça soit au niveau de la nomenclature ou des targets de compilation.

Ce qui fait que les projets pour code::blocks, codelite, msvs2005 et msvs2008, j'ai du me les taper à la main! ^^ Et le jour où j'aurai accès à un mac, je ferai probablement de même avec xcode.

Si tu trouves la solution idéale, je suis preneur, car mine de rien ça prend beaucoup de temps de maintenir ça, surtout qd tu te retrouves avec 10 targets de compilation différentes (sous codelite j'en ai 4 pour windows et 4 pour linux: static/dynamic debug/release + 2 pour GP2X).
Je ne me sers plus vraiment de bakefile, je vérifie juste que les fichiers soient à jour et les makefiles encore utilisable, mais je développe principalement sous codelite (win/linux/gp2x) et debug sous windows avec msvs.

J'espère que ça répond à ta question, si tu en as d'autres, n'hésite pas! =)

- iarwain

[screetch]

et bien moi j'etais parti sur une solution a base de SCons et du python en pagaille. le probleme c'est que je supporte pas le python (je suis allergique au duck typing) mais je m'y fais.
J'ai reecrit la generation de solutions pour satisfaire a mes besoins.
Je suis assez difficile, il me FAUT absolument que :
- scons detecte les sources tout seul. si je fous un CPP sur mon disque, c'est pas pour faire joli. Je vais pas lui filer la liste.
- scons gere les dependences que je lui donne. si je lui dit que B a besoin de A il saura que les fichiers include de A peuvent etre inclus a B et qu'il faut lier A a B. Je vais pas lui expliquer tout a la paluche.
- Je veux pouvoir lier une lib a un exe; la dessus je suis assez exigeant car SCons ne connait pas cela. Mais je genere des libs statiques, et un programme, et un plugin. Lors de la liaison, le programme est egalement une DLL du jeu, et le plugin est lié dynamiquement au jeu pour pouvoir acceder aux singletons. C'est tout a fait faisable sur linux et windows, mais scons ne le prenait pas en compte.
- Je veux pouvoir developper avec autre chose que VIM, donc la generation de solution automatique. C'est source d'erreur de maintenir ses solutions, on peut oublier des fichiers, ou changer des options de comilation sur un projet mais pas les autres. Relou.

La dessus j'ai resolu pas mal de ces problemes, mais pour cela j'ai l'impression d'avoir reecrit la moitié de SCons... alors si un autre programme le fait mieux, je dis pas non.

J'ai aussi voulu ajouter la generation de projets CODE::BLOCKS mais cet IDE ne gere pas bien les fichiers lex/yacc (double compil necessaire car il ne savait pas faire les dependences necessaires). J'avais jamais vu codelite par contre, je vais regarder a quoi ca ressemble.

[iarwain]

et bien moi j'etais parti sur une solution a base de SCons et du python en pagaille. le probleme c'est que je supporte pas le python (je suis allergique au duck typing) mais je m'y fais.

Je compatis ^^

J'ai reecrit la generation de solutions pour satisfaire a mes besoins.
Je suis assez difficile, il me FAUT absolument que :
- scons detecte les sources tout seul. si je fous un CPP sur mon disque, c'est pas pour faire joli. Je vais pas lui filer la liste.
- scons gere les dependences que je lui donne. si je lui dit que B a besoin de A il saura que les fichiers include de A peuvent etre inclus a B et qu'il faut lier A a B. Je vais pas lui expliquer tout a la paluche.
- Je veux pouvoir lier une lib a un exe; la dessus je suis assez exigeant car SCons ne connait pas cela. Mais je genere des libs statiques, et un programme, et un plugin. Lors de la liaison, le programme est egalement une DLL du jeu, et le plugin est lié dynamiquement au jeu pour pouvoir acceder aux singletons. C'est tout a fait faisable sur linux et windows, mais scons ne le prenait pas en compte.

J'avais aussi pensé à SCons, cmake et autres utilitaires de la même trempe, mais je n'avais pas assez de temps à investir pour connaître les possibilités de chacun (j'ai déjà beaucoup à faire avec le moteur en lui-même, alors j'ai un peu délaissé tout ce qui est annexe).

Je vois tout à fait ton problème pour le link du jeu en dll sur l'exe, orx permet aussi de développer des jeux en plugins DLL (c'est plus rapide pour du prototypage je trouve, et ça permet simplifie grandement l'accès aux utilisateurs pas forcément avancés). Je suis content d'avoir ton retour sur SCons, ça me montre que ce n'est pas forcément non plus de ce côté qu'il faut que je m'oriente donc...

- Je veux pouvoir developper avec autre chose que VIM, donc la generation de solution automatique. C'est source d'erreur de maintenir ses solutions, on peut oublier des fichiers, ou changer des options de comilation sur un projet mais pas les autres. Relou.

A qui le dis-tu! ^^ Je me sers régulièrement d'emacs, msvs2005, msvs2008, codelite, code::blocks et eclipse/cdt pour le dév d'orx. Maintenir les build files divers et variés est une vraie plaie. Mais j'ai pris le coup, et à l'aide de quelques macros j'édite directement les fichiers xml pour tous ce ptit monde (msvs200X, codelite, code::block). Il ne me reste qu'à automatiser la procédure si un jour je trouve un peu de temps. Peut-être si la communauté d'orx grandit, mais pour le moment en travaillant 35-45h par semaine sur le projet (en plus de mes 40h pour Ubi), je t'avoue qu'il me manque la motivation pour m'occuper des build files...

La dessus j'ai resolu pas mal de ces problemes, mais pour cela j'ai l'impression d'avoir reecrit la moitié de SCons... alors si un autre programme le fait mieux, je dis pas non.

As-tu essayé de contacter les auteurs de SCons? Peut-être pourront-ils t'aider avec les cas à problème que tu as rencontrés?

J'ai aussi voulu ajouter la generation de projets CODE::BLOCKS mais cet IDE ne gere pas bien les fichiers lex/yacc (double compil necessaire car il ne savait pas faire les dependences necessaires). J'avais jamais vu codelite par contre, je vais regarder a quoi ca ressemble.

Je ne continue à maintenir les fichiers pour code::blocks seulement car son utilisation est répandue. Je trouve cependant codelite (http://codelite.org) bien meilleur et son auteur, en plus d'être à l'écoute de ses utilisateurs, est très réactif pour corriger les bugs et rajouter de nouvelles features, ce qui n'a pas de prix! =)

[sinok]

Juste pour une piste, après avoir été étudié très sérieusement par kde pour la mise en place de leur solution de build multiplateforme de la version 4, scons s'est fait voler dans les plumes par CMake qui semble être un outil plus que puissant.

Un article expliquant le choix de CMake par KDE: http://lwn.net/Articles/188693/

[Matthieu Brucher]

Juste pour une piste, après avoir été étudié très sérieusement par kde pour la mise en place de leur solution de build multiplateforme de la version 4, scons s'est fait voler dans les plumes par CMake qui semble être un outil plus que puissant.

Un article expliquant le choix de CMake par KDE: http://lwn.net/Articles/188693/

Ce n'est qu'un point de vue, et la communauté SCons en a un autre, critique envers KDE cette fois-ci. Il y a des torts de part et d'autre, sachant aussi que SCons ne vient que de sortir en version 1.0.

Personnellement, c'est mon outil favori, et de loin. Ce que screetch cherche est fourni par SCons depuis longtemps (sauf le coupd e la dépendance, mais je ne suis pas d'accord avec lui, et SCons pense à ajouter un noeud Library pour gérer plus efficacement celle-ci).