Discussion :

[Cirrus Minor]

... c'est juste que le héro avance moins vite. (Mais pour ça il suffise que je change la vitesse. :..).

Pourquoi ne pas plutôt tenir compte du temps écoulé entre deux updates, histoire de ne pas avoir des mouvements liés au framerate ?

[Invité]

Salut, je me base sur le temps écoulé entre 2 update...

Code cpp :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
sf::Int64 t = getClock("LoopTime").getElapsedTime().asMicroseconds() * caracter->getSpeed();

A chaque tour de boucle je "restart" la clock.

C'est donc indépendant du framerate.

Ou alors c'est la mesure du temps qui n'est plus bonne quand il y a plusieurs thread car il est vrai que normalement ça ne devrait pas dépendre du framerate. (Mais ça, je ne peux rien faire car dans ce cas le problème ne vient pas de mon code)

PS : il faudrait peut être que j'essaye avec std::chrono plutôt que avec sf::Clock vu que j'utilise la librairie standart pour les threads et pas SFML.

[Invité]

J'ai remanié mon devblog :

-J'ai retiré le code source.(en effet il n'étais pas nécessaire de le mettre, celui-ci est déjà sur mon devblog)
-J'ai terminé la partie sur le module core, les pages suivante parleront plutôt du module physique et de comment je gère les collisions avec ODFAEG.

J'ai réussi à ajouter et à afficher des cubes avec le gestionnaires d'entité de ODFAEG, donc les dernières fonctionnalités du moteur (génération de terrain, chargement de modèles en 3D, etc...) ne devraient plus tarder à voir le jour.

[Invité]

Salut, il ne me reste plus que quelques optimisations à faire car lorsque il y a trop de poly, ça rame...

Je suis donc preneur pour chaque nouvelle idée d'optimisation du moteur...

Si quelqu'un est partant pour implémenter un support pour l'opengl moderne ça serait bien, je n'ai malheureusement pas de driver fonctionnel pour tester cela. :/

Cela n'empêche pas que j'ai déjà écrit un peu de code pour l'opengl moderne.

[Invité]

Après avoir fait quelque tests je me rend compte que ce qui bouffe tout se sont les shaders car lorsque je les désactives, mon FPS double!

Donc je pense que plus tard, je vais essayer de trouver une aternative aux shaders, mais en attendant ça me simplifie bien des choses surtout pour les textures semi-transparente, là ou le depthtest classique d'opengl ne marche pas. :/

[Bousk]

Plutôt qu'espérer trouver une "alternative aux shaders" (laquelle d'ailleurs ? tu vas développer ta propre carte graphique ?), j'opterais surtout pour une mauvaise utilisation.
Et vu que tu as déjà avoué dans un autre sujet (ou celui-ci?) être accroc aux locks, ton faible fps ne me surprend pas du tout..

[maeiky]

Même sans shader, le depthtest classique d'opengl sur les textures semi-transparente ne marche pas. Il faut quand même les afficher en ordres. Le shader n'a rien à voir la dedans

Et puis les cartes graphiques de nos jours simule les vielles fonctions d'openGL avec des shaders, sans parler de toutes les possibilités que ça offre. Il y a plein de façon d'arriver au même résultat certain plus efficace que d'autre, comme les bindless textures par exemple, qui sont très performantes. Ton ordinosaure n'est sans doute pas la meilleur référence

[Invité]

Deux nouvelles pages de crééent, dont celles-ci : (Ou je présente l'architecture globale du module graphique du framework)

http://lolilolightdevblog.wordpress....ique-partie-1/

Plutôt qu'espérer trouver une "alternative aux shaders" (laquelle d'ailleurs ? tu vas développer ta propre carte graphique ?), j'opterais surtout pour une mauvaise utilisation.
Et vu que tu as déjà avoué dans un autre sujet (ou celui-ci?) être accroc aux locks, ton faible fps ne me surprend pas du tout..

Je n'utilise plus les locks vu que je n'utilise plus de threads, en fin j'ai deux implémentation une avec thread et une sans thread mais ça ne change pas les performances, les bindless texture je ne peux pas les utiliser, car ma plateforme ne supporte que openg3.0, hors il me semble que les bindless textures ne sont disponible que à partir de la version 4 d'opengl.

Et oui tout ce qui est gratuit à ses limites, je devrai peut être coder mon propre driver.
Mais bon ne venez pas dire que je ne sais pas utiliser les shaders, j'aurai sûrement opté pour une méthode plus performante sinon.

Même sans shader, le depthtest classique d'opengl sur les textures semi-transparente ne marche pas. Il faut quand même les afficher en ordres. Le shader n'a rien à voir la dedans

Non, pas obligé de les afficher dans l'ordre, dans mon moteur je n'affiche pas les entités dans l'ordre, je fais juste un depthtest perso dans le fragment shader. D'ailleurs, je suis bien obligé pour générer la heightmap et la normal map pour l'éclairage par pixel et l'ombrage.

[maeiky]

Non, pas obligé de les afficher dans l'ordre, dans mon moteur je n'affiche pas les entités dans l'ordre, je fais juste un depthtest perso dans le fragment shader. D'ailleurs, je suis bien obligé pour générer la heightmap et la normal map pour l'éclairage par pixel et l'ombrage.

Oh wow, tu as inventé ta propre technique pour faire du "Order Independent Transparency", désolé, mais il n'y a que 2 réel méthodes viables pour ça, qui demande des techniques très avancés, que je doute que tu aie implémenté. Une demande une version minimal de 4.0 et qui utilise les "per-pixel linked lists" et l'autre qui demande un pré-rendu.

La transparence à toujours été un gros problème en 3D. Je doute fort que tu l'ai résolue à toi seul, à surpasser de centaines de mathématiciens sur des dizaines d'années, surtout sans utiliser les dernières versions d'OpenGL, tout en étant performant, donc ton algo est certainement faux.

Je n'utilise plus les locks vu que je n'utilise plus de threads, en fin j'ai deux implémentation une avec thread et une sans thread mais ça ne change pas les performances

On peut programmer efficacement en threads sans utilisé de lock, il suffit d'encapsuler.

ma plateforme ne supporte que openg3.0

Personne ne fait du OpenGL 3.0, on fait du 3.3 car très peu de système, sinon inexistant, offre 3.0 sans 3.3. Même en 3.3 tu peux faire des rendu très performant, sinon il suffit de garder dans l'optique qu'il puissent supporter les bindless pour une optimisation futur.

Et oui tout ce qui est gratuit à ses limites, je devrai peut être coder mon propre driver.

Tu veux coder ton propre driver? Pour quoi faire ça? Ça ne te donnera pas plus de possibilités que ce que t'offre le hardware qui est déjà 100% utilisable dans OpenGL.

Tu propose plein de fonctionnalités pour ton moteur qui ne semble être que des essaies préliminaires sans base solide. C'est beau avoir réussi à affiché quelque chose, mais est-ce efficace, bien codé et que tu n'auras pas besoin d'y retoucher? Concentre toi sur les choses de bases, et si ça fonctionne bien, ensuite tu ajouteras d'autres fonctionnalités.

[Invité]

Oh wow, tu as inventé ta propre technique pour faire du "Order Independent Transparency", désolé, mais il n'y a que 2 réel méthodes viables pour ça, qui demande des techniques très avancés, que je doute que tu aie implémenté. Une demande une version minimal de 4.0 et qui utilise les "per-pixel linked lists" et l'autre qui demande un pré-rendu.

Je fais beaucoup de pré-rendus, c'est même obligé et ce n'est pas une méthode difficile, ça me permet de faire des rendus non saccadés sur des plateformes critique telle que la mienne, mais j'utilise aussi pleins d'autres techniques avancées qui me permettent d'afficher des choses de manière non saccadée avec un FPS très bas. (15 FPS)

On peut programmer efficacement en threads sans utilisé de lock, il suffit d'encapsuler.

J'encapsule déjà le tout, programmer en thread sans utilisé de lock est très compliqué, il faut passer par des queues lock free et faire beaucoup de benchmarks. :/
Sinon, si je ne lock pas j'ai des crashs, personnellement je préfère essayer de programmer le plus possible sans threads.

Personne ne fait du OpenGL 3.0, on fait du 3.3 car très peu de système, sinon inexistant, offre 3.0 sans 3.3. Même en 3.3 tu peux faire des rendu très performant, sinon il suffit de garder dans l'optique qu'il puissent supporter les bindless pour une optimisation futur.

Hé bah alors je dois être le seul à être bloqué sur du opengl 3.0 avec ma platforme et mon driver. (Le seul supporté par ma plateforme)
Mais bon ça n'est pas grave je m'en sors très bien même avec de l'ancien.
Et puis c'est toujours bien pour apprendre.

Tu veux coder ton propre driver? Pour quoi faire ça? Ça ne te donnera pas plus de possibilités que ce que t'offre le hardware qui est déjà 100% utilisable dans OpenGL.

Pas vraiment besoin de le faire je crois que ils seront passé à mesa 10 avant, la version du driver qui supporte opengl 3.3 mais lorsque je l'ai testée ça m'affichais du blanc à la place des textures hors que ça marche parfaitement bien avec opengl3.0 donc là j'attends, en plus, il n'est même pas encore dans le dépôt officiel d'ubuntu, je passerai sûrement le moteur en openg3.3 avec en tête que il y aura les bindless textures par la suite.

Inutile de me parler des driver propriétaires d'AMD qui supporte opengl 4.0 mais qui ne fonctionnent carrément pas.

Bref je préfère rester sur de l'ancien, ce n'est pas forcément parce qu'on utilise du moderne qu'on est un bon programmeur.

Tu propose plein de fonctionnalités pour ton moteur qui ne semble être que des essaies préliminaires sans base solide. C'est beau avoir réussi à affiché quelque chose, mais est-ce efficace, bien codé et que tu n'auras pas besoin d'y retoucher? Concentre toi sur les choses de bases, et si ça fonctionne bien, ensuite tu ajouteras d'autres fonctionnalités.

Non, je n'aurai pas besoin d'y retoucher, sauf si demain opengl 3.3 fonctionne correctement avec mon driver alors là il y aura, quelque petit changements à faire mais rien de très conséquent.

[maeiky]

Je fais beaucoup de pré-rendus, c'est même obligé et ce n'est pas une méthode difficile, ça me permet de faire des rendus non saccadés sur des plateformes critique telle que la mienne, mais j'utilise aussi pleins d'autres techniques avancées qui me permettent d'afficher des choses de manière non saccadée avec un FPS très bas. (15 FPS)

Ok et comment tu fais ton "Order Independent Transparency" alors?

[Invité]

Ok et comment tu fais ton "Order Independent Transparency" alors?

Pas besoin de faire de "order independent transparency", un test sur la composante alpha de chaque pixel qui est dessiné et qui va être dessiné à l'écran suffit.

Je ne dessine donc pas les pixels dans l'ordre, à chaque dessin je récupère juste la composante alpha du pixel qui est dessiné à l'écran, et je la compare avec la composante alpha du pixel à dessiner, si la composante alpha du pixel à dessiné est plus petite que la composante alpha du pixel dessiné, alors, je ne l'affiche pas car il est caché, sinon, je l'affiche. (sans faire de test sur le z sinon le pixel plus transparent vient caché le pixel plus opaque et l'alpha blending ne se fait pas)

Donc le pixel à dessiner n'est pas affiché si sa composante alpha est plus petite et si son z est plus petit que le pixel dessiné, sinon, il est affiché.

PS : Bon, c'est peut être pas la manière la plus "correcte" de faire et l'algorithme peut être faux dans le cas ou l'on veut que le blending alpha se fasse même si le pixel à dessiné est moins opaque et est derrière le pixel dessiné, mais bon dans mon cas ce n'est pas nécessaire, je ne compte pas faire des graphismes très développé, je n'ai pas un PC assez puissant et puis, au pire je peux toujours rajouter un paramètre dans le shader pour faire un alpha test personnalisé ou une équation tout comme on le fait avec le blending pour le pixel courant et le pixel à dessiné.

Bref je pense que je vais faire une page sur le sujet.

[maeiky]

Bon, c'est peut être pas la manière la plus "correcte" de faire et l'algorithme peut être faux dans le cas ou l'on veut que le blending alpha se fasse même si le pixel à dessiné est moins opaque et est derrière le pixel dessiné

Ça confirme ce que je pensais, tu devrais au moins dessiné les plans en ordre pour faire les choses bien. Ce n'est pas très correct de proposé un moteur de jeux sans spécifier qu'il peut y avoir de glitchs dans les éléments transparents, surtout pour la 2d.

[LittleWhite]

alpha du pixel qui est dessiné à l'écran

Vous récupérez la valeur qui est actuellement sur l'écran ? Comment faites vous ?

Sinon, le vrai blending utilise la couleur du fond, à chaque fois qu'une nouvelle couche est ajoutée. Vous, vous semblez faire un truc ultra bizarre, qui dit qu'un objet plus proche et plus transparent n'est pas affiché. De plus, comment avoir les valeurs pour les autres choses déjà rendues/plus loin dans la scène ?

[Invité]

Ça confirme ce que je pensais, tu devrais au moins dessiné les plans en ordre pour faire les choses bien. Ce n'est pas très correct de proposé un moteur de jeux sans spécifier qu'il peut y avoir de glitchs dans les éléments transparents, surtout pour la 2d.

Bof, je ne perçois pas de glitchs pour l'instant et la différence de couleur est trop minime pour être perçue à l’œil nu.

Voici un article ou j'explique comment je fais, toutes les textures que j'utilise sont semi-transparentes :

http://lolilolightdevblog.wordpress....ique-partie-2/

Si je rencontre des glitchs je ferai un autre algorithme plus complexe avec découpage et reconstitution de polygones mais, pour le moment je ne perçois rien d'anormal.

Il faut dire les textures ne sont pas toujours super, surtout pour le personnage, car ce sont des textures que je reprend sur internet et ou je sélectionne les pixels avec gimp pour transformer la couleur de fond en transparence donc parfois il peut semble y avoir des petits trous dans les pixels ce qui explique les ombres qui paraissent parfois bizarre, mais à part ça...

Bref de toute façon ce sont juste des textures de "test". ^^

[Invité]

Ha, LW!

Désolé je n'avais pas vu ton poste, la valeur des pixels déjà dessiné précédemment dans la scene est "blendé" (alpha blending) à chaque fois qu'un pixel est dessiné donc, il suffit juste de reprendre la valeur alpha du dernier pixel qui a été dessiné.

Le fait que je n'ai pas de glitch et sûrement le fait que je dessine le pixel sur la deuxième texture de rendu peut importe sa composante alpha, donc le pixel est quand même "blendé."

Le fait est juste que je n'écris pas le z du pixel sur la 1ère texture de rendu si il est plus transparent et si il est devant le pixel couramment dessiné, ainsi, il ne vient pas caché le pixel opaque.

PS : j'ai mis des heures et des jours à essayer de comprendre ce qu'est le blending, le depth test et l'alpha test, donc, je peux comprendre que ça soit difficile à comprendre. :/
Je suis juste un peu frustré de ne pas pouvoir profité des nouvelles fonctionnalités de opengl 3.3, mais j'espère que je pourrai en profiter dans le futur pour augmenter mon FPS qui est assez bas. :/

[maeiky]

Le fait est juste que je n'écris pas le z du pixel sur la 1ère texture de rendu si il est plus transparent et si il est devant le pixel couramment dessiné, ainsi, il ne vient pas caché le pixel opaque.

Encore une chose à proscrire, si tu n'est pas complètement indépendant de l'ordre d'affichage , récupéré le pixel d'un FBO n'est que réellement actualisé qu'à la fin du dessin de celui-ci. Le GPU travaille en parallèle et tout les éléments peuvent être dessiné simultanément et dans n'importe quel ordre. Encore une fois tu vas avoir des glitchs. Ce n'est pas pour rien qu'il faut utiliser les fonctions de blending d'opengl, en plus d'être plus performante. Par contre, il y a bien une extension qui permet de jouer dans le pipline de blending, mais ce n'est pas disponible sur toute les plateforme.

Bof, je ne perçois pas de glitchs pour l'instant et la différence de couleur est trop minime pour être perçue à l’œil nu.

Ne te limite pas seulement au jeu que tu veux réaliser. Si tu n'utilise pas beaucoup de transparence ça peu passer. Mais garde à l'esprit que pour d'autre ça peu devenir horrible.

[Invité]

Ok, je garderai ça en tête pour la suite, mais, étant donné que je fais un display après chaque dessin d'une entité, le FBO se remet bien à jour.

Maintenant au niveau des performances ça peut jouer je pense.

Nouvel article sur la génération de la normal map, j'en ai profité pour afficher la heightmap générée dans l'article précédent.

http://lolilolightdevblog.wordpress....ique-partie-3/

Les articles suivant traiterons de la lightmap et de la shadowmap.

PS : bien que je fais du sprite batching avant de dessiner tous les tableaux de sommets donc, je fais moins de draw call et moins de display.

M'enfin bon, je préfère ça que d'avoir à découper tout les polygônes, calcule leur centre en z et afficher tout les polygones découpé dans l'ordre, là, c'est le CPU qui va en bouffer. ^^

Ca, c'est la 3ème méthode que tu n'a pas mentionné.

[maeiky]

Ca, c'est la 3ème méthode que tu n'a pas mentionné.

Oui puisque ça n'entre pas dans la catégorie ""Order Independent"

[Invité]

Nouvel article sur le light mapping :

http://lolilolightdevblog.wordpress....ique-partie-4/

Par contre sans opengl 3.3 c'est limite au niveau des perfs, je ne pense pas que je vais pouvoir utiliser cette technique en 3D. :/ (Donc je vais attendre d'avoir un meilleur driver pour ça)