Discussion :

[dragonjoker59]

L'erreur est explicite, tu as un fichier trop gros pour passer sur GitHub, il faut donc que tu arrives à le réduire.
Mais comme on dirait qu'il s'agit de Qt, je serais toi je ne le mettrais tout simplement pas.

[Invité]

Mdr qu'est ce que des fichiers de qt viennent faire dans ce dossier.

Je ne les avais même pas mis dedans, bref, je les ai retirer.

Ici ça devrait passer.

PS : mdr je les ai supprimé du dossier et j'ai refais un commit, il les a bien retiré mais git refuse toujours de push en me disant qu'ils sont toujours là.

[yildiz-online]

fais un git status pour voir si ils sont toujours référencés, si oui, fais un git rm

[Invité]

Oui il y en a un qui est toujours référencé, j'ai tenté de faire un git rm mais, il me dit que le fichier n'existe pas. On dirait que git il foire.

[dragonjoker59]

Si tu l'as retiré à la main, il faut d'abord revert ce change, pour ensuite le supprimer via git rm

[Invité]

Bonjour, oui je les ai supprimé à la main, je vais demander comment on fait ça.

[Invité]

J'ai essayé de faire un git revert commit et ça ne fonctionne pas.

[Invité]

J'arrête ce projet, projet trop démesuré pour une seule personne.

[guitz]

Pourquoi tessaies pas de recruter ?

[Invité]

Je ne trouve personne d'intéressé par le projet. J'ai juste fais le système de combat et d'xp du jeux en plus le dépôt git ne fonctionne plus à cause d'un virus (un fichier qt super volumineux que j'ai eu du mal à supprimé d'ailleurs il ne voulait pas partir de la corbeille) et j'ai des bugs c++. (variables mal initialisées, j'en ai une que j'initialise à false et elle vaut true dans le programme et j'ai le même problème avec les évènements)

Je vais encore devoir tout réinstaller. Mais je ne vais pas le faire tout de suite.

PS : il faudrait que je change [projet en cours] en [recrutement] mais je ne sais pas comment on fait.

[Invité]

Non c'est bon je sais pourquoi ça plante.

[dragonjoker59]

Gné ?

[guitz]

Bon alors ce projet, tu l'arrêtes ou tu le continues ?

[Gregouar]

Hey Laurent, ça fait un baille.
Je n'ai pas trop suivi où ton projet en est pour le moment, mais si t'es toujours intéressé pour en apprendre plus sur OpenGL je te conseille de jeter un oeil ici : https://learnopengl.com/
Prends le temps de lire les choses et tu en apprendras beaucoup sur comment réaliser des techniques d'éclairage moderne. Du plus, si jamais t'es intéressé à travailler avec la SFML (ce qui facilite quand-même beaucoup de choses et je sais que tu le faisais, en tout cas avant), on peut s'échanger quelques tips sur comment implémenter tout ça vu que j'ai un peu expérimenté dessus ces derniers temps (par exemple utiliser le zBuffer pour ordonner tes tiles en 2.5D sans devoir ce soucier de l'ordre d'affichage; et ce avec "presque aucun" appel à "OpenGL lui-même" ).

[dragonjoker59]

Mouais, vu le code de la SFML pour le rendu, je ne la conseillerais pas dans le développement d'un moteur de jeu... Ils en sont encore aux Vertex Arrays, si je ne me trompe (id est. envoi des données de sommets au GPU à chaque frame, même si aucun changement n'est intervenu entre 2 frames...). Ca a l'avantage d'être portable sur à peu près toutes les versions d'OpenGL, mais c'est totalement contre performant...

Par contre, tant qu'à faire de la pub, je développe une lib de rendu qui permet de définir et d'écrire son rendu à la manière de Vulkan, sans se soucier de savoir si c'est OpenGL ou Vulkan qui est utilisé derrière. (J'ai un post, dans la section Vulkan, si ça vous intéresse). Ca utilise pour l'instant OpenGL >= 4.2, mais divers renderers OpenGL sont prévus (3.x, ES 3.1, et peut-être ES 3.0)

[Gregouar]

Mouais, vu le code de la SFML pour le rendu, je ne la conseillerais pas dans le développement d'un moteur de jeu... Ils en sont encore aux Vertex Arrays, si je ne me trompe (id est. envoi des données de sommets au GPU à chaque frame, même si aucun changement n'est intervenu entre 2 frames...). Ca a l'avantage d'être portable sur à peu près toutes les versions d'OpenGL, mais c'est totalement contre performant...

Il semble que la doc n'est pas tellement à jour, mais tu as sf::VertexBuffer qui fait ça si je ne dis point de bêtise.

Par contre, tant qu'à faire de la pub, je développe une lib de rendu qui permet de définir et d'écrire son rendu à la manière de Vulkan, sans se soucier de savoir si c'est OpenGL ou Vulkan qui est utilisé derrière. (J'ai un post, dans la section Vulkan, si ça vous intéresse). Ca utilise pour l'instant OpenGL >= 4.2, mais divers renderers OpenGL sont prévus (3.x, ES 3.1, et peut-être ES 3.0)

Ça peut être intéressant

[dragonjoker59]

sf::VertexBuffer n'existe pas dans la 2.4.2, mais uniquement dans le dépôt Git (c'est déjà ça tu me diras).
Ensuite on peut aussi parler de l'utilisation du pipeline fixe (ces cochonneries de glMatrixMode, glMultMatrix et autres trucs sortis du musée des horreurs...), de l'absence de batching et autres joyeuseries qui font que pour un moteur de jeu avancé, ce n'est pas un framework adapté (désolé pour ceux qui l'utilisent en pensant que c'est bien).

[Invité]

Salut Grégoire, mon moteur de jeux gère l'éclairage de manière avancé (avec les normales), les ombres (shadow mapping) et le rendu sans tenir compte de l'ordre des tiles. (order independant transparancy)

En ce qui concerne les techniques de rendu plus moderne que les vertexarray et le batching j'ai déjà essayé mais ça n’optimisait pas beaucoup.
Je ne sais pas comment tu as fais avec le zBuffer mais je veux une technique qui marche aussi en 3D car je veux que ce moteur de jeux soit universel, j'utilise aussi le zBuffer mais dans un shader.

J'ai testé avec une dizaines de tiles semi-transparentes affichée dans n'importe quel ordre en z et ça marche la couleur au centre reste la même. Par contre si je change l'ordre d'affichage des tiles là la couleur du centre change mais ça n'est pas grave étant donné que mon moteur affiche toujours les tiles dans le même ordre en x et en y.
Mais je dois dessiner mes tiles une par une car je dois rappeler le shader à chaque dessin pour remettre à jour le zBuffer.

Actuellement j'en suis au système de combat je viens de le terminé mais il y a encore quelques bugs restant.

En gros il me reste à gérer :

Le système de quêtes.
Les items et l'inventaire.
Les compétences.
Avec bien sûr les interfaces graphiques qui vont avec.

Et toi tu en es ou avec HolySpirit ?

Le code de ton jeux m'intéresse (mais je ne l'ai plus) il va me falloir de l'inspiration pour la suite de mon propre jeux.
En ce moment je n'ai plus trop la motivation (car je suis tout seul) ni le temps de coder, je me dis je n'arriverai jamais à faire un jeux de ce genre en plus j'ai des bugs mais par moment la motivation revient donc je continue en ne pensant plus à ces bugs mais en continuant comme si le jeux fonctionnait normalement et je me dis que je réglerais ces bugs plus tard.

Mais j'ai des bugs de fenêtrage avec la SFML, genre je rend la fenêtre invisible elle réapparaît.
Et j'ai aussi un bug avec l'animation des personnages qui attaque qui ne se joue pas bien donc on ne voit pas que les personnages attaquent hors que en fait si. Pourtant pour les animations du personnage qui marche je n'ai pas de problèmes, je ne fais rien d'autre que de les afficher frame par frame, bref je ne comprend pas.

Ha oui et j'ai aussi un autre bug avec SFML, j'initialise un évènement (bouton gauche de la souris) pour testé le clic sur un bouton. Et au cours de l'exécution la variable à changé de contenu tout seul comme ça.
J'ai le même problème avec une variable que j'initialise à false et que au cours de l'exécution vaut true sans que je ne la modifie du coup mon personnage bouge tout seul.

Bref j'ai quelques bugs avec c++ et SFML.

[Gregouar]

mon moteur de jeux gère l'éclairage de manière avancé (avec les normales), les ombres (shadow mapping) et le rendu sans tenir compte de l'ordre des tiles. (order independant transparancy)

En ce qui concerne les techniques de rendu plus moderne que les vertexarray et le batching j'ai déjà essayé mais ça n’optimisait pas beaucoup.

Je parlais plutôt d'introduire des méthodes PBR (Physically based rendering). Pour l'optimisation, c'est une autre histoire...

Je ne sais pas comment tu as fais avec le zBuffer mais je veux une technique qui marche aussi en 3D car je veux que ce moteur de jeux soit universel, j'utilise aussi le zBuffer mais dans un shader.

Ca dépend de comment tu veux mixer ta 2D et ta 3D.

J'ai testé avec une dizaines de tiles semi-transparentes affichée dans n'importe quel ordre en z et ça marche la couleur au centre reste la même. Par contre si je change l'ordre d'affichage des tiles là la couleur du centre change mais ça n'est pas grave étant donné que mon moteur affiche toujours les tiles dans le même ordre en x et en y.
Mais je dois dessiner mes tiles une par une car je dois rappeler le shader à chaque dessin pour remettre à jour le zBuffer.

Ca ne m'a pas l'air très performant.

Et toi tu en es ou avec HolySpirit ?

Le code de ton jeux m'intéresse (mais je ne l'ai plus) il va me falloir de l'inspiration pour la suite de mon propre jeux.

Je ne travaille plus sur HS depuis des années. Ceci dit, les sources sont toujours ici : https://sourceforge.net/p/lecheminde...ode/HEAD/tree/
Mais elles ne sont clairement pas un exemple à suivre, j'étais encore trop au stade expérimentale et j'ai commis de nombreuses erreurs de design.

[Invité]

Je parlais plutôt d'introduire des méthodes PBR (Physically based rendering).

Ha non je n'ai pas implémenté cela. Par contre on peut transformer les ombres grâce à la matrice de projection des ombres et ajouté une texture à
chaque entité pour faire du bumpmapping.

Ca ne m'a pas l'air très performant.

Non ça ne l'est pas mais je n'ai pas trouvé de méthode plus performante pour le faire à part avec openGL 4.2 peut être avec imageLoad et imageStore pour faire du batching mais ma carte graphique ne supporte pas opengl 4.2 j'ai donc du choisir une méthode supportée par les PC plus anciens.

J'aimerais bien savoir comment tu fais avec le zBuffer car ça à l'air plus performant. Moi c'est juste la formule de blending que je change si la tile est devant ou derrière la tile la plus proche.

Je ne travaille plus sur HS depuis des années. Ceci dit, les sources sont toujours ici : https://sourceforge.net/p/lecheminde...ode/HEAD/tree/
Mais elles ne sont clairement pas un exemple à suivre, j'étais encore trop au stade expérimentale et j'ai commis de nombreuses erreurs de design.

ODFAEG impose d'utiliser un design bien précis de type entités-composants. J'utilise aussi RAII pour les ressources externes. Tout est calculé dans les composants de rendu ou dans le gestionnaire d'entités ainsi l'utilisateur n'a même plus besoin de créer ses propres type de shader et si il veut le faire il doit créer un nouveau type de composants de rendu ou bien un nouveau type de gestionnaire d'entités. Je préfère travailler avec des codes qui ont un bon design en effet. Ce que je n'ai pas encore gérer se sont les reflets, et les shaders pour l'eau. (les vagues)
Mais ceci est trop compliqué pour que je gère cela moi même je ne suis pas aussi doué que toi en mathématiques.