Partage
  • Partager sur Facebook
  • Partager sur Twitter

[Moteur de jeu] Nazara Engine

Moteur de jeu en développement

    26 octobre 2016 à 16:49:16

    Oui, enfin Nazara permet quand même des rendus plus élaborés que le cubisme à la Minecraft ! C'est forcément un peu plus long à développer.

    • Partager sur Facebook
    • Partager sur Twitter
    Helium Rain, une space sim réaliste pour PC
      Staff 26 octobre 2016 à 16:54:46

      Moi, j'aimerais faire un jeu où le but est de tuer ton pc IRL, c'est possible avec Nazara ?
      • Partager sur Facebook
      • Partager sur Twitter

      FAQ 3D || 3DFR: discord francophone d'infographie 3D || Pas de demande d'aide par MP, le forum est là pour ça :)

        26 octobre 2016 à 17:04:25

        Ben ouais c'est le bute, simplifier la représentation 3D pour faire un moteur de jeux très simple pour se concentrer sur la logique de jeux Sinon autant utiliser l'unreal engine 4 et blender.

        Après je me suis concentrer sur autre chose, gérer les ombres , et permettre de créer des labyrinthes énorme et d'afficher le tous avec un FPS supérieur à 60 FPS.

        Tu utilses quoi comme structure pour déterminer les objets visibles , un octree ou un BSP ou autre ????

        Tu gère comment les textures atlas , avec des textures arrays ???

        Ce la permet de faire un prototype de jeux rapidement, après je suis d'accord on aime ou on aime pas les graphismes à base de cube, ça ce discute pas.

        -
        Edité par Banisardevidad 26 octobre 2016 à 17:04:57

        • Partager sur Facebook
        • Partager sur Twitter
          26 octobre 2016 à 17:12:07

          Ce n'est pas une question d'aimer ou pas. Développer un moteur de qualité comme Nazara ne laisse pas le temps de réaliser un jeu de qualité à côté, c'est tout. ^^
          • Partager sur Facebook
          • Partager sur Twitter
          Helium Rain, une space sim réaliste pour PC
            Staff 26 octobre 2016 à 17:13:38

            Pitié, ne lancez pas un énième débat minecraft et graphismes voxel. Pitié !  :lol:
            • Partager sur Facebook
            • Partager sur Twitter

            FAQ 3D || 3DFR: discord francophone d'infographie 3D || Pas de demande d'aide par MP, le forum est là pour ça :)

              26 octobre 2016 à 18:27:56

              Str4nger a écrit:

              Ce n'est pas une question d'aimer ou pas. Développer un moteur de qualité comme Nazara ne laisse pas le temps de réaliser un jeu de qualité à côté, c'est tout. ^^

              Lynix a écrit:

              @charlesfire: Ce n'est qu'un morceau du fond qui n'appartient pas au logo :)

              @edouard22:


              A priori si.. le but reste de developer utopia :p
              • Partager sur Facebook
              • Partager sur Twitter
                26 octobre 2016 à 18:35:34

                Il s'en passe des choses quand on part une petite après-midi :D 

                Str4nger a écrit:

                Oui, enfin Nazara permet quand même des rendus plus élaborés que le cubisme à la Minecraft ! C'est forcément un peu plus long à développer.

                Après il faut dire quelque chose, le plus gros du boulot autour de Nazara n'a pas été consacré au rendu mais bien aux capacités du moteur de jeu.

                Si on regarde l'évolution graphique, du moteur, on voit que ça n'a presque pas bougé ces trois dernières années, pour la simple raison que je me suis consacré à d'autres tâches que je considérai plus importantes, mais le moteur a toujours été flexible et permis à ses utilisateurs de rajouter ce qu'il manquait, par exemple l'utilisateur peut fournir ses propres techniques de rendus sans devoir recompiler le moteur, ou rajouter des post-process au Deferred Shading (et changer la composition du G-Buffer, etc.), pareil pour le système de particules qui est très flexible.

                Je trouve important de le préciser car récemment on a vu des moteurs de jeux comme Kit ou Instrinsinc, ces deux moteurs de jeux proposent un rendu plus avancé que celui de Nazara, des éditeurs, l'un propose même un rendu via Vulkan.

                Seulement voilà, il suffit de fouiller un peu le code pour se rendre compte que l'architecture de ces moteurs est atroce, Kit est tellement lié à OpenGL qu'il faudrait le réécrire pour rajouter le support d'un autre Renderer ou juste certaines fonctionnalités un peu plus poussées, et Instrinsinc utilise Vulkan de façon peu optimisée et avec un découpage tout aussi atroce (il suffit de voir que l'implémentation du rendu de la végétation et du reste se trouve dans le renderer Vulkan).

                Bref, si les moteurs de jeux étaient des châteaux de cartes, je dirais que mon objectif n'est pas de faire le château le plus haut, mais le plus solide, qui ne s'écroulera pas en claquant des doigts, et qui à terme sera l'un des plus beau château de cartes du paysage des châteaux de cartes du libre, même si ça doit me demander du temps et des tubes de colle :)

                Banisardevidad a écrit:

                Tu utilses quoi comme structure pour déterminer les objets visibles , un octree ou un BSP ou autre ????

                Pour l'instant, et depuis l'ECS, le culling n'est pas présent.

                J'ai développé sur une autre branche (culling) une solution à base de frustum-culling cache-friendly, par la suite je passerai à une représentation en octree, mais ce n'est pas pour tout de suite.

                Banisardevidad a écrit:

                Tu gère comment les textures atlas , avec des textures arrays ???

                Non, les texture arrays ne répondent pas à la problématique car la taille doit être la même à chaque face, ce qui n'est pas du tout ce que je veux, les texture atlas pour le texte ne sont que des textures régulières, découpées de façon logique par le moteur.

                Str4nger a écrit:

                Ce n'est pas une question d'aimer ou pas. Développer un moteur de qualité comme Nazara ne laisse pas le temps de réaliser un jeu de qualité à côté, c'est tout. ^^

                Je plussoie, même si ça dépend du degré de qualité, mais il est vrai que si je voulais développer un jeu comme disons Helium Rain avec Nazara, je devrais mettre le moteur en pause excepté pour les additions qui concernent directement le jeu.

                edouard22 a écrit:

                Str4nger a écrit:

                Ce n'est pas une question d'aimer ou pas. Développer un moteur de qualité comme Nazara ne laisse pas le temps de réaliser un jeu de qualité à côté, c'est tout. ^^

                Lynix a écrit:

                @charlesfire: Ce n'est qu'un morceau du fond qui n'appartient pas au logo :)

                @edouard22:


                A priori si.. le but reste de developer utopia :p

                Alors ça c'est juste une petite démo en préparation d'Utopia, mais rien à côté du boulot colossal d'Helium Rain par exemple :) 

                -
                Edité par Lynix 26 octobre 2016 à 18:48:10

                • Partager sur Facebook
                • Partager sur Twitter
                Nazara Engine | Discord NaN ! (Chat dédié à la programmation) | Ma chaîne Twitch (développement)
                  27 octobre 2016 à 11:30:48

                  Moi c'est une des chose que je me suis consacré le plus l'utilisation d'un octree et des query opengl , pour optimiser au maximum le rendu quand on est a l’intérieur de bâtiments ou de labyrinthe quelque soit la taille du monde, c'est indispensable pour faire un jeux.

                  Après les texture array tu peux en faire de taille différente après c'est vrais que les texture arrays c'est super adapté pour les jeux fais a base de cube car un pack de texture c'est un texture array.

                  Moi j'utilise un texture array couplé avec une texture 3D pour texturer chaque cube de façon différente.

                  Après moi je me suis aussi concentrer sur la génération procédural exemple https://www.youtube.com/watch?v=xmS9vMBWyM0

                  J'ai mis au point le concept de grammaire 3D pour décrire les éléments possible et leurs liens entre eux.

                  la modélisation est simple :

                  class Bloque {

                  String PX,MX,PY,MY,PZ,MZ

                  }

                  deux bloque peuvent être a coté suivant l'axe des X si Bloque1.PX== Bloque2.MX et ainsi de suite pour les autres Axe.

                  • Partager sur Facebook
                  • Partager sur Twitter
                    27 octobre 2016 à 17:28:20

                    Banisardevidad a écrit:

                        class Bloque {

                            String PX,MX,PY,MY,PZ,MZ

                        }

                    Bloque ._.

                    Sinon Lynix, est-ce que tu aurais de la lecture sur la conception d'Engine 3D? Ou est-ce que tu pourrais nous partager ton pokédex de liens intéressant plz?

                    Merci!

                    • Partager sur Facebook
                    • Partager sur Twitter
                    J'aime pas les gens
                      27 octobre 2016 à 18:03:52

                      @Banisardevidad: La différence c'est que je dois faire quelque chose de la façon la plus générique possible avec Nazara, afin que tout le monde retrouve son compte peu importe l'objectif final, mais je suis sûr que tes techniques sont très bonnes pour les voxels.

                      @Bl4ckb0ne: Non je n'ai pas vraiment de lecture à vous faire parvenir, je lis souvent des choses à gauche et à droite comme ça, pour ce qui est de l'architecture c'est surtout de l'essai/erreur et de la réflexion (il m'arrive de passer des semaines à réfléchir avant d'attaquer un nouveau design), pour les features de rendu ça va faire trop longtemps pour retrouver les liens, et il y en a certainement toute une chiée :) 

                      Donc il va falloir être plus précis je le crains !

                      • Partager sur Facebook
                      • Partager sur Twitter
                      Nazara Engine | Discord NaN ! (Chat dédié à la programmation) | Ma chaîne Twitch (développement)
                        27 octobre 2016 à 21:56:44 - Message modéré pour le motif suivant : Dérive du sujet


                          Staff 28 octobre 2016 à 16:24:24

                          Le sujet a pour but de présenter le projet, pas de faire un débat philosophique de la programmation d'un moteur de jeu pendant trois plombes. :-°

                          • Partager sur Facebook
                          • Partager sur Twitter

                          FAQ 3D || 3DFR: discord francophone d'infographie 3D || Pas de demande d'aide par MP, le forum est là pour ça :)

                            28 octobre 2016 à 19:02:35 - Message modéré pour le motif suivant : Message complètement hors sujet


                              Staff 28 octobre 2016 à 20:34:44

                              Banisardevidad

                              Tu parles sérieusement de censure ? Pour rappel :

                              La censure est la limitation arbitraire (cad libre choix sans logique ni accord avec la justice) ou doctrinale de la liberté d'expression de chacun.

                              Tu dérives du sujet, tu lances des débats dont personne ne veut et persistes à les continuer quand on te demande d'arrêter. Si tu veux étaler ta culture, lances des messages privés, ouvres un blog, comme tu veux. Mais pas ici.

                              Ce n'est pas un choix arbitraire de ma part, c'est une simple conséquence de ta dérive en hors sujet. Si tu dis avoir l'habitude des forums, tu devrais comprendre, sinon les forums ne sont pas faits pour toi et ça ne concerne que toi.

                              Sur ce, je modère ton énième hors sujet et supprime les réactions engendrées. Bonne continuation.

                              -
                              Edité par -L0Lock- 28 octobre 2016 à 20:36:49

                              • Partager sur Facebook
                              • Partager sur Twitter

                              FAQ 3D || 3DFR: discord francophone d'infographie 3D || Pas de demande d'aide par MP, le forum est là pour ça :)

                                28 octobre 2016 à 23:42:26

                                Alors ma question je vais faire différent , mon ton moteur tu va faire comment le culling ??????

                                • Partager sur Facebook
                                • Partager sur Twitter
                                  28 octobre 2016 à 23:56:27

                                  Banisardevidad a écrit:

                                  Alors ma question je vais faire différent , mon ton moteur tu va faire comment le culling ??????

                                  Lynix a écrit:

                                  Banisardevidad a écrit:

                                  Tu utilses quoi comme structure pour déterminer les objets visibles , un octree ou un BSP ou autre ????

                                  Pour l'instant, et depuis l'ECS, le culling n'est pas présent.

                                  J'ai développé sur une autre branche (culling) une solution à base de frustum-culling cache-friendly, par la suite je passerai à une représentation en octree, mais ce n'est pas pour tout de suite.

                                  Pour compléter un peu, je pense mettre en place après ça de l'occlusion culling software: les occluders seraient affichés (de façon extrêmement simplifiés) dans un depth buffer software, et les objets ayant passé le frustum culling seront ensuite testés par rapport à ce depth-buffer.

                                  Voici un lien sorti de mon pokédex qui explique tout ça:

                                  https://software.intel.com/sites/default/files/why-render-hidden-objects-6.pdf

                                  • Partager sur Facebook
                                  • Partager sur Twitter
                                  Nazara Engine | Discord NaN ! (Chat dédié à la programmation) | Ma chaîne Twitch (développement)
                                    29 octobre 2016 à 9:27:56

                                    Très très bien merci , merci pour la réponse c'est ce que je cherchais a avoir discutions.

                                    Merci.

                                    C'était un peu l'idée de mon algorithme que j'avais présenté dans le poste qui a été supprimé.

                                     Sinon j'ai un autre question , j’espère que mon poste sera pas supprimé...

                                    tu connais des techniques pour afficher différemment un décor vu de très loin   , genre faire un rendu dans une texture ou autre , tu a un truc dans ton pokédex ?? ???

                                    Moi je trouve ce qui est intéressant dans ton projet c'est pas de faire un enième moteur 3D (il existe orgre3D irrlicht et autre ) mais de faire un truc modulable , comme par exemple rendre le culling entièrement modulable a sa sauce.

                                    Il y a trop de moteur qui sont monolithique, donc bon courage sur cette voie la ....

                                    -
                                    Edité par Banisardevidad 30 octobre 2016 à 10:19:29

                                    • Partager sur Facebook
                                    • Partager sur Twitter
                                      4 novembre 2016 à 12:23:31

                                      Banisardevidad a écrit:

                                      tu connais des techniques pour afficher différemment un décor vu de très loin   , genre faire un rendu dans une texture ou autre , tu a un truc dans ton pokédex ?? ???

                                      Pour un modèle, il y a bien la technique des impostors, qui consiste à rendre le modèle du point de vue de la caméra dans une texture et puis d'afficher un sprite avec le résultat jusqu'à ce que le point de vue (l'angle entre la caméra et l'entité) change d'un certain facteur.

                                      Pour un décor entier, là y'a pas photo, il faut soit le simplifier (le LOD est ton ami) soit utiliser une technique similaire aux impostors: rendre le décor lointain et uniquement lui dans un cubemap qu'on affichera comme une skybox, je ne sais pas trop ce que ça peut donner, surtout en automatique mais ça peut être intéressant.

                                      Banisardevidad a écrit:

                                      Moi je trouve ce qui est intéressant dans ton projet c'est pas de faire un enième moteur 3D (il existe orgre3D irrlicht et autre ) mais de faire un truc modulable , comme par exemple rendre le culling entièrement modulable a sa sauce.

                                      Il y a trop de moteur qui sont monolithique, donc bon courage sur cette voie la ....

                                      À vrai dire, contrairement à Unity/UDK/Cry Engine, Ogre3D et Irrlicht sont des moteurs que je souhaiterai voir Nazara dépasser, les mauvaises langues diront que ça n'est pas difficile mais pourtant je n'y suis pas encore :) 

                                      Mais oui, j'apporte pas mal d'importance à la modularité, il suffit de voir que mon premier moteur (l'ancêtre de Nazara) était entièrement basé sur un système de plugins qu'on pouvait changer à chaud.

                                      Il faudrait que je fasse une liste de tout ce qu'il est possible de modifier à chaud dans Nazara, ça pourrait être intéressant :) 

                                      • Partager sur Facebook
                                      • Partager sur Twitter
                                      Nazara Engine | Discord NaN ! (Chat dédié à la programmation) | Ma chaîne Twitch (développement)
                                      Anonyme
                                        5 novembre 2016 à 0:23:16

                                        Salut 

                                        Si j'ai compris après avoir vite fait regarder le github et les commentaire de OC tu utiliser OpenGL pour le rendu

                                        • Partager sur Facebook
                                        • Partager sur Twitter
                                          5 novembre 2016 à 0:38:11

                                          TheYoungGeek43 a écrit:

                                          Si j'ai compris après avoir vite fait regarder le github et les commentaire de OC tu utiliser OpenGL pour le rendu

                                          En effet, le renderer actuel est basé sur OpenGL 3.3.

                                          Je suis en train de développer un nouveau Renderer multi-API sur une branche séparée (même si des changements vers cet objectif ont déjà été appliqués à master), proposant à terme Vulkan, OpenGL 2 et OpenGL 3.

                                          J'ai été assez réticent à remettre le support d'OpenGL 2, mais visiblement il existe encore des personnes avec un ordinateur incapable de faire tourner OpenGL 3.3 et j'ai quand même envie de pouvoir dire que Nazara tourne à peu près partout.

                                          Le point qui m'a le plus embêté avec OpenGL 2 c'était les shaders, mais étant donné que Vulkan veut de toute façon du SPIR-V et OpenGL du GLSL, je dois bien faire en sorte que les shaders puissent être compilés/traduits en différents langages.

                                          • Partager sur Facebook
                                          • Partager sur Twitter
                                          Nazara Engine | Discord NaN ! (Chat dédié à la programmation) | Ma chaîne Twitch (développement)
                                            7 novembre 2016 à 18:57:57

                                            Y a-t-il des fonctionnalités d'OpenGL 4.x ?
                                            • Partager sur Facebook
                                            • Partager sur Twitter
                                              7 novembre 2016 à 20:55:43

                                              ImperatorS79 a écrit:

                                              Y a-t-il des fonctionnalités d'OpenGL 4.x ?


                                              Oui, OpenGL 3.3 est la version minimale actuelle mais le moteur cherche quelques extensions et features d'OpenGL 4 qui pourraient lui servir. 

                                              Quant au contexte OpenGL , par défaut il est à la version maximale supportée par l'ordinateur. 

                                              • Partager sur Facebook
                                              • Partager sur Twitter
                                              Nazara Engine | Discord NaN ! (Chat dédié à la programmation) | Ma chaîne Twitch (développement)
                                                11 novembre 2016 à 13:58:56

                                                A propos de Vulkan, je te prie de ne pas faire n'importe quoi avec les barrières ! Genre faire une "memory barrier from the bottom to the top" qui n'a juste aucun sens !

                                                Pour le reste c'est du très bon boulot !

                                                • Partager sur Facebook
                                                • Partager sur Twitter
                                                http://cpp-rendering.io : Vous trouverez tout ce dont vous avez besoin sur Vulkan / OpenGL et le rendu 3D !
                                                  13 novembre 2016 à 22:07:05

                                                  Qnope a écrit:

                                                  A propos de Vulkan, je te prie de ne pas faire n'importe quoi avec les barrières ! Genre faire une "memory barrier from the bottom to the top" qui n'a juste aucun sens !

                                                  De quoi parles-tu ? Du code de Nazara ? (Si oui, de quel endroit ?) et aussi, depuis quand étudies-tu Vulkan ? :)

                                                  • Partager sur Facebook
                                                  • Partager sur Twitter
                                                  Nazara Engine | Discord NaN ! (Chat dédié à la programmation) | Ma chaîne Twitch (développement)
                                                    13 novembre 2016 à 23:02:05

                                                    Ah non j'ai pas regardé le code de Nazara ^^.

                                                    Mais c'est juste que quand on regarde les codes sources, article sur internet (GPU Open), Sascha Willems, Vulkan tutorial, sur les barrières de mémoires ils écrivent n'importe quoi à certains moments. Du coup je voulais t'éviter que tu écrives ce genre de choses en ne sachant pas vraiment ce qu'il se passe ;).

                                                    Je m'explique : GPU Open n'écrit pas n'importe quoi mais le suggère (enfin je trouve), je cite ce qui est écrit pour une barrière BOTTOM TO TOP :

                                                    This transition expresses that every command currently in flight on the GPU needs to finish, then the transition is executed, and no command may start before it finishes transitioning. This barrier will wait for everything to finish and block any work from starting. That’s generally not ideal because it introduces an unnecessary pipeline bubble. 

                                                    Ce qui est écrit est clairement vrai, mais tu peux (enfin j'ai compris au début) comprendre que les accés mémoires en écriture effectué de la première commande sont rendu disponible lorsque toute la première commande atteint le BOTTOM, et qu'ils sont visible lorsque la seconde commande en est au TOP. Ce qui est actuellement faux étant donné que BOTTOM / TOP. La seule façon de faire une barrière bloquante sur tous les stages est de faire ALL_COMMANDS to ALL_COMMANDS (ce qui est relativement lent je te l'accorde ;) ). Mais ils n'auraient jamais créés TOP/BOTTOM si ils pouvaient remplacer ALL_COMMANDS ;).
                                                    D'après ce que j'ai pu lire sur github, le fait que les spécifications ne sont pas claires à certains moments, voir fausses (mais corrigées depuis) y est surement pour quelques choses.

                                                    Pour Sascha Willems, il transitionne ses images avec une barrière mémoire TOP to TOP. Ce n'est pas "correct" dans pas mal de cas (même si c'est sûrement "suffisant" dans les cas qu'il utilise), mais vu le nombre d'exemples qu'il a fait, on peut admettre que du lazy programming / ainsi que les spécifications fausses à l'époque n'ont pas du aider à gérer tous les types de barrières mémoires de manières correctes. 

                                                    Pour Vulkan tutorial, j'ai ouvert des issues sur github pour expliquer en quoi il avait tort.

                                                    Il y a aussi les "faux warnings" des validations layers qui peuvent induire en erreur. Genre le validation layer te dit d'utiliser HOST_WRITE lorsque une image est PREINITIALIZED, ce qui est TOTALEMENT FAUX (car elle a déjà été faite) et qui est un bug des validation layers ! (j'espère que ma PR sera acceptée x)). Il y a aussi que lorsque tu utilises une ressource en lecture dans la première commande, ils te disent que tu dois utiliser en srcAccessMask le READ_BIT associée, ce qui n'a pas de sens, car tu n'as pas besoin de flush un cache lorsque tu fais une lecture. (Ça ils sont en discussion pour savoir si ils doivent ou non le supprimé).

                                                    Depuis quand j'étudie Vulkan, alors j'ai commencé le jour de sa sortie, puis fais une grosse pause (même si je me renseignais / lisait les forums etc). Je dirais que ça fait 2 mois que je bosse sur Vulkan à plein temps ou presque...

                                                    Néanmoins, voilà quelques liens qui peuvent être utiles:

                                                    Memory Barriers on TOP_OF_PIPE

                                                    Host_write when PREINITIALIZED

                                                    Vulkan Tutorial issues

                                                    Ma façon de voir les choses sur les barrières  (si y a des fautes ou des questions, n'hésites pas à me le dire, mais j'ai pas eu de retour négatif)

                                                     Tout ça pour dire, que même les spécifications ne sont pas forcément claires ^^.

                                                    BTW, j'admire ton travail et j'espère avoir un jour ton niveau sur le rendu 3D un jour :).

                                                    -
                                                    Edité par Qnope 13 novembre 2016 à 23:04:32

                                                    • Partager sur Facebook
                                                    • Partager sur Twitter
                                                    http://cpp-rendering.io : Vous trouverez tout ce dont vous avez besoin sur Vulkan / OpenGL et le rendu 3D !
                                                      14 novembre 2016 à 17:02:08

                                                      @QNope:

                                                      C'est très instructif, je garde tes liens au chaud !

                                                      Et merci :)

                                                      Désolé du manque de nouvelles dernièrement, j’ai pas mal voyagé (d’ailleurs, bonjour à Ardakaniz, rencontré aux Utopiales de Nantes :D ).

                                                      Aujourd’hui sort enfin la nouvelle version de Nazara, la version 0.2.

                                                      Elle corrige tous les bugs connus (à l’exception du RUdp qui se verra corrigé d’ici deux ou trois versions, à cause de sa complexité), et ajoute quelques changements intéressants !

                                                      Quelques points marquants:

                                                      • Le module Physics a été renommé en Physics3D
                                                      • Le module Physics2D a fait son apparition (Nazara peut maintenant gérer de la physique bi-dimensionnelle rudimentaire).
                                                      • La configuration NAZARA_UTILITY_THREADED_WINDOW a été remplacée par le style WindowStyle_Threaded (permettant de faire tourner sélectivement des fenêtres dans un thread séparé).
                                                      • Material, Matrix4, Sprite, Texture, etc. sont maintenant accessibles depuis le binding Lua.
                                                      • Correction de la compilation d’un shader interne sur les chipset Intel.

                                                      Un lien vers le changelog (beaucoup plus complet) et les liens de téléchargement:

                                                      Nazara Engine - Release 0.2

                                                      J’ai aussi mis en place plusieurs issues sur Github permettant de discuter de certaines fonctionnalités à venir, et voir quand je prévois leurs arrivées.
                                                      J’ai aussi mis en place un tableau de bord plus complet sur les fonctionnalités à venir, afin de partager ma vision sur l’évolution du moteur.

                                                      Comme toujours, vous pouvez venir retrouver la toute dernière actualité/poser vos questions sur le moteur sur le canal dédié à Nazara sur Mattermost ou bien ici même.

                                                      :)

                                                      • Partager sur Facebook
                                                      • Partager sur Twitter
                                                      Nazara Engine | Discord NaN ! (Chat dédié à la programmation) | Ma chaîne Twitch (développement)
                                                        15 novembre 2016 à 13:43:03

                                                        J'ai une question aussi qui j’espère ne sera pas viré par le modérateur ...

                                                        Pourquoi pas avoir fait le moteur en C# ou en Java ?

                                                        • Partager sur Facebook
                                                        • Partager sur Twitter
                                                          15 novembre 2016 à 13:59:06

                                                          Ca serait pas une bonne idée, Microsoft a annoncé qu'ils arrêtaient le C# l’année prochaine. Et Oracle a annoncé que le Java serait encore maintenu quelques années, mais que ca ne serait que du bug fix, il n'y aura plus d'évolutions majeures du langage.

                                                          EDIT : ceci est un troll, ce n'est absolument pas vrai, il est inutile de m'envoyer un MP pour demander confirmation...

                                                          -
                                                          Edité par gbdivers 15 novembre 2016 à 15:33:39

                                                          • Partager sur Facebook
                                                          • Partager sur Twitter
                                                          Pour poser des questions ou simplement discuter informatique, vous pouvez rejoindre le discord NaN.
                                                            15 novembre 2016 à 14:01:02

                                                            Banisardevidad a écrit:

                                                            Pourquoi pas avoir fait le moteur en C# ou en Java ?

                                                            Ok, alors même si je vais immanquablement lancer un débat, je t'invite à ne pas répondre ici, on peut argumenter par MP ou sur un autre topic du forum, mais pas ici.

                                                            Donc, pourquoi pas Java ou C# ? Pour plusieurs raisons (et je vais même ajouter que ce sont mes opinions personnelles):

                                                            • Ces langages, même s'ils sont plus performants qu'avant, n'arrivent pas à la cheville du C++ quand il s'agit de performances. J'ai déjà passé des heures à grapiller quelques microsecondes (1e-6, véridique) sur l'emploi de fonctions souvent appelées par le moteur, des langages comme le Java ou le C# ne peuvent pas subir la même optimisation, et ont un environnement plus lourd.
                                                            • Je suis totalement contre l'idée d'un Garbage Collector Stop-The-World dans ce genre de contexte, comment faire attention à des microsecondes si l'environnement peut arrêter tous les threads pendant plusieurs millisecondes à n'importe quel moment ?
                                                            • (Java) Je pense également que la compilation AOT est largement supérieure en terme de bénéfices à l'heure actuelle que le JIT (je sais qu'on peut compiler Java en AOT, mais ce n'est pas la tendance).
                                                            • (Java) Devoir dépendre d'une JVM est selon moi contraire à ce qu'un moteur devrait être.
                                                            • Le RRID (ou RAII ou RFID) est selon moi l'une des meilleures façons de gérer la mémoire, un garbage collector (selon l'implémentation courante) bouffe énormément de mémoire.
                                                            • Ces deux langages dépendent de sociétés, je préfère un langage libre comme le C++.
                                                            • J'aime le C++, de part sa nature multi-paradigme.
                                                            • J'aime les pointeurs.
                                                            • Minecraft.

                                                            Voilà, c'est tout pour mes opinions totalement personnelles.

                                                            -
                                                            Edité par Lynix 15 novembre 2016 à 14:02:06

                                                            • Partager sur Facebook
                                                            • Partager sur Twitter
                                                            Nazara Engine | Discord NaN ! (Chat dédié à la programmation) | Ma chaîne Twitch (développement)
                                                              15 novembre 2016 à 14:31:20

                                                              Merci beaucoup , la réponse me convient et je pense que je vais refaire mon moteur aussi en C++.

                                                              • Partager sur Facebook
                                                              • Partager sur Twitter

                                                              [Moteur de jeu] Nazara Engine

                                                              × Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
                                                              • Editeur
                                                              • Markdown