Auteur Sujet: Demo Engine - pourquoi, comment?  (Lu 6493 fois)

0 Membres et 1 Invité sur ce sujet

Je suis bien d'accord avec ce qui a été dit, mais j'ai l'impression qu'on oublie un truc.
Un demoengine - pour moi - ce n'est pas juste un moteur 3d (pardon pata, un renderer ;)) et tout ce qu'il faut pour créer rapidement et facilement des effets.
C'est aussi toute la mécanique pour agencer les effets entre eux, gérer les synchros, leurs paramètres, en mixer plusieurs ensemble etc...

Bref pour moi le gros du demo engine se situe là dedans. (et je suis preneur de tout avis sur comment faire ça bien ^^)

Je suis bien d'accord avec ce qui a été dit, mais j'ai l'impression qu'on oublie un truc.
Un demoengine - pour moi - ce n'est pas juste un moteur 3d (pardon pata, un renderer ;)) et tout ce qu'il faut pour créer rapidement et facilement des effets.
C'est aussi toute la mécanique pour agencer les effets entre eux, gérer les synchros, leurs paramètres, en mixer plusieurs ensemble etc...

Bref pour moi le gros du demo engine se situe là dedans. (et je suis preneur de tout avis sur comment faire ça bien ^^)

L'approche classique est la gestion des événements basée sur le temps et la musique. Je n'ai jamais voulu écrire du code qui lise
des scripts. Je trouve que ça augmente le travail pour pas grand-chose... Je récupère les valeurs importantes (speed, beat, spectrum, order, row, ...)
à chaque update et je m'en sers directement dans les effets. C'est plus dynamique à mon sens... On peut utiliser ces valeurs où l'on veut.
A l'instinct :)

Voir "demoprogrammingbasics" dans google pour le timing.

pour rebondire avec ce qui a été dit plus haut a propos des moteurs "simples".

Faire un système "simple" n'est pas evident du tout mais alors pas du tout du tout, c'est le contraire.
C'est toujours bien plus facile de faire des systèmes complexes dans lequel le programmeur peu avoir la sensation de créer quelque chose de consistent alors qu'il se noie tout seul.
Patapom dit qu'il arrive a faire un framework simple mais il ne faut pas oublié que ce n'est pas son 1er et qu'il a lui aussi succombé ( comme tout le monde ) a la complexité abstractionnelle aigue.
Bref ecrire un "moteur" de demo / 3D ou un systeme de ce genre n'est pas quelque chose aisée pour un  programmeur et c'est normal. il n'y a que l'expérience et l'expérience encore qui permettra au programmateur de simplifier son code afin de n'y ajouter que le strict nécessaire.

Enfin pour ce qui est de l'intéret de re-coder ou d'utiliser une librairie tierce? a mon avis il n'y a pas de règle dans le domaine.
- d'un coté recoder ( qui ne veut pas dire ré-inventer la roue ) demande du temps et de l’énergie mais est gratifiant car le coder maitrise ce qu'il fait et le comprends.
- de l'autre utilisé une API fait gagné du temps ( si on a de la chance ) mais demande de rentré dans une logique, une syntaxe, tierce qui demande aussi une gymnastique intellectuelle ( et un temps de recherche ) moins "util" selon moi. Et plus l'API fait 36000 choses et plus c'est difficile d'evaluer un gain de temps par rapport a un code from scratch.

Mieux vaut maitrisé une petite fonctionnalité plutot que de ne pas savoir faire fonctionner correctement un gros système.

Dans tout les cas il va falloir aux padawans programmeusr des heures et des heures de pratiques, d'essai et de teste avant d'arriver a faire quelque chose de consistant et de différent. il n'y a pas de magie selon moi ( surtout en demo ). Par contre il faut savoir se faire plaisir ( comme le conseil pata ) avec des petits programmes simples utilisant une fonctionnalité précise et qui fonctionne. Ca permet de se montrer que l'on arrive a atteindre ses objectifs et en plus cela permet d'améliorer la robustesse de ce que l'on développe.

Bon aller je la ferme j'ai été trop long.... on dirait un vieux con. :'(

C'est aussi toute la mécanique pour agencer les effets entre eux, gérer les synchros, leurs paramètres, en mixer plusieurs ensemble etc...

Bref pour moi le gros du demo engine se situe là dedans. (et je suis preneur de tout avis sur comment faire ça bien ^^)
Complètement d'accord. Dans Incubation, entre la gestion de la caméra, la synchro de la caméra avec les animations, synchro des animations entre elles, et synchro des animations avec la musique... ça nous ont pris un temps fou. On a dû repousser la release de plusieurs mois. Réussir à faire proprement les transitions entre les différentes scènes était long et difficile aussi (et il y a plein de problèmes dans ce qu'on a fait).

Dans un moteur de démo, il faut au minimum une bonne gestion du temps : pouvoir mettre en pause, accélérer, voir au ralenti, revenir en arrière. Il faut pouvoir contrôler les différents paramètres et avoir l'aperçu en temps réel. Il faut une gestion des animations, une bonne gestion de la caméra (mouvements fluides à base de courbes). Il faut pouvoir modifier les textures, les shaders et les modèles et avoir le résultat aussitôt (sans recompiler / relancer la démo).

Mais comme l'a dit @lx, faites des démos avec. Quand vous obtenez quelque chose de sympa, vous pouvez commenter et publier le code source, écrire des articles, etc. pour aider les débutants.

Pour ce que ça vaut...
Je me suis récemment mis au C++ et à OpenGL sous Windows. Mon background c'est le Basic, un peu d'asm sur amiga il y a 20 ans, beaucoup de PHP et un peu d'ActionScript.

Après avoir passé un certain temps à configurer et à comprendre mon IDE (Code::Blocks), j'ai écumé tous les sites/blogs/forums/sources OpenGL, de game dev et de demomaking que j'ai pu trouver : NeHe, iq, dbf, gamedev, etc.

Pour toutes les explications de "game loops" que j'ai pu trouver, j'ai fait des essais d'implémentation jusqu'à arriver à faire tourner un truc qui me convienne. J'ai disséqué chacune des sources que j'ai pu trouver et j'ai fait des recherches sur ce que je ne connaissais/comprenais pas.

Bon, y a plein de trucs que je ne comprends toujours pas : entre les projets faits pour VS que j'essaie souvent vainement d'adapter à C::B ou les effets oldschool datant de l'époque DOS, le fait qu'en C++ je me mélange souvent les pinceaux entre les machins* et les &bidules, et le fait que je suis une truffe en maths...

Tout ça pour dire que je suis probablement pile dans la cible d'un tel outil. Mais personnellement, un "framework" ou un "demo engine", je ne l'utiliserais pas pour produire quoi que ce soit, parce que mon but c'est plus de savoir fabriquer la roue que de m'en servir. Donc, les effets "intégrés", je ne voudrais pas utiliser sans les comprendre mais en même temps je n'ai aucune idée de comment sont créés les autres effets "classiques" que je pourrais vouloir intégrer.

Par contre j'essaierais de le disséquer pour voir comment sont gérés les timers et les synchros, comment sont gérés/enchaînés les effets, comment sont gérées la scène, la caméra, etc. et comment sont produits les effets (s'il y en a par défaut, donc) pour tenter de reproduire et d'adapter ce que j'aurais compris (et pas juste de copier des bouts de sources) dans mes propres trucs. Et s'il y avait des explications (tutorials/articles) en plus des sources, ça serait encore mieux.

En fin de compte, j'aurais tendance à penser que sur 10 prods faites à partir d'un tel outil on aurait 8 fois la même démo avec des logos différents. Personnellement je n'éprouverais aucune satisfaction à compiler avec succès un code hyper chiadé pondu par quelqu'un d'autre, alors que je suis hyper fier de mon cube tout pourri avec son éclairage tout moisi qui tourne au milieu de ma fenêtre. Mais si je pouvais être encore plus fier en y ajoutant (par exemple) un plasma que j'aurais implémenté moi-même et dont j'aurais compris la logique et le fonctionnement, ça serait encore mieux :)

Enfin, comme dit au début : "pour ce que ça vaut..."  ;)