Discussion :

[Kromagg]

Bonsoir à tous

Et bien je pense que le titre ne peut être plus explicite Cependant quelques précisions :
- le noyau est totalement en C++ sur plateforme PC (linux, windows)
- sans librairies annexes : ni gestion de l'input, du son, du temps...

En fait mon problème c'est que je ne vois pas trop quoi mettre dans ce noyau (à part la gestion de plugin) pour qu'il soit totalement indépendant de l'OS et comment il peut tourner sans plugins en fait.

Si vous avez une petite idée, j'achète avec plaisir.

Le débat est ouvert

Naos.

[raptor70]

Beaucoup de chose peuvent être intégrées..
Une petite liste de chose qui me viennent :

• gestionnaire mémoire
• collections (array, set, list, stack..)
• moteur de script
• moteur graphique (2D/3D)
• input
• moteur de son
• système de fichiers
• système d'animations

[Kromagg]

Ok enfin pas de moteur graphique car je compte utiliser une lib externe (Ogre). Les collections je ne vois pourquoi en coder de nouvelles alors qu'elles existent déjà en C++. Le système de fichier on peut se baser sur boost::filesystem ?
Système d'animation, je pense que le moteur 3D le fera pour moi.
Pour la gestion de la mémoire je ne vois pas quoi mettre à par la gestion des new/delete (un peu comme celui de Loulou) sauf que je me baserai sur une liste doublement chainées je pense.
On peut ajouter la gestion cache (LRU, FIFO...) en fonction des besoins.

[raptor70]

Donc finalement :

- sans librairies annexes : ni gestion de l'input, du son, du temps...

n'est tout à fait ce que tu cherches ...

L'intéret des collections codée toi même est le controle complet de leurs allocations et optimisations ...

[screetch]

et thread safety.

tu peux ajouter des choses rigolotes comme des générateurs de noms nains ou orcs, qui sait ?

[Kurisu]

Perso, je limiterais le "noyau" à l'essentiel, ou plutôt je le diviserais en plusieurs sous-noyaus se chargeant comme plug-ins. Principe du micro-kernel peut-être.

Donc le noyau:
- gestion de la mémoire:
-- surcharge de new et delete pour un pool de mémoire
-- spécialisation des collections STL et Boost pour utiliser des allocateurs spécifiques
- gestion du filesystem
- gestion des plug-ins.

Ayant ceci, j'attaquerais les sous-noyaus, dont:
- le renderer
- le gestionnaire de ressources
- le module de son
- gestionnaire des modules logiques
- moteur de script

Puis je passerais au moteur de logique proprement dit:
- gestion des évenements,
- logique du jeu proprement dite (et là, ca va forcément dépendre du jeu)
- pour un RPG: gestion de l'histoire
- pleins de trucs qui me viennent pas à l'esprit...

Voilà, ca représente pas mal de boulot, même en utilisant un framework graphique prêt à l'emploi. Bon courage.

[Kromagg]

Super Kurisu, c'est exactement ce que je cherche, une description en profondeur

Tu ne vois pas d'inconvénients à ce que je reprene tes idées (en gros) ?

Naoss.

[deadalnix]

Perso, je limiterais le "noyau" à l'essentiel, ou plutôt je le diviserais en plusieurs sous-noyaus se chargeant comme plug-ins. Principe du micro-kernel peut-être.

Donc le noyau:
- gestion de la mémoire:
-- surcharge de new et delete pour un pool de mémoire
-- spécialisation des collections STL et Boost pour utiliser des allocateurs spécifiques
- gestion du filesystem
- gestion des plug-ins.

Ayant ceci, j'attaquerais les sous-noyaus, dont:
- le renderer
- le gestionnaire de ressources
- le module de son
- moteur physique !
- gestionnaire des modules logiques
- moteur de script

Puis je passerais au moteur de logique proprement dit:
- gestion des évenements,
- logique du jeu proprement dite (et là, ca va forcément dépendre du jeu)
- pour un RPG: gestion de l'histoire
- pleins de trucs qui me viennent pas à l'esprit...

Voilà, ca représente pas mal de boulot, même en utilisant un framework graphique prêt à l'emploi. Bon courage.

[Mindiell]

- gestion du filesystem

Ca me parait très lié à la plateforme ca, non ?

[deadalnix]

C'est bien pour ça que ça vaut le coup de le mettre dans le moteur et ne pas se faire ch*** partout avec cette blague.

[Camel LowFilter]

les sous-noyaus, dont:
- le renderer
- le gestionnaire de ressources
- le module de son
- moteur physique
- gestionnaire des modules logiques
- moteur de script

Ca a été dit implicitement mais j'explicite que dans le cas des développements avec de faibles moyens (99% des cas sur ce forum) ... il faut absolument récupérer des librairies déjà faites ou des programmes déjà faits pour les sous-noyaux.

[deadalnix]

Sauf si le but est avant tout de se confronter au problème. C'est exactement ce que je cherchait (dans un but pédagogique) en me lanceant dans l'écriture d'un moteur physique.

Mais il faut être clair, ça n'est pas simple !

[Kromagg]

On pourrait aussi ajouter une console pour le noyau puisque c'est un aspect indépendant de la plateforme.

Je voulais aussi préciser un point sur la gestion des plug-ins : un plug-in n'est autre qu'une bibliothèque dynamique (dll, so...) donc cette gestion est faite en fonction de l'OS.
Admettons que je me contente de la plateforme Windows et Linux, est-ce que je peux gérer les plug-ins dans le noyau ? Si oui comme Ogre permet de gérer tout ça de manière portable est-ce que je peux réutiliser son système interne, ainsi que le système de log dans le noyau en utilisant simplement l'objet Ogre::Root ?

Naoss

[Mat.M]

Ok enfin pas de moteur graphique car je compte utiliser une lib externe (Ogre). Les collections je ne vois pourquoi en coder de nouvelles alors qu'elles existent déjà en C++. Le système de fichier on peut se baser sur boost::filesystem ?

Euh je n'arrive pas à comprendre la finalité de la chose.
Encore un énième personne qui désire faire un "moteur" de jeu...
bon passons.
Ensuite on dirait que tu souhaites faire comme une cuisine autour de Ogre qui est un moteur pas une bibilothèque ( quoique il faut que je vérifie mais c'est un moteur )
Quel est le but final de la manoeuvre ?
Qu'est-ce que cela va m'apporter concrétement?

[Kurisu]

Naoss: aucun problème à ce que tu reprennes mes idées. Si c'était pour les garder pour moi, je n'irais pas les poster ici...

Sinon, la "console d'entrée" n'est pas un élément essentiel et il vaudrait mieux la garder à part. D'une parce que c'est la console pourrait être lié au moteur de script, de deux, parce qu'elle pourrait changer d'un jeu à l'autre.

Pour commencer, je te conseillerais de reflechir aux différentes fonctions que chaque sous-noyau doit remplir (définir l'interface du sous-noyau). Et écrire le noyau central qui doit charger et utiliser les interfaces des sous-noyau.


Mat.M.: l'intérêt d'écrire son propre moteur, c'est de pouvoir regarder et apprendre la construction d'un tel outil. Même s'il existe des masses de moteurs comme Ogre, irrLicht, Sauerbraten etc., ceux-ci ont aussi leur limites, n'existant par exemple pas sur console (Wii, PSP, iPhone, XBox...). Bref, ca permet d'apprendre et de pouvoir réutiliser ses connaissances plus tard, ne serait-ce que pour adapter ou porter un moteur déjà existant.

Je sais que c'est un boulot monstre que d'écrire "son" propre moteur à soi, qui ne sera peut-être jamais utilisé par une personne tierce. Mais si on commence avec un raisonnement pareil, c'est perdu d'avance.

[epsilon68]

je dirais meme plus que ca aide à comprendre les choix des autres moteurs :-)

[edimok]

Salut à tous,

moi je suis nouveau dans la 3D et j'aimerais vraiment apprendre comment ca marche. Est-ce qu'il y a la possibilité que l'un d'entre vous m'intègre dans un développement d'un jeu en 3D, ce serait vraiment génial pour m'aider à me comprendre

merci bien

[deadalnix]

Et bien déjà, il faudrait poster dans la bonne section.

Tu pourra constater qu'il existe une partie du forum dédiée a la présentation des projets, et tu trouvera ton bonheur dedans si tu sais te vendre.

[Kromagg]

Dernière petite question
Je disais dans un post précédent que je voulais utiliser Ogre::Root et son système pour charger les plug-ins (mes sous-noyaux en l'occurence). Je souhaite donc intégrer Ogre::Root dans le noyau principal. Est-ce une bonne solution ou dois-je tout réécrire moi-même sachant qu'au final ce que je vais produire sera en gros identique au système d'Ogre ?

Sinon voyez-vous une autre solution pour gérer des plug-ins autre que sous la forme de bibliothèque dynamique ?

Naoss.

[shenron666]

Euh je n'arrive pas à comprendre la finalité de la chose.
Encore un énième personne qui désire faire un "moteur" de jeu...
bon passons.
Ensuite on dirait que tu souhaites faire comme une cuisine autour de Ogre qui est un moteur pas une bibilothèque ( quoique il faut que je vérifie mais c'est un moteur )
Quel est le but final de la manoeuvre ?
Qu'est-ce que cela va m'apporter concrétement?

tout comme il existe déjà des programmeurs hobbyistes, quel intérêt d'être soi même programmeur pour le plaisir ? quel intérêt de jouer à un jeu que tout le monde a déjà fini ? quel intérêt de réinventer la roue en réécrivant pour lé énième fois une bibliothèque pour gérer les chaines de caractères...
- plaisir
- apprentissage
- découverte
bref c'est pas parceque c'est déjà fait qu'il ne faut pas le refaire

concernant Ogre, c'est un moteur de rendu, et le rendu c'est pas ce qui fait un moteur complet, ce n'est qu'un sous système

perso je conseillerai de poser à plat, sous forme d'un diagramme, et d'une manière générale, l'environnement
en partant de ce diagramme, on en dessine un dans lequel chaque partie estimée trop complexe est détaillée en étant séparée en plusieurs sous parties
en faisant cela plusieurs fois on arrive au résultat souhaité