Banisardevidad a écrit:

Il faut arrêté maintenant, sinon ce que je trouve dommage c'est que NAZARA est en C++ , en C# je pense que j'aurais utilisé.

Quel dommage que C# ne soit pas le langage des moteurs de jeux !
(et puis bon, c'est pas le langage qui détermine si tu dois utiliser le moteur ou pas hein ?)

Banisardevidad a écrit:

je pense C# est mieux que java et C++ car il inègres les pointeurs un GC et des objets allouable sur la pile comme les vecteurs.

Ben en C++ y a des pointeurs, les objets peuvent être alloués dans la pile, et y a le RAII qui fait très bien le boulot du GC. 
Donc arguments bancals.

Banisardevidad a écrit:

Mais je trouve pas des moteurs ou au minimum une bonne intégration d'opengl ou vulkan comme dans LWJGL.

Banisardevidad a écrit:

Ben télécharge mon jeux sur mon site tu verra il y a aucun problème avec un moteur de jeux en java.

ça tourne a merveille a 60 FPS ....

sinon j'adore le coté fanatique de ce  forum c'est pour ça que je poste, c'est marrant ....

Toujours sans mesquinerie aucune, encore heureux que ça tourne à 60 FPS. Nazara est capable d'afficher ça à plusieurs milliers de FPS.

Le truc c'est quand tu commences à monter dans les techniques de rendu, à augmenter la complexité de la scène, là il est intéressant de voir si le moteur permet de conserver les 60 FPS.

(Parce que sinon on peut comparer avec le Dr. Freak que Nazara affiche à l'aide de Vulkan, ça tourne à 15 000 FPS ..)

Banisardevidad a écrit:

Après le pire que je trouve c'est qu'il n'y a pas de démos a télécharger pour voir ce que le moteur vaut.

Moi au moins il y a un démo ...

Comme précisé plus haut, les démos sont dans les nightlies, compilées automatiquement à chaque mise à jour du moteur, j'ai également plusieurs fois distribué des liens de téléchargement.

Banisardevidad a écrit:

Allez donne un lien pour une démo .....

 Ou même une videos ...

Edité par Banisardevidad il y a moins de 30s

Là c'est la preuve que tu n'as rien lu, pas même la page de présentation...

Je vais te le demander une dernière fois gentillement, tu peux arrêter de jouer au plus con s'il te plaît ? Merci !

-
Edité par Lynix 10 décembre 2016 à 14:42:57

Banisardevidad a écrit:

ça tourne a merveille a 60 FPS ....

 Tu as oublié de préciser "avec un Intel Core i7 et 3 sprites"

sinon j'adore le coté fanatique de ce  forum c'est pour ça que je poste, c'est marrant ....

 J'adore le côté stupide de ce forum.

Ah, et, on a trouvé ton frère trolleur !

Après le pire que je trouve c'est qu'il n'y a pas de démos a télécharger pour voir ce que le moteur vaut.

 Encore une preuve que tu sais pas chercher...

Moi au moins il y a un démo ...

 On s'en fout de toi.

Damn, grillé !

-
Edité par Random Coder 99 10 décembre 2016 à 14:47:12

Banisardevidad a écrit:

Quelqu'un connais un bon moteur de jeux en C# comme NAZARA ? je pense C# est mieux que java et C++ car il inègres les pointeurs un GC et des objets allouable sur la pile comme les vecteurs.

Mais je trouve pas des moteurs ou au minimum une bonne intégration d'opengl ou vulkan comme dans LWJGL.

Arrêtez de lui répondre, c'est un troll et comme les Gremelins il faut mieux éviter les nourrir (pour les trolls c'est toute la journée et pas juste après minuit :p).

Pan dans les dents, mdr

Banisardevidad a écrit:

Il y a pas la même chose qu'unity en opensource ??????

si, Nazara. mais sans l'UI

allez dehors le troll oops j'ai répondu

pour ma défense j'aimerai demander à lynix si le moteur est interfaçable (à la manière de la sfml qui est en c++ mais utilisable en python par ex) dans d'autres langages facilement, ca pourrait être intéressant à faire !

Yaalval a écrit:

pour ma défense j'aimerai demander à lynix si le moteur est interfaçable (à la manière de la sfml qui est en c++ mais utilisable en python par ex) dans d'autres langages facilement, ca pourrait être intéressant à faire !

C'est marrant comme il suffit d'y penser et pouf, quelqu'un en parle 
Plus sérieusement, j'ai justement décris la façon dont je pensais m'y prendre pour les binding sur le groupe ce matin, ou hier peut-être.

Alors, Nazara est partiellement interfacé en Lua jusqu'ici, un binding Python et un binding C m'ont également été assez réclamés.
Concernant le binding C, je voulais au début le générer en parsant les headers mais ça aurait certainement donné n'importe quoi, étant donné la taille de Nazara.

Alors j'ai pensé à une autre solution.

J'ai pensé à la création d'un outil, un petit exécutable utilisant Nazara, dont le rôle serait de générer les binding pour les langages désirés.

Comment s'y prendrait-il ? En utilisant des informations de classes données manuellement, ainsi que des méthodes (dont la signature serait extraite grâce aux templates) de façon générique (agnostique au langage) et en les passant à un module chargé d'écrire l'implémentation (et les headers dans le cas du C) du binding voulu.

La beauté de cette solution est qu'elle peut réutiliser le travail effectué jusqu'ici sur le binding Lua:

Avec un peu d'ajustement, on peut arriver à quelque chose de plus générique pouvant servir au générateur de code.

Un autre aspect positif de la solution est de pouvoir régler le temps et le coût en mémoire de compilation du SDK ainsi que son poids, en effet, le SDK utiliserait alors les fichiers binding générés et n'aurait plus besoin d'utiliser autant de templates imbriqués (derrière chaque BindMethod de l'image se voient instanciés parfois plusieurs dizaines de fonctions templates).

Je pense mettre en place cette idée pour la version 0.5 ou 0.6.

D'ailleurs en parlant de ça, la 0.3 arrive bientôt, elle apportera un frustum-culling très rapide et compatible avec l'ECS, ainsi qu'un début de GUI (Widgets pour l'interface), dont un widget d'entrée de texte (qui a été vraiment très chiant à mettre au point !) et un bouton cliquable.

Je voulais y intégrer la sérialisation de l'ECS avant de la sortir, avec notamment la possibilité de sauvegarder/restaurer un monde, mais ça risque de devoir attendre la version suivante car j'ai sous-estimé le travail.

À côté de ça, le nouveau Renderer (et Vulkan) progressent, lentement mais sûrement.

Voilà pour les nouvelles, à côté de ça je suis en vacance et je débute à mon nouveau travail début d'année, mais ça devrait ne pas avoir trop d'impact sur le développement. 

-
Edité par Lynix 11 décembre 2016 à 23:24:18

Lynix a écrit:

D'ailleurs en parlant de ça, la 0.3 arrive bientôt, elle apportera un frustum-culling très rapide et compatible avec l'ECS, ainsi qu'un début de GUI (Widgets pour l'interface), dont un widget d'entrée de texte (qui a été vraiment très chiant à mettre au point !) et un bouton cliquable.

Tu crées ton propre système de GUI ?

Lynix a écrit:

Alors j'ai pensé à une autre solution.

J'ai pensé à la création d'un outil, un petit exécutable utilisant Nazara, dont le rôle serait de générer les binding pour les langages désirés.

Comment s'y prendrait-il ? En utilisant des informations de classes données manuellement, ainsi que des méthodes (dont la signature serait extraite grâce aux templates) de façon générique (agnostique au langage) et en les passant à un module chargé d'écrire l'implémentation (et les headers dans le cas du C) du binding voulu.

La beauté de cette solution est qu'elle peut réutiliser le travail effectué jusqu'ici sur le binding Lua:

Ou la la, j'en ai la nozé rien que d'y penser

En tout cas, super boulot , bonne chance pour la suite .

-
Edité par Erwan28250 12 décembre 2016 à 0:44:16

Merci !

Erwan28250 a écrit:

Tu crées ton propre système de GUI ?

En effet, j'ai longtemps hésité à utiliser GWEN ou un autre système, mais ils auraient plus difficilement profités des optimisations de rendu du moteur, et ne se seraient pas bien intégrés avec l'ECS. 

Lynix a écrit:

Merci !

Erwan28250 a écrit:

Tu crées ton propre système de GUI ?

En effet, j'ai longtemps hésité à utiliser GWEN ou un autre système, mais ils auraient plus difficilement profités des optimisations de rendu du moteur, et ne se seraient pas bien intégrés avec l'ECS. 

edouard22 a écrit:

pour la gui, tu pense faire une architecture à la Qt ou quelque chose de différent ?

Pour l'instant ça ressemble à ça :

    Ndk::Canvas canvas(world.CreateHandle(), window.GetEventHandler());
    canvas.SetSize(Nz::Vector2f(window.GetSize()));


    Ndk::TextAreaWidget& textArea = canvas.Add<Ndk::TextAreaWidget>();
    textArea.SetSize({ 300.f, 150.f });
    textArea.Center();
    textArea.SetText("Héhé !");

C'est en effet similaire à ce que fait Qt, dans le sens où les widgets appartiennent à leurs parents.

Je pense transformer la référence en pointeur nu, car c'est assez contraignant en l'état pour le stockage.
Alors, pourquoi un pointeur nu ? Parce que la durée de vie des widgets est explicitement définie: le parent détruit ses enfants. De ce fait, l'utilisateur prend la responsabilité du pointeur qu'il utilise (et à vrai dire, ça serait exactement la même chose avec une référence).

À noter que le TextAreaWidget est celui dont je parlais plus haut, avec ce simple code vous aurez du texte apparaissant au milieu de votre écran, mais aussi la possibilité de l'éditer ! (Ça a l'air de rien comme ça, mais je vous jure que c'est chiant à faire ).

Eyefighter a écrit:

Question (par curiosité ) est ce que se serai compliqué d intégré là prise en charge de la vr dans nazara ?  ( je ne demande pas de le faire.)

Honnêtement je n'en suis pas sûr, pour moi le support de la VR par un moteur se résume à l'activation du rendu en stéréo (ce qui n'est pas le plus compliqué à obtenir) et à l'interaction entre le casque (et les éventuels contrôleurs) avec le moteur.

Je pense que le plus gros du boulot n'est pas vraiment à faire du niveau du rendu, mais au niveau architectural pour ce qui est de l'intégration des différents SDK du marché, mais je peux me tromper.

Donc, AFAIK, non ce n'est pas vraiment compliqué.

Apres un module de bruit mathematique une ame charitable se devoura elle pour proposer un module VR?

Vous le saurez au prochain episode

Eyefighter a écrit:

j'aimerais bien tenté, mais je sais que je n'ai pas le niveau (rien que pour compilé le moteur, sens lynix, j'en suis incapable)

Tu à essayé le tutoriel

-
Edité par Erwan28250 12 décembre 2016 à 18:48:31

oui, le lien de la vidéo pour code:block , c'est une vidéo qu'il avais fait pour moi (pas que, mais je suis sité)

j'ai re testé et sa fait toujours une erreur de compilation

..\..\..\include\Nazara\Core\ResourceSaver.inl|31|error: 'ExtensionGetter' was not declared in this scope|

Le moteur compile sur Appveyor pourtant

ExtensionGetter est ici

Donc fail de ta part je pense

oui, je pence que j'ai mal configurais code block.

Le problème ne vient pas directement de CodeBlocks mais du compilateur, lequel utilises-tu ? (Tu devrais utiliser ceux dont je donne le lien à chaque release), tu as d'autres erreurs que celle-là ? (Parce que ça paraît étrange).

En tout cas je peux t'affirmer que ça fonctionne très bien avec ces compilateurs et CodeBlocks 16.01, parce que je les ai utilisé pas plus tard que ce matin.

Aussi, pourquoi vouloir compiler le moteur quand je propose des précompilés ? :D 

Juste car il faut bien une petite réaction de temps en temps : gg pour le générateur pour le binding c'est avec ce genre de "petites" attentions qu'on se rend compte du niveau atteint

La sérialisation est aussi un point intéressant pour les applications en réseau outres les sauvegardes :) 

Au niveau de l'ui, beaucoup de jeux se basent sur une description xml des différentes interfaces, est-ce que tu as déjà un parseur dans Nazara (j'imagine que ça a déjà dû t'arriver d'en avoir besoin) ?  je pense aussi à la gestion des fichiers de config

-
Edité par Anonyme 12 décembre 2016 à 22:24:50

Rinrynque a écrit:

Juste car il faut bien une petite réaction de temps en temps : gg pour le générateur pour le binding c'est avec ce genre de "petites" attentions qu'on se rend compte du niveau atteint

Attendons d'abord de l'implémenter, jusqu'ici ce n'est qu'une idée 

Rinrynque a écrit:

Au niveau de l'ui, beaucoup de jeux se basent sur une description xml des différentes interfaces, est-ce que tu as déjà un parseur dans Nazara (j'imagine que ça a déjà dû t'arriver d'en avoir besoin) ?  je pense aussi à la gestion des fichiers de config

Non pour l'instant Nazara est incapable de parser du XML ou du JSON, simplement parce que je n'en ai jamais eu besoin.

Pour l'UI pour l'instant je pense partir sur du code façon Qt, je ne m'attends pas à ce que les UI soient vraiment très complexes à définir, surtout à ce stade.

Pour les fichiers de config, j'aime bien utiliser le Lua, grâce à la puissance du langage derrière, et puis il ne faut pas oublier que c'était à ça que servait le langage à la base 

Lynix a écrit:

Le problème ne vient pas directement de CodeBlocks mais du compilateur, lequel utilises-tu ? (Tu devrais utiliser ceux dont je donne le lien à chaque release), tu as d'autres erreurs que celle-là ? (Parce que ça paraît étrange).

En tout cas je peux t'affirmer que ça fonctionne très bien avec ces compilateurs et CodeBlocks 16.01, parce que je les ai utilisé pas plus tard que ce matin.

Aussi, pourquoi vouloir compiler le moteur quand je propose des précompilés ? :D 

se n'ais pas la seul erreur (je n'ais cité que la première)

des precompilés ? les fichier généré avec le batch , c'est ce que j'ai utilisé.

code block 16.01 ? avec le compilateur intégré par défaut (faut que je teste et surtout désinstale code block avent)

si non, j'ai trouvé sa pour la vr : https://github.com/ValveSoftware/openvr

-
Edité par Eyefighter 14 décembre 2016 à 12:41:48

SuperDadou666 a écrit:

C'est cool de réinventer la roue , je me souvienne pas que les développeurs de Ogre 3D (moteur que j'utilise ) et de Boost ( j'utilise aussi ) est fait un forum de cette manière ....

Réinventer la roue est essentiel dans ce genre de cas, pour pouvoir proposer mieux et ne pas se limiter aux contraintes imposées par les solutions existantes. 

SuperDadou666 a écrit:

C'est un peut n'importe quoi .... non ????

Non ça va, ça se passe bien (le fait que nous soyons sur la 52ème page le prouve).

SuperDadou666 a écrit:

Vous êtes combien a développer ce moteur ???

Nous sommes moi, et de temps en temps la communauté 

Eyefighter a écrit:

des precompilés ? les fichier généré avec le batch , c'est ce que j'ai utilisé.

Non je parle des fichiers compilés que je distribue à chaque release:

ou les nightlies (Visual Studio only):

Eyefighter a écrit:

code block 16.01 ? avec le compilateur intégré par défaut (faut que je teste et surtout désinstale code block avent)

Alors pour le compilateur TDM-GCC, je ne le supporte pas dans la version actuelle (parce qu'il ne marche pas pareil que ceux de MinGW-w64 qui me semblent bien mieux configurés), je te suggère de passer aux compilateurs dont je parle à chaque release.

Je pense rétablir le support de TDM-GCC dans le futur, quand je n'aurai plus besoin des options supportées uniquement (à ma connaissance) par MinGW-w64.

(Et en attendant pourquoi pas fournir une option de configuration pour ne pas définir les options dans ce cas, à voir.

Eyefighter a écrit:

si non, j'ai trouvé sa pour la vr : https://github.com/ValveSoftware/openvr

Intéressant, merci, même si je n'ai vraiment pas prévu la VR avant longtemps (déjà tant que je n'ai pas acheté de casque moi-même ça ne risque pas de me servir ).

Khronos travaillerait aussi sur un standard, à suivre.

-
Edité par Lynix 14 décembre 2016 à 20:09:39