Non mais sincèrement pourquoi devoir utiliser un shader pour dessiner des guis (des rectangles, du texte, des cercles, des formes convexes, etc...), autant passer les matrices à opengl et utiliser les vertex array d'opengl comme le fait la SFML. (et oui je me sert encore des anciennes fonctionnalité pour dessiner certains chose là ou la performance n'est pas vraiment nécessaire)
Je ne me sert de l'opengl moderne seulement pour dessiner des graphismes qui sont gourmands en performances.
Et comme ODFAEG est écrit par dessus la SFML, et que les fenêtres SFML créent un contexte opengl et ne supportent pas vulkan, ça m'impliquera de devoir changer toutes les classes du modules graphique de SFML, du module fenêtre de ODFAEG (ne plus utiliser SFML mais une librairie qui permet de ne pas créer de contexte opengl et d'utiliser vulkan comme la SDL ou glfw) et de ODFAEG pour afficher tout.
Et si tu n'avais pas la tête dans le guidon depuis 10 ans, tu te serais peut-être aperçu que le monde change et que depuis le départ ton architecture aurait dû être assez souple pour passer d'une librairie graphique à une autre sans avoir à tout casser.
C'est peut-être le moment pour rectifier c'est erreur majeure de conception, non ?
Les moteurs que tu décries ont tous largement gérer ces problématiques, malgré ces casse-couilles de mangeurs de pommes.
Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
Mon architecture est bonne mais je ne la changerai pas et en fait je n'ai pas besoin la changer même si j'utilisais vulkan les méthodes et les classes resteraient les mêmes c'est le code source en interne qui changerait et comme j'ai fait une interface pour créer des fenêtres, je n'ai qu'à hérité de cette interface pour implémenter une fenêtre SDL (ou autre) adaptée à vulkan.
Je vois pas ce que vous avez contre mon architecture, je la trouve bonne.
Vulkan ne nécessite pas de faire de changement de code pour fonctionner sur d'autres plateformes apparemment.
>même si j'utilisais vulkan les méthodes et les classes resteraient les mêmes
Alors tout est bien, y a plus qu'à.
>Je vois pas ce que vous avez contre mon architecture, je la trouve bonne.
Vos réticences à faire un portage Vulkan m'a fait entrevoir le pire.
Mais si l'on en revient au sujet initial, c'est quand même pas folichon, une architecture à plug-ins qui verrouille les compilateurs et les options de compilation pour la génération du plug-ins aux mêmes strictement que ceux pour la génération de l'exécutable.
En plus l'utilisateur de l'éditeur, qui est majoritairement un game designer donc un non-programmeur, lui collé du C++ velu directement dans les pattes, c'est quand même bourrin. Un langage de script est bien plus permissif, voir du "Visual Scripting" à la Blue Print de Unreal Engine.
Quel est l'intérêt de votre moteur s'il est dépassé, surclassé par le premier moteur de jeu venu ? Qui eux, ont évolués pour ne pas rester scotché à un OpenGL d'il y a 30 ans.
Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
>même si j'utilisais vulkan les méthodes et les classes resteraient les mêmes
Alors tout est bien, y a plus qu'à.
>Je vois pas ce que vous avez contre mon architecture, je la trouve bonne.
Vos réticences à faire un portage Vulkan m'a fait entrevoir le pire.
Mais si l'on en revient au sujet initial, c'est quand même pas folichon, une architecture à plug-ins qui verrouille les compilateurs et les options de compilation pour la génération du plug-ins aux mêmes strictement que ceux pour la génération de l'exécutable.
En plus l'utilisateur de l'éditeur, qui est majoritairement un game designer donc un non-programmeur, lui collé du C++ velu directement dans les pattes, c'est quand même bourrin. Un langage de script est bien plus permissif, voir du "Visual Scripting" à la Blue Print de Unreal Engine.
Quel est l'intérêt de votre moteur s'il est dépassé, surclassé par le premier moteur de jeu venu ? Qui eux, ont évolués pour ne pas rester scotché à un OpenGL d'il y a 30 ans.
Non, l'utilisateur de l'éditeur ne devra pas connaître le c++, il n'aura qu'à, si il veut créer un objet, entrer les valeurs pour ses objets, même chose si il veut le modifier, ODFAEGCreator génère le code c++ automatiquement, le compile, l'exécute et sauvegarde tout les objets dans des fichiers que le programmeur c++ pourra réutiliser dans le jeux, le programmeur c++ pourra mettre des fichiers c++ dans le dossier du projet de ODFAEGCreator pour que le game designer puisse créer par exemple les pnjs, les quêtes, etc..., c'est ça qui fera la force de ODFAEGCreator et je ne compte pas faire d'éditeur de scripts avec ODFAEGCreator comme dans unity même si j'ai commencé à en faire un bref parce que je ne vois pas l'intérêt d'une interface graphique à part pour créer des objets, pour le reste, il faut de toute façon coder et compiler alors je préfère utiliser mon EDI préféré pour le faire.
Je n'ai pas envie de perdre un an pour passer de opengl à vulkan mon but c'est pas d'avoir un moteur de jeux moderne que beaucoup de monde utilise comme unity et unreal engine, mon but c'est d'utiliser le moteur pour créer un jeux et tirer plaisir du travail que j'ai effectué pendant 10 ans pour créer le moteur et l'éditeur, d'ailleurs, je n'ai pas besoin non plus d'implémenter la 3D dans l'éditeur pour le moment vu que le jeux sera en 2.5D.
PS : et comme j'aime bien réutiliser du code je pense attendre que SFML (ou une autre lib) implémente vulkan comme ça, je ne devrai pas tout réinventer.
Je pense faire une interface pour les classes du module graphique (shader, texture, rednertexture) avec l'implémentation opengl et une implémentation vulkan) mais ça sera bien plus tard quand le premier jeux créer avec odfaeg sera terminé et qu'il y aura plus de tutoriels sur vulkan.
EDIT : Le seul truc que je n'ai pas encore fait c'est de vérifier si les valeurs entrées sont valides c'est à dire qu'elles correspondent bien aux types c++, mais bon ça, pas compliqué à savoir même pour un non programmeur, si c'est un std::string il la met entre "", si c'est une valeur il la rentre directement, si c'est un objet il tape le nom de l'objet ou bien il appelle le constructeur de l'objet et lui passe les valeurs, et pour les classes et les fonctions, il n'aura qu'à les choisir, si je dois lui expliquer en 5 minutes c'est fait.
EDIT2 : je sais comment je vais faire pour vulkan, créer une interface et une factory avec un #ifdef pour compiler soit le code vulkan ou opengl, comme j'ai fait pour le module window si je veux utiliser SFML ou pas parce que sous linux j'utilisais pas SFML à cause d'un bug j'ai créer mon propre module fenêtre pour opengl, par contre sur windows j'utilise SFML. Pratique le préprocesseur.
Bref ça me permet de changer de lib en rajoutant juste une option de compilation.
Non, l'utilisateur de l'éditeur ne devra pas connaître le c++, il n'aura qu'à, si il veut créer un objet, entrer les valeurs pour ses objets, même chose si il veut le modifier, ODFAEGCreator génère le code c++ automatiquement, le compile, l'exécute et sauvegarde tout les objets dans des fichiers que le programmeur c++ pourra réutiliser dans le jeux, le programmeur c++ pourra mettre des fichiers c++ dans le dossier du projet de ODFAEGCreator pour que le game designer puisse créer par exemple les pnjs, les quêtes, etc..., c'est ça qui fera la force de ODFAEGCreator et je ne compte pas faire d'éditeur de scripts avec ODFAEGCreator comme dans unity même si j'ai commencé à en faire un bref parce que je ne vois pas l'intérêt d'une interface graphique à part pour créer des objets, pour le reste, il faut de toute façon coder et compiler alors je préfère utiliser mon EDI préféré pour le faire.
Sauf que, a priori, ce n'est pas toi qui va utiliser ton programme, mais "quelqu'un d'autre". Du moins, on peut espérer que quelqu'un d'autre l'utilisera, car, autrement, l'intérêt du programme est pour le moins limité
Et, du coup, tu m'excuseras la grossièreté, mais, en gros, tes préférences personnelles en tant qu'EDI, on s'en bat gentiment la queue !
OmbreNoire a écrit:
Je n'ai pas envie de perdre un an pour passer de opengl
Non, au lieu de cela, tu as préféré perdre dix ans à t'enfoncer de plus en plus dans un projet qui ne tient que par habitude et par miracle tant il présente des problèmes de conception
Je ne suis pas sur que tu aies vraiment gagné au change, sur ce coup là
OmbreNoire a écrit:
Je pense faire une interface pour les classes du module graphique (shader, texture, rednertexture) avec l'implémentation opengl et une implémentation vulkan) mais ça sera bien plus tard quand le premier jeux créer avec odfaeg sera terminé et qu'il y aura plus de tutoriels sur vulkan.
Ben, là, il semblerait déjà y avoir un sérieux problème, car, a priori, l'interface de tes classes, ce devrait être la première chose à laquelle il faut penser, pour qu'il n'y ait plus que l'implémentation à modifier en fonction des technologies utilisées
Ce qui se conçoit bien s'énonce clairement. Et les mots pour le dire viennent aisément.Mon nouveau livre : Coder efficacement - Bonnes pratiques et erreurs à éviter (en C++)Avant de faire ce que tu ne pourras défaire, penses à tout ce que tu ne pourras plus faire une fois que tu l'auras fait
Non mais sincèrement pourquoi devoir utiliser un shader pour dessiner des guis (des rectangles, du texte, des cercles, des formes convexes, etc...), autant passer les matrices à opengl et utiliser les vertex array d'opengl comme le fait la SFML. (et oui je me sert encore des anciennes fonctionnalité pour dessiner certains chose là ou la performance n'est pas vraiment nécessaire)
Si tu savais tout ce qu'on peut faire avec des shaders…
Salut! C'est bon j'ai une idée sur comment implémenter ça pour vulkan, reste plus qu'à avoir la motivation pour implémenter ça.
Mais ça va être plus difficile d'encapsuler cette api, car, pour les shaders, faut créer des UBO, pour les textures des sampler, et de plus, sur le tutoriel que j'ai trouvé il n'explique pas comment utiliser plusieurs textures/shader, il n'y a plus de fonction glBind évidemment bref c'est totalement différent!
Bah oui, par contre je vais devoir utiliser des ifdef plutôt que des interfaces, le code varie de trop entre opengl et vulkan, les fonctions ne sont pas les mêmes.
Pour coder une interface si je ne me trompe pas il faut implémenter les même fonctions pour toutes les implémentations de cette interface et le problème c'est qu'opengl utilise glBind (SFML possède une fonction statique bind pour les textures et les shader) tandis qu'avec Vulkan il faut récupérer un objet et le passer à une structure c'est complètement différent.
Par contre j'ai vu dans le tutoriel sur vulkan que lors du redimensionnement de la fenêtre il faut tout recréer, la swapchain, le pipeline, etc... et même les uniform buffer objects, je trouve pas ça très pratique, et il faut recréer tout le pipeline quand on change de shader. Opengl se chargeait de créer les objets pour nous, et on pouvait choisir lequel on voulait utiliser avec glBind ce que je me demande c'est avec les FBO si il faut recréer tout (y compris l'instance vulkan) ou bien si certaines données doivent être partagées. (si oui il faut créer une sorte de "shared context" comme pour opengl)
Pas un contexte par FBO mais si il faut que je partage des objets vulkan au moins passer un objet au FBO, je sais pas moins comment ça fonctionne les FBO avec vulkan je n'ai jamais fait pour ça que je demande...
Et si j'utilise plusieurs fenêtres, il faut, plusieurs swapchain sûrement, mais peut être une seule instance de vulkan bref..., il me faudrait trouver un tutoriel plus complet.
> il faut tout recréer, la swapchain, le pipeline, etc... et même les uniform buffer objects,
T'as mal lu. Il faut recréer les objets qui dépendent de la surface, rien d'autre.
> il faut recréer tout le pipeline quand on change de shader.
Immutable pipelines, ça s'appelle, et c'est un soulagement, comme ça t'as pas à jouer avec la machine à états d'OpenGL qui est une autre partie de l'enfer
Un tuto Vulkan: https://vulkan-tutorial.com/
- Edité par dragonjoker 20 janvier 2021 à 16:56:35
Si vous ne trouvez plus rien, cherchez autre chose.
Oui c'est le tutoriel que j'ai lu, il s'arrête au multisampling, il ne parle pas du rendu hors écran, je pense que tu trolls ce n'est pas possible autrement déjà juste à lire ton pseudo. Je ne sais pas ou tu as été cherché ce fameux site web avec toutes les classes que tu avais mit sur développez.com et la soi disant documentation mais ça n'a vraiment aucun sens, et comme tu vois que je répond à chaque fois ça marche plutôt bien, bref, je vais plutôt, t'ignorer.
Normalement il faut un setup vulkan que tu passes au FBO mais comment fait tu si certaines données doivent être partagées et d'autres pas il faut créer plusieurs setup avec un setup pour les données partagées que tu passes à tout les autres setup.
C'est pour ça que je crée plusieurs contextes par FBO avec opengl, si je ne le fais pas, les données qui ne doivent pas être partagées sont partagées du coup il n'affiche plus rien!
Bref tu fais genre de t'y connaître et que t'a créer un moteur mais, tu ne comprends même pas la moitié de ce que je raconte et tes conseils n'ont aucun sens, à mon avis, tu trolls, et personnellement je ne pense pas que tu as fait un moteur toi même tu n'as pas l'air de te rendre compte de ce que ça implique comme travail.
> Oui c'est le tutoriel que j'ai lu, il s'arrête au multisampling, il ne parle pas du rendu hors écran
Et ça c'est quoi ? https://vulkan-tutorial.com/Drawing_a_triangle/Drawing/Framebuffers
> Je ne sais pas ou tu as été cherché ce fameux site web avec toutes les classes que tu avais mit sur
J'aimerais bien que tu me montres de quel site tu parles.
> Normalement il faut un setup vulkan que tu passes au FBO mais comment fait tu si certaines données doivent être partagées et d'autres pas il faut créer plusieurs setup avec un setup pour les données partagées que tu passes à tout les autres setup.
Il n'y a PAS de notion de partage de données d'un FBO à l'autre, que ce soit en OpenGL comme en Vulkan ni même en D3D9/10/11. Arrête tes cauchemars, c'est plus simple que ça...
> C'est pour ça que je crée plusieurs contextes par FBO avec opengl, si je ne le fais pas, les données qui ne doivent pas être partagées sont partagées du coup il n'affiche plus rien!
Aucun rapport avec une notion de partage, si rien ne s'affiche c'est parce que toi ou la SFML faites de la merde.
> Bref tu fais genre de t'y connaître et que t'a créer un moteur mais, tu ne comprends même pas la moitié de ce que je raconte et tes conseils n'ont aucun sens, à mon avis, tu trolls, et personnellement je ne pense pas que tu as fait un moteur toi même tu n'as pas l'air de te rendre compte de ce que ça implique comme travail.
Si je participe à la discussion, c'est parce que ton projet est intéressant, et que je souhaite t'aider (après, je m'y prends peut-être mal) et c'est vraiment rageant de te voir partir dans des directions complètement loufoques (installer le compilo en même temps qu'ODFAEG ? Tu y penses vraiment sérieusement ? Oo) et ignorer complètement les conseils qui peuvent t'être donnés, en pensant que tu fais mieux que ce qui existe.
- Edité par dragonjoker 20 janvier 2021 à 17:25:08
Si vous ne trouvez plus rien, cherchez autre chose.
Je n'ai plus le lien du site mais tu avais parlé de documentation mais quand j'ai cliqué sur le lien je n'en ai pas trouvé.
Et c'est quoi tout ces dossiers et toutes ces classes et cette structure ?
Moi j'utilise une architecture avec des composants (renderer) avec un renderer pour les lumières, un pour les ombres, etc..., une scène avec des scene nodes rendu avec les renderer, et des systèmes qui remettent à jour les animations, les particules, etc... et l'application qui contient tout, toi, je ne vois aucune architecture, c'est quoi l'architecture de ton moteur ?
Tu critiques sans cesse ce que moi et l'auteur de la SFML font, mais ce que tu fais, c'est pire encore, la SFML il y a une architecture et elle est simple comme il le dit, mon moteur il y a une architecture et je le trouve simple à utiliser.
Et puis de toute façon, comme je vais utiliser vulkan, le problème de contextes multiples sera résolu, parce que avec vulkan il n'y a plus de contexte.
Tu dis que tu trouves mon projet intéressant alors que depuis le début tu dis que je ne sais pas coder, et après tu dis que tu veux m'aider en me donnant des conseils, il y a un problème là.
Personnellement il faut un compilateur c# pour pouvoir compiler les scripts de Unity alors pourquoi je ne devrai pas installer un compilo en même temps que ODFAEGCreator ?
Bref j'ai suivis tes conseils, d'utiliser vulkan et je vais perdre un an, ça te convient comme ça ?
Bref plutôt que de me faire perdre du temps tu n'aurais pas des choses à faire pour Castor3D ? Ou bien alors tu as déjà fini ?
Tu dis que tu trouves mon projet intéressant alors que depuis le début tu dis que je ne sais pas coder, et après tu dis que tu veux m'aider en me donnant des conseils, il y a un problème là.
Il ne faut pas non plus confondre le projet et celui qui le code!!!!
Un projet peut être codé d'une manière admirable tout en présentant un intérêt complètement nul, tout comme un projet peut être particulièrement intéressant tout en donnant l'impression d'avoir été codé avec les pieds par un singe bigleux tant il y a d'erreur de conception.
S'il est vrai que la critique est facile alors que seul l'art est difficile, il faut bien comprendre qu'il ne s'agit pas de connaitre -- même parfaitement -- le langage que l'on utilise pour s'assurer de faire quelque chose qui tienne la route et qui soit utilisable au final, car l'écriture du code est normalement la toute dernière étape du développement d'un projet digne de ce nom:
L'idée de projet a beau être excellente, si tu prend de mauvaises décisions conceptuelles au départ, tu vas te retrouver à devoir prendre des décisions conceptuelles de plus en plus mauvaises afin de contourner les problèmes occasionnés par tes premières décisions, et ton projet sera de plus en plus bancal. C'est ce que l'on appelle la dette technique.
Toi, ca fait des années que tu nous as présenté ton projet sur d'autres forums, et que l'on te dis que ta conception de base est foireuse et que tu es parti sur des bases exécrables et tu n'as pourtant pas varié d'un iota depuis tout ce temps.
Puis tu t'étonnes de ne recevoir aucune réponse à tes questions, alors que cette conception que tu trouves merveilleuse nous met dans une situation dans laquelle il nous est impossible de comprendre la moitié du quart de ce qui est fait sans passer dix ans à étudier l'intégralité du projet, alors que l'on te cite très rapidement une foule incroyable de problèmes qui devront être résolus avant de commencer à pouvoir avancer alors que tu balaies ces objections d'un revers de la main en disant que ce n'est pas comme cela que tu as prévu que ton moteur fonctionnerait?
Ce qui se conçoit bien s'énonce clairement. Et les mots pour le dire viennent aisément.Mon nouveau livre : Coder efficacement - Bonnes pratiques et erreurs à éviter (en C++)Avant de faire ce que tu ne pourras défaire, penses à tout ce que tu ne pourras plus faire une fois que tu l'auras fait
Je n'ai jamais changé l'architecture du moteur tout simplement parce que pour moi elle est plus simple à comprendre que celles de moteurs existants que j'ai eu l'occasion d'utiliser et qui n'utilisent pas le système application/monde/scenenodes/scene/composants et systèmes.
Pour quelqu'un qui n'a pas conçu le moteur il est impossible pour moi de savoir si le moteur est simple à utiliser car on à tous une conception différente de ce qu'est un moteur et son architecture c'est pour cela que il existe de nombreux moteurs différents et que chaque grande société de développement de jeux vidéos possède son propre moteur.
Si l'architecture de mon moteur ne vous plait pas, je ne vous ai jamais obligé à l'utiliser! Je l'utilise parce que moi, j'en ai besoin.
EDIT : et puis la conception architecturale d'un moteur c'est de l'art et c'est compliqué.
Je n'ai jamais changé l'architecture du moteur tout simplement parce que pour moi elle est plus simple à comprendre que celles de moteurs existants
Tout tient dans ces deux mots: pour TOI!!!
Or, un projet qui ne peut être réellement compris que par son développeur, cela n'a pas vraiment énormément d'intérêt, car, le but, c'est quand même qu'il puisse servir au développeur, mais aussi qu'il puisse servir à "quelqu'un d'autre, surtout s'il est sur un repository git public, non?
En outre, comme tu ne prend pas la peine de nous expliquer en quoi ton architecture est tellement meilleure, et encore moins ce que tu reproche à celle des moteurs de jeux actuels, il nous est relativement malaisé de trouver des arguments permettant de te faire changer d'avis.
Tu présentes donc un argument d'autorité qui ne nous laisse pas d'autre choix que te répondre "c'est ton avis".
Et quand tu nous dit, je cite
OmbreNoire a écrit:
Et 10 ans auparavant pas de unity et ue, il y avait déjà des moteurs mais sans interface graphique.
Ben, oui, justement, en dix ans les voitures ont dans l'ensemble réussi à économiser deux litres et demie au cent km et le diesel est devenu aussi cher que l'essence.
En dix ans, le nombre de coeurs des processeurs a au minimum doublé
En dix ans, nous sommes passés de windows 7/8 à windows 10
En dix ans, enfin, nous sommes passé de OpenGL 3.x à OpenGL 4.x et à Vulkan, et unity unereal engine sont devenus particulièrement intéresant
Ne crois tu pas qu'il serait au moins intéressant de voir un peu ce que font, quitte à les rejeter malgré tout en masse, au moins pour avoir une idée de ce qu'il font et de la manière dont ils le font?
Note que cela a au moins l'avantage de nous obliger également, quitte à ne pas partager ton opinion, à le respecter, vu qu'il est clair que tu ne souhaites pas changer d'avis.
D'ailleurs, à bien y réfléchir, une architecture de moteur de jeux basée sur des plugins pourrait, effectivement, présenter de très nombreux intérêts... A condition toutefois d'avoir été correctement conçue et que la structure générale du projet soit absolument sans tache.
Or, c'est justement là que le bât blesse: on ne peut clairement pas dire que la conception de ton architecture, aussi "fantastique" puisse-t-elle être en théorie est absolument sans tache.
Car, quand tu fais ressortir le fait qu'un de tes plugins dépend de core, et que core dépend justement de ce plugin, il devient tout de suite évident qu'il y a -- à tout le moins -- déjà un problème de "gestion" des niveaux d'abstraction:
Tu devrais, dans l'idéal, avoir au moins quatre niveaux d'abstractions différents (et potentiellement plusieurs plugins par niveau):
le niveau "0" qui reprend les parties réellement communes qui risquent, effectivement, de se retrouver de manière plus ou moins transversale à peu près partout (comme les notions d'événements, de plugins, d'entrées (clavier / souris) ou de propriétés de la fenêtres)
le niveau "1" qui serait une façade permettant "cacher" à l'utilisateur tout ce qui est spécifique au système (windows Vs linux Vs IOS Vs bfd, etc) (OpenGL Vs Vulkan, GLFW Vs SFML, GLAD Vs GLEW, etc) ou à la techno spécifique qui seront utilisé(e)s
le niveau "2" qui correspond, en gros, au modèle, au données strictement métier
le niveau "3" qui correspond à tout ce qui permet de fournir "à quelque chose ou à quelqu'un d'autre" des informations sur les données utilisées (la "vue"), que ce soit au travers d'une IHM, pour l'émission de sons ou pour la sauvegarde et la récupération ou pour la transmission d'informations
Et, enfin, tu devrais sans doute avoir, intégré à la façade du niveau "1", un niveau "0.5" qui fournit l'implémentation spécifique (au systèmes et / ou au bibliothèques externes utilisées) des fonctionnalités exposées par ta façade.
(Ce niveau "0.5" est différents des autres (ce qui justifie que je ne l'aie pas indiqué directement dans la liste) dans le sens où c'est un niveau strictement interne et "privé", dont l'utilisateur devrait même carrément aller jusqu'à ignorer l'existence.)
Pire encore, ta conception frise par moments le "grand n'importe quoi" (à vrai dire, elle fait bien plus que "le friser" :P)
OmbreNoire a écrit:
Pour quelqu'un qui n'a pas conçu le moteur il est impossible pour moi de savoir si le moteur est simple à utiliser
On ne sait peut être pas déterminer s'il est simple à utiliser, mais on sait très facilement se faire sur les facilités qu'il offre en termes d'évolution et de maintenance.
Or, sur ces deux points, on ne peut pas vraiment dire que ton projet soit exemplaire
OmbreNoire a écrit:
car on à tous une conception différente de ce qu'est un moteur et son architecture
Ca, je peux te l'accorder sans problème. Tu remarqueras cependant que l'architecture des moteurs de jeux qui tiennent vraiment la route est généralement très semblable
OmbreNoire a écrit:
c'est pour cela que il existe de nombreux moteurs différents et que chaque grande société de développement de jeux vidéos possède son propre moteur.
Eett non... S'il existe tant de moteurs de jeux différents et si les grandes sociétés ont investi dans le développement de leur propre moteur, c'est d'abord et avant tout une question de licence et de gros sous: il revient beaucoup moins cher, à terme, de développer son propre moteur que de devoir payer une licence et/ou des royalties au concurrent parce que l'on utilise son logiciel (sans compter que l'on préférerait, à choisir, éviter d'aller financer son concurrent )
OmbreNoire a écrit:
Si l'architecture de mon moteur ne vous plait pas, je ne vous ai jamais obligé à l'utiliser!
Non, tu fais encore bien pire en nous demandant à nous d'essayer de résoudre des problèmes qui ne sont que les conséquences logiques de mauvaises décisions rendues inéluctables par des décisions encore plus anciennes et le tout sans même penser un seul instant que nous puissions avoir d'excellentes raisons pour t'inciter à remettre ces anciennes décisions en question.
Seulement, quand on demande de l'aide à quelqu'un, il faut être près à accepter son aide et donc, au minimum, à écouter les conseils qu'il pourrait nous donner, tu ne crois pas ?
OmbreNoire a écrit:
et puis la conception architecturale d'un moteur c'est de l'art et c'est compliqué.
Oui, bien sur, la conception d'un moteur de jeux est une tâche particulièrement complexe tant il y a d'éléments à faire rentrer en ligne de compte.
Seulement, il ne faut pas confondre complexe, imposant parce qu'il y a 175 éléments différents à prévoir et compliqué, pour lequel il devient impossible de savoir par quel bout il faut prendre les éléments.
Nous sommes tout à fait d'accord pour t'aider à gérer la complexité du problème, et même à t'éviter de ne rendre le problème plus complexe que nécessaire.
Mais tant que tu n'auras pas compris qu'il faut impérativement virer les choses qui rendent le problème inutilement compliqué, on ne pourra pas faire grand chose pour toi. Et je doute très fort que qui que ce soit n'en soit capable
Ce qui se conçoit bien s'énonce clairement. Et les mots pour le dire viennent aisément.Mon nouveau livre : Coder efficacement - Bonnes pratiques et erreurs à éviter (en C++)Avant de faire ce que tu ne pourras défaire, penses à tout ce que tu ne pourras plus faire une fois que tu l'auras fait
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
git is great because Linus did it, mercurial is better because he didn't.
Si vous ne trouvez plus rien, cherchez autre chose.
Si vous ne trouvez plus rien, cherchez autre chose.
Si vous ne trouvez plus rien, cherchez autre chose.
Si vous ne trouvez plus rien, cherchez autre chose.
Si vous ne trouvez plus rien, cherchez autre chose.