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

0 Membres et 1 Invité sur ce sujet

azerty^TRSI

  • Invité
Salut à tous,

Je suis en train de me documenter et de cogiter sur la possibilité de créer un moteur démo
destiné à ceux qui n'ont pas envie de se retaper tout le boulot. Il ne s'agit pas d'un outil avec GUI
ou d'un simple framework mais plutôt d'une bibliothèque de fonctions C/C++ elle-même basée sur d'autres libs
car, moi non plus, je veux pas réinventer la roue, surtout pour ouvrir une fenêtre OpenGL
et gérer les E/S. Car je voudrais que le moteur soit multiplateforme (Windows/Mac/Linux).
C'est pour cela que j'ai choisi GLFW comme lib de base...

Je voudrais donc ouvrir une discussion sur les facilités que devrait offrir un tel moteur. Toutes les idées
et suggestions ainsi que vos témoignages m'intéressent. Que trouvez-vous utile? Qu'est-ce qui ne l'est pas?
Avez-vous tenté telle ou telle approche et a-t'elle abouti?

Je sais que le sujet est vaste...

Merci d'avance pour toute réponse,
azerty

Déjà fait. libcinder, frontend d'outtracks (site offline), ogre3D, etc. Tu ne veux pas réinventer la roue ? Y'en a déjà plein de différentes, enjoy the fnu.

Déjà fait. libcinder, frontend d'outtracks (site offline), ogre3D, etc. Tu ne veux pas réinventer la roue ? Y'en a déjà plein de différentes, enjoy the fnu.

Ma motivation est aussi de réunir mes connaissances dans ce projet, ainsi que d'en acquérir de nouvelles.
C'est ce que j'ai envie de faire pour l'instant. Je ne connaissais pas libcinder. Je vais m'y intéresser.
Quant à Ogre3D, Irrlicht, etc... j'ai déjà essayé et apprécié bien que ce soit des API très "verbeuses".
Pour ma lib, je voudrais qu'on ait le moins de code possible à taper...

* Fais une démo. Elle sera loin d'être parfaite.
* Fais une 2e démo en identifiant le code que tu peux réutiliser de ta première démo et en corrigeant les gros problèmes.
* Fais une 3e démo en améliorant ta base de code et tu sauras alors exactement de quoi tu as besoin.

Commencer par coder un moteur générique me semble être une mauvaise idée.

Ce que je vois d'essentiel pour bien commencer (toute ressemblance avec Nuaj' est purement fortuite ;D ) :

* Créer une Device
 => Gérer la target et le depth/stencil "default"
 => Gérer les RenderStates
 => Gérer les DepthStencilStates
 => Gérer les BlendStates
 => En helpers, des "stock states" pour se simplifier la vie :
   _ Pour les blend states : ADD, MUL, SUB, etc.
   _ Pour les render states : CULL_BACK, CULL_FRONT, NO_CULLING, etc.
   _ Pour les depth states : WRITE_CLOSEST, WRITE_CLOSEST_OR_EQUAL, NOWRITE, DISABLED, etc.

* Ouvrir un viewport dans n'importe quel HWND
 => En helper, un truc qui crée une fenêtre from scratch avec un viewport dedans

* Créer une texture 2D / 3D à partir d'un array de valeurs et leurs mips
 => En helpers, des loaders de formats (JPG, PNG, TGA, etc.) in memory qui génèrent un array de valeurs et leurs mips que tu rebalances au constructeur de texture

* Créer une render target 2D / 3D
 => Gérer les render target arrays
 => Pouvoir setter n'importe quel index dans l'array ou n'importe quel mip level comme render target dans la device (i.e. rendre dans un mip level particulier)

* Créer un matériau à partir d'un bytecode de shader
 => En helper, le compilo qui prend le code source du shader (VertexShader, GeometryShader, PixelShader)
 => Locker le matériau pour utilisation (current material)
 => Setup de variables (scalaires, vectors, matrix, resources)

* Créer un Vertex Buffer à partir d'un vertex format et d'un array de vertices
 => Une méthode "Use" (current VB)
 => Une méthode "Render" pour rendre le VB non indexé

* Créer un Index Buffer à partir d'un index format (int ou short) et d'un array d'indices
 => Une méthode "Use" (current IB)
 => Une méthode "Render" pour rendre le VB indexé par l'IB

* En bonus, créer une classe "Primitive" qui aggrège un VB et un IB optionnel
 => Une méthode "Render" qui va rendre la primitive (indexed si l'IB est présent, sinon non)

* Une classe "Camera" avec la matrice caméra, le type de projection, etc.
 => C'est pas à proprement parler une feature DirectX ou OpenGL mais ça sauve la vie


Tout le reste n'est que surcouche. Par contre, j'appelle pas ça un moteur moi, juste un renderer. D'ailleurs je crois pas que beaucoup de gens aient vraiment créé de vrais moteurs 3D à proprement parler. 3DSMax c'est un moteur 3D par exemple...

NOTE 1 : J'insiste à MORT sur le fait de faire le strict minimum et le plus simple possible !
NOTE 2 : Bien faire un projet d'exemple qui teste chaque feature ! C'est le meilleur moyen de pas laisser de bug...
NOTE 3 : Pour bien insister sur la simplicité (cf. Note 1), ne pas partir sur l'idée que des templates avec des traits et des singletons d'autoptr de choucroute, c'est quelque chose de malin et que ça va plaire aux users ! ;D (donc déjà, t'oublies d'inclure boost, ça te fera des vacances)

Ha, cool, j'ai tout ça dans mon truc perso. Moi j'appelle ça un framework. Bon bah j'ai un framework perso \o/
Faudra que je push tout ça sur github alors.

Edit: Si ça intéresse quelqu'un, mon bout de machin : https://github.com/msklywenn/TrollFramework

Salut,

Moi aussi, je bosse sur le projet avec azerty. Il me reprendra si je dis des bêtises.

J'ai déjà un framework que j'ai créé pour faire mes démos, azerty a déjà le sien aussi et à déjà créé plusieurs démos (c'est de toute façon ce que tout le monde fait pour se simplifier la vie).

Le projet sera axé "demomaking". Il s'adressera aux personnes qui débutent en C/C++ et qui veulent se lancer dans la programmation "démo".
C'est donc un "framework" fait à partir de lib connues (openGL, DevIL, Bass), mais qui se veut simple à prendre en main et multiplateforme avec des effets classiques de démos faciles à créer.

Nous ne voulons pas faire un "demotool" qui mâcherait le boulot, c'est plutôt dans le but de promouvoir la programmation et la scène démo (au passage encore bravo à FRequency pour PERIODIC - demotool mais où la programmation reste l'élément principal).

Beaucoup de gens veulent se lancer dans la démos mais sont bloqués par des questions 'basiques' "comment coder un plasma?"
Là on pourra créer et afficher un plasma facilement du genre:
plasma->Draw(float time);
Et tu pourras voir le code et le modifier (tu crées et tu es content, tu vois la technique et si tu t'y intéresses un peu du va chercher plus loin).

Idem pour les shaders, on fera sans doute une lib de shaders "prêts à l'emploi".... etc.... Tu veux juste créé quelque chose tu pourras le faire facilement, si tu veux aller plus loin, tu peux voir le code et l'améliorer où le personnaliser..........

De toute façon, nous on fait ça pour le fun, c'est l'état d'esprit "demoscene". Et azerty et moi on veut faire une démo ensemble alors autant mettre en commun nos propres fonctions dans un seul framework (au moins si ça sert pas aux autres, ça nous servira)
 
Enfin, c'est comme ça que je vois les choses.............. Après c'est une opinion perso :)











Beaucoup de coders ont mis leur framework en public domain open source.
- Nuaj' avec Patapom
- Romain fait aussi un framework
- http://pouet.net/prod.php?which=57026 de Littlewhite est Linux/Windows.

Bref je pense qu'en panachant du code de tout le monde ça peut devenir très rapide de faire son framework ! A condition de greeter en conséquence :)
Je dis ça parce que je constate que tout le monde veut son framework perso et que ça me semble pas spécialement dommageable.

Salut,

Moi aussi, je bosse sur le projet avec azerty. Il me reprendra si je dis des bêtises.

J'ai déjà un framework que j'ai créé pour faire mes démos, azerty a déjà le sien aussi et à déjà créé plusieurs démos (c'est de toute façon ce que tout le monde fait pour se simplifier la vie).

Le projet sera axé "demomaking". Il s'adressera aux personnes qui débutent en C/C++ et qui veulent se lancer dans la programmation "démo".
C'est donc un "framework" fait à partir de lib connues (openGL, DevIL, Bass), mais qui se veut simple à prendre en main et multiplateforme avec des effets classiques de démos faciles à créer.

(...)

Beaucoup de gens veulent se lancer dans la démos mais sont bloqués par des questions 'basiques' "comment coder un plasma?"
Là on pourra créer et afficher un plasma facilement du genre:
plasma->Draw(float time);
Et tu pourras voir le code et le modifier (tu crées et tu es content, tu vois la technique et si tu t'y intéresses un peu du va chercher plus loin).

(...)

Donc si vous avez déjà chacun un framework, vous voulez juste faire une lib d'exemples ? C'est pas du tout ce qui avait été annoncé en début de post !
Mais là encore, vous pourriez plutôt faire des articles sur un site qui expliqueraient comment faire tel ou tel effet, avec un zip avec le code et tout. Ca serait à mon avis + intéressant que d'écrire du code destiné aux gens qui veulent faire de la démo...

Il faut partir du prémisse que les programmeurs sont souvent "prétentieux" (surtout quand on est jeune, et surtout dans la démo puisque ça va souvent de paire !) et qu'ils préfèrent refaire le code eux-même plutôt que d'utiliser du code déjà fait. Vous courrez le risque d'écrire plein de code qui ne sera jamais utilisé par personne, sauf quelques petits bouts par-ci par-là.
Libre à vous de le faire cependant, mais j'ai déjà fait un truc comme ça avec Nuaj' et je doute que qui que ce soit sur Terre l'ait downloadé (dommage que j'aie pas mis de compteur d'ailleurs, juste par curiosité).

En parallèle, vous avez des sites comme celui de Nehe (http://nehe.gamedev.net/) et d'Humus (http://www.humus.name/index.php) (qui a eu un bébé !) qui sont sans doute des références pour les débutants et qui se contentent d'écrire des articles bien faits sur telle ou telle technique.
Mais encore une fois, ça existe déjà...

Bref, c'est très difficile à notre époque de ne pas ré-inventer l'eau chaude...

Bon je vais encore faire un peu de Patapom-centric quelques instants mais si vous voulez savoir ce qui m'a motivé à faire Nuaj', dans le cas où votre problème serait la motivation ou la direction que vous voulez prendre, c'est essentiellement de faire des effets.

J'avais besoin d'un petit framework de rendu, simple à utiliser, qui me permette de coder n'importe quel effet en 2 coups de cuillère à pot. D'où le choix de le faire en C# puisque c'est le langage idéal pour monter une application en 5 secondes.

Le truc c'est que j'ai souvent des idées un peu farfelues et que j'ai besoin de les tester immédiatement et le + vite possible. Je n'ai pas essayé de faire une usine à gaz avec des factories et des providers et des binders et compagnie, ça ne me fait pas peur de copier/coller du code pour initialiser ma fenêtre et ma device puisque de toute manière généralement je copicol le projet complet, je change le GUID du CSPROJ et j'adapter les classes existantes pour ma nouvelle technique.

C'est seulement + tard, quand j'avais déjà quelques effets terminés et testé assez extensivement toutes les features du renderer que je me suis dit que ça pourrait p'têt servir à des gens et que j'ai foutu le repository en libre accès...

Mais je ne suis pas du tout parti de l'idée de faire quelque chose "pour les autres", seulement quelque chose "pour moi". Quelque chose qui me soit utile et qui soit  SIMPLE.

Et quand je dis simple (j'insiste énormément sur ce concept !), c'est quelque chose (une fonction, une API, une philosophie, etc.) que je puisse reprendre dans 6 mois et que ça me paraisse toujours aussi évident. Et pour l'instant ça l'est toujours, donc pour moi le pari est gagné et je pense que plus grand-chose ne changera désormais dans le bas niveau du renderer.

Donc réfléchissez bien : pour quoi est-ce que vous voulez faire ce que vous voulez faire ? Est-ce que vous pensez sincèrement, en gardant l'esprit chafouin ;D du coder de démo lambda en tête, que votre travail servira ? Ne voulez-vous pas qu'il vous serve d'abord à vous avant de le distribuer au monde ?


J'ai vraiment l'impression de décourager les gens dans ce thread...  :(

Je viens apporter mes deux centimes de zikos qui code comme un pied et qui peut pas se concentrer plus de 10 minutes (5 si ya de la bière à côté)... mais j'aimerais comprendre le but de faire un blabla->plasma() ... je veux dire par là que le but de coder un plasma est de coder le plasma, de l'optimiser, de le modifier, afin qu'il devienne "ton plasma" non ?

Bref, à part avoir un outil pour, comme le dit Patapom, tester rapidement des effets, je vois pas l'intêret de vouloir ajouter des effets faciles façon "toi aussi, fait ton brainshock to japanese brains en quelques minutes"

Oui, c'est un point de vue.
Pour ma part, ça partait d'un bon sentiment... Histoire de voir le nombre de prods françaises augmenter un peu.

Du coup, je retiens qu'il faut que je garde mon framework pour moi, je fasse mes démos et que j'emmerde les autres (surtout les codeurs débutants prétentieux) :D.

Donc réfléchissez bien : pour quoi est-ce que vous voulez faire ce que vous voulez faire ? Est-ce que vous pensez sincèrement, en gardant l'esprit chafouin ;D du coder de démo lambda en tête, que votre travail servira ? Ne voulez-vous pas qu'il vous serve d'abord à vous avant de le distribuer au monde ?

J'abonde dans ce sens.
Travailler d'abord ce framework pour vous, pour des démos que vous voulez faire avec. Vous confronterez votre idéal avec la réalité des productions que vous aurez réussi a réaliser avec, ce qui ne pourra d'ailleurs contribuer que positivement a l’évolution du framework. C'est seulement a cette condition que vous réussirez a attirer l'attention de programmeurs débutants qui voudront faire les même démos avec votre framework. C'est un peu ce qui est arrivé avec Werkkzeug de Farbrausch... (ok, même si c'est plutôt un demotool. ryg de Farbrausch a récemment expliqué qu'il pourrait releaser le code de Werkkzeug, mais le code demanderait pas mal de clean, donc c'est plus facile d’écrire des articles sur les techniques qu'ils ont développé!)
Plus près de chez nous, xt95 a développé un framework Yuka Engine avec lequel il a releasé au moins une démo avec (a ma connaissance, c'etait l'invit pour la main "Hall Of Frames"!), ou Periodic qui a aussi été utilisé pour faire deux prods. Dans les deux cas, il a rendu accessible le code en open-source.

De toute façon, nous on fait ça pour le fun, c'est l'état d'esprit "demoscene". Et azerty et moi on veut faire une démo ensemble alors autant mettre en commun nos propres fonctions dans un seul framework (au moins si ça sert pas aux autres, ça nous servira)

Exactement! C'est le meilleur moyen de vous motiver sur la durée pour améliorer ce framework. Vous verrez ensuite comment faire fructifier un fan club! ;)
Bon courage!

Oui, c'est un point de vue.
Pour ma part, ça partait d'un bon sentiment... Histoire de voir le nombre de prods françaises augmenter un peu.

Non mais je comprend, et ce que je dis c'est juste qu'il faut ptete pas voir le truc comme un générateur d'effets faciles à utiliser mais juste un bon "framework" robuste qui permet d'ouvrir une fenêtre et fournir, par exemple, un moteur qui tourne bien. Genre, je sais que je dis de la merde, mais imaginons qu'on parle de plateforme oldschool, un bon framework permettrait à un débutant de pas se soucier d'optimiser le moment où la machine calcule et le moment où la machine plot (le hsync, vsync, tous ces trucs là... vous moquez pas de moi si je dis une bétise bande de prétentieux)

Du coup, je retiens qu'il faut que je garde mon framework pour moi, je fasse mes démos et que j'emmerde les autres (surtout les codeurs débutants prétentieux) :D.

Et pour cette blague sur les codeurs prétentieux... j'ai déjà pu me rendre compte que les développeurs (que ça soit de la scene ou tout simplement le mec au taff, dans le web par exemple) sont vraiment prétentieux.

Salut à tous,

Je suis entièrement Patapom sur le plan de la simplicité. Il faut pouvoir créer des effets vite et facilement, c'est tout ce qui compte...
Ce que je voudrais faire, c'est permettre aux gens ayant des bases de programmation en C/C++ de s'amuser pleinement avec une
palette de fonctions plus proches du "3D scripting" que du code pur et dur... Mais un shader reste un shader, une texture une texture, etc..
Libre donc aux créateurs de faire quelque chose à partir des facilités offertes par la lib. Tout dépendra de la créativité et du niveau technique.

Voici un petit exemple affichant un cube:

...
...
...

//   Create core module
core = Edengine::instance();
if (!core) return -1;

//   Create Graphics module
gfx = Graphics::instance();
if (!gfx)
{
   delete core;
   core = 0;
   return -1;
}

//   Load texture
iStarTex = gfx->createTexture("data/star.tga");

//   Create main light
light0 = gfx->createLight();
light0->ambient(.1f, .1f, .1f);
light0->attenuation(0.f, .1f, .01f);
light0->position(0, 0, 1);
light0->enable(true);

//   Set state
gfx->enable(TEXTURE_2D);
gfx->enable(LIGHTING);

//   Main loop
do
{
   if (core->active())
   {
...
      //   Draw cube
      gfx->begin3D(60.f, .1f, 100.f);
         gfx->translate(0, 0, -3.f);
         gfx->rotate(r * 4.f, r * 2.f, r * 3.f);
         gfx->box(1.f, 1.f, 1.f, true);    // textured
      gfx->end3D();
      gfx->swap();
   }
} while (!core->key(KEY_ESC) && core->opened());

gfx->disable(LIGHTING);
gfx->disable(TEXTURE_2D);

gfx->destroyLight(light0);

...
...
...