Pardon mon anglais n'est pas super, j'espère avoir corrigé mes principales erreurs.

Str4nger a écrit:

A priori quelqu'un qui utilise une tilemap va vouloir le rendu "pixelisé" de GL_NEAREST. Quand on travaille en tiles c'est qu'on est en 2D, en pixel-perfect, on ne veut surtout pas d'interpolation ou même de coordonnées non-entières qui nuisent activement à la qualité du rendu. La feature est unique à ton moteur pour une bonne raison.

Mais où est-ce que tu voie de la qualité dans un rendu en Nearest??

Un rendu bilinéaire s'applique parfaitement à la 2d, c'est surtout visible lors de mouvement lent, en Nearest se sera saccadé avec des effet de scintillements, de plus un bump mapping en Nearest serait vraiment moche.

Bon, pour montrer la différence j'ai fait les 2 types, vous pouvez télécharger l'exécutable ici :

GZE_Interpolation_Correction_With_Tiles.zip

J'ai tenté d'enregistrer un gif, mais le résultat est ~ 5 frames secondes pour ne pas prendre trop d'espace (l'effet est moins visible)

Bilinear.gif

Nearest.gif

-
Edité par Maeiky 8 septembre 2015 à 0:35:02

Juste deux mots: filtrage anisotropique.

Et j'emmerde cet éditeur de merde qui s'amuse à mettre mon texte en petit.

-
Edité par Lynix 7 septembre 2015 à 20:18:22

Lynix a écrit:

Juste deux mots: filtrage anisotropique.

Pourquoi pas, mais on s’entend que c'est une coche au-dessus et c'est pas mal plus près d'un rendu bilinéaire que nearest.

Ça consomme aussi plus de mémoire, mais je ne suis pas fermé à l'éventualité de l'implémenté, avec une option pour changer la qualité.

-
Edité par Maeiky 8 septembre 2015 à 0:39:39

Le filtrage anisotropique peut (doit?) être utilisé avec le filtrage nearest, ce n'en est pas un concurrent.

Si tu actives ce filtrage, tu peux laisser le filtrage nearest, tes textures ne seront pas floutées et tu auras un bien meilleur rendu en perspective.

Je ne crois pas que tu puisse activer deux filtrages, ou pire encore un "filtrage nearest" (aucun filtrage) avec un filtrage anisotropique.

Je n'ai pas beaucoup étudier le filtre anisotropique, mais d'après ce que j'ai compris, ce n'est que l'évolution du mipmap. Le mipmap est utiliser avec un filtre trilinéaire, qui est un filtre bilinéaire avec l'ajout d'une dimension, les différents mipmaps. Car lorsque le triangle est plus petit que le triangle source, il perd l'information des pixels intermédiaires (le défaut du filtre bilinéaire).

Les mipmaps sont donc des versions réduites de l'image source à différent scale, ont conserve ainsi la bonne interpolation des pixels intermédiaires.

Pour le filtre anisotropique c'est la même chose, mais les mipmaps ont une nouvelle dimension, c'est à dire qu'il sont redimensionner sur l'axe X, puis sur l'axe Y, ainsi ont récupère l'information perdu si le triangle n'a pas le même ratio, il est plus large que haut par exemple.

Mais niveau qualité/mémoire/performance/complexité, le filtre bilinéaire est le meilleurs compromis.

*Un filtre bilinéaire et non linéaire, GL_LINEAR -> Bilinéaire

Edit : En y repensant, si ce que tu veux dire c'est pour avoir un effet de "gros pixel", il est probablement possible de simuler ou d'avoir une source redimensionné sans interpolation, puis appliquer l’interpolation voulue. Donc oui, ils serait en quelque sorte combiner dans ce cas.

-
Edité par Maeiky 8 septembre 2015 à 4:43:21

Tu vois le filtrage point, bilinéaire, trilinéaire et anisotropique comme une suite, les barreaux d'une échelle, et ce n'est pourtant pas le cas.

Mipmapping (soft) avec du filtrage point:

glSamplerParameteri(GL_TEXTURE_MIN_FILTER, GL_NEAREST_MIPMAP_LINEAR);
glSamplerParameteri(GL_TEXTURE_MAG_FILTER, GL_NEAREST);

Filtrage anisotropique sans mipmapping avec filtrage point:

glSamplerParameteri(GL_TEXTURE_MIN_FILTER, GL_NEAREST);
glSamplerParameteri(GL_TEXTURE_MAG_FILTER, GL_NEAREST);
glSamplerParameterf(GL_TEXTURE_MAX_ANISOTROPY_EXT, 8.f);

Au passage, il n'est pas vraiment utile de m'expliquer comment tout ça fonctionne

En effet on peut en quelque sorte les décomposer (pour avoir un filtre ... moins bon ) .

Web a écrit:

GL_NEAREST - no filtering, no mipmaps
GL_LINEAR - filtering, no mipmaps
GL_NEAREST_MIPMAP_NEAREST - no filtering, sharp switching between mipmaps
GL_NEAREST_MIPMAP_LINEAR - no filtering, smooth transition between mipmaps
GL_LINEAR_MIPMAP_NEAREST - filtering, sharp switching between mipmaps
GL_LINEAR_MIPMAP_LINEAR - filtering, smooth transition between mipmaps

So:
GL_LINEAR is bilinear
GL_LINEAR_MIPMAP_NEAREST is bilinear with mipmaps
GL_LINEAR_MIPMAP_LINEAR is trilinear

-
Edité par Maeiky 8 septembre 2015 à 19:34:03

Il ne s'agit pas de "les décomposer en quelque sorte" pour obtenir un filtre "moins bon", mais d'avoir le filtrage le plus adapté à ce que tu veux.

Ce n'est pas parce que les jeux ne proposent généralement que "point - bilinéaire - trilinéaire - anisotropique" que d'autres combinaisons sont impossibles (cela dit, il s'agit bien des plus courantes).

Encore faut-il leur trouver une utilité, par exemple : "GL_NEAREST_MIPMAP_NEAREST - no filtering, sharp switching between mipmaps"

Pour moi c'était linéaire de façon implicite (GL_LINEAR_MIPMAP_LINEAR).

Est-ce une question de performances?

Ben l'utilité est toute trouvée pour celle du haut (GL_NEAREST_MIPMAP_LINEAR), car elle te permet d'avoir ton rendu "point" tout en ayant des mipmaps (et donc en améliorant la qualité du rendu).

Il existe des cas rares où ça peut servir, je n'en ai pas en tête pour GL_NEAREST_MIPMAP_NEAREST (excepté lorsqu'on veut avoir une séparation nette, comme lorsqu'on trafique les mipmaps, ce que Valve a fait pour le Source Engine pour afficher les niveaux de mipmaps avec des couleurs).

Après oui, tout ceci a été décidé il y a plus d'une vingtaine d'année, donc les performances peuvent avoir été un facteur (ceci dit, Vulkan propose également cela de la même façon, de ce que j'en ai vu).

Ah ben oui, c'est bête, c’est peut-être peu utile pour un rendu final, mais pour un traitement intermédiaire ça peu servir, ce qui n'est pas limitant.

Tout ça me donne une idée pour faire un rendu style rétro

Une autre victoire!

Suite à cette discussion, je me suis rendu compte que le filtre bilinéaire donne un résultat plutôt flou lorsqu’il s'agit de conserver un style pixelisé. J'ai donc tenté de garder le meilleurs des deux monde.

J'ai réussi à obtenir un rendu plus rétro, afin de pouvoir conserver un aspect pixelisé tout en ayant une transition "smooth" entre ceux-ci.
La solution est donc un mixe entre un rendu nearest et bilinéaire. Ceci agit comme si le centre du pixel conserve sa couleur et son contour transitionne avec les pixels voisins selon un ratio.

Ce rendu est peu couteux et est compatible avec l’interpolation entre tiles.

Voici le résultat :

Voici une animation avec le ratio qui augmente progressivement :

C'est vrai que tu as tout piqué à Lynix et nazaara?

Je ne sais pas d'où tu prend cette information, mais tout est réalisé par moi, en respectant les licences. Je n'ai jamais volé de code et surtout pas Nazara qui n'a rien à voir avec mon moteur.

Je connais le projet Nazara, j'ai survoler le code, sans plus.

À la base c’est très différent, je vise la portabilité,  simplicité et légerté. Je réalise une base qui va permettre de créer n'importe quoi et pas seulement des jeux 3d. 

Le moteur est bien plus orienté GUI et 2d, il peut faire des transformations et effets 3d, mais rien d'aussi avancé qu'avec le moteur Nazara.

Le moteur à été créer dans un but premier pour pourvoir utiliser le langage de mon invention, comme tu auras pu comprendre le Lnx, mais il ne se limite pas qu'à cela, il sert de base pour n'importe quoi, c'est un Ground Zero.

GilbertFroseph a écrit:

C'est vrai que tu as tout piqué à Lynix et nazaara?

Bon ça fait un moment que je n'ai pas donné de nouvelles. En fait c'est pour une bonne raison, je travaille sur plusieurs fronts simultanément, l'IDE, le site Web, le langage, le moteur.

Je modifie en grande partie GZE, le moteur, pour qu'il soit encore plus modulable, pour incorporer un principe que j'ai appelé Overplace, le tout de façon muti-thread.

L'Overplace permet d'ajouter en quelques sorte un module qui se place "par dessus", un peu comme un plugin. Par exemple, j'ai mes fonctions communes à toutes plateformes, lorsque j'overplace la lib Windows, les fonctions écrasent ceux communes (par héritage).  Je peux donc facilement changer de module, d'une plateforme à l'autre.

J'ai changé le tout dernièrement pour rendre l'overplace de façon dynamique.
Ma première version statique (à la compilation) fonctionnait, mais était très limité. Il est maintenant possible de changer de module au runtime relatif au thread courant. Deux thread peuvent avoir un module différent.

Ceci est plutôt pratique, par exemple en ce moment je travaille pour intégrer WebGL,  je vais faire une détection de la version de WebGL au runtime et selon la version détecté, WebGL2, WebGL1, Canvas2d (WebGL indisponible), je vais overplacer le module en conséquence. Ce qui permet un fallback de WebGL, sans avoir à créer plusieurs versions différentes du projets.



Donc j'ai bel et bien commencé le portage du moteur vers le Web, ça compile  .
J'ai une première version très minimal, de disponible, il est possible de communiquer avec le javascript, HTML & cie, pour preuve j'ai même fait une console en javascript.

Vous pouvez essayer mon tout premier programme live dans votre navigateur, qui en gros fait simplement un glClear :

http://www.simacode.com/fr/demos/wglapp/Demo/

Tester sous Firefox, Chrome, IE

-
Edité par Maeiky 6 décembre 2015 à 9:34:53

Vraiment bravo pour ton travail c'est phénoménal, j'espère qu'on pourra bientôt profiter de tout ça

GZE reborn!

J'ai finalement réussi un portage vers WebGL, ça ma pris un moment. Le Web avec Emsciptem est probablement la plateforme la plus difficile à supporter.

De plus j'ai tout réécris GZE de Zéro (ironiquement), plus propre, bien plus portable et surtout multi-threaded.
J'ai conçu un système pour générer automatiquement les fonctions OpenGL pour OGL desktop, WebGL ou ES, on peut voir ça comme une version OGL réellement portable, le tout avec des énumérations claire qui permette l'auto-complétion.

Je me suis lancé dans un Raymarching comme petite démo, qui fonctionne sur Windows et WebGL

Vous pouvez voir le résultat ici :
/Raymarching_DataBlock/


Screenshot sur Windows :

-
Edité par Maeiky 31 mai 2016 à 17:45:06

Bonjours, ça fait un moment que je n'ai pas donnée de nouvelles, car j'ai travaillé sur quelque chose de gros.

Alors, je vous annonce qu'il sera désormais possible d'exécuter le moteur de façon JIT (Just In Time).

GZE est donc un des premier moteur C++, "Jit-able", si ce n'est pas le seul.

Basé sur LLVM, c'est un peu comme la machine virtuel Java, en même temps ça n'a rien à voir, car ici on parle de C++, LLVM IR et même D++. De plus c'est incomparable en termes de performances, sans parler d’un GC inutilement lourd.

 

Qu'est que le Jit, ça mange quoi en hivers?

Le Jit est une compilation à chaud, aucun fichier exécutable n'est généré, ni binaire, tout se fait directement en mémoire.

Quels en sont les avantages?

Il y a de nombreux avantages, dont les principaux:

-Meilleurs performances, le code est compilé sur la machine client et profite ainsi des toutes l’optimisation applicable de l'architecture sur lequel il est compilé. Par exemple la plateforme possède tel types d'instructions SSE, pas de problème, il peuten profiter.

-Meilleurs portabilité, le même fichier fait pour toutes les plateformes, plus de casse-tête pour faire des versions 32bit ou 64bit.

-Ça permet de faire de l'interprétation, le C++ est interprétable, ainsi que le LLVM IR et éventuellement le D++, on peut donc évaluer des fonctions C++, à même notre application.

-Le tout est très modulaire, divisé en libs, on peut plugger à chaud des modules (sans redémarrer le programme), ici c'est parfait avec mon système d'overplace (un peu comme des plugins).

-On peut optimiser le code pendant que celui-ci tourne, ajouter/supprimer des fonctions.

-etc

J’annonce aussi que je vais supporter la plateforme CpcDos, en collaboration direct avec l’auteur.

CpcDos est un OS, ultla léger, ultra customisable. Basé sur le Dos,les dev Windows n’en sont pas trop perdu.

Par la même occasion on va rendre cet OS Jitable nativement, c'est-à-dire que j’y inclue ma machine virtuelle/compilateur du nom de LibRT (basée sur llvm)nativement.

J’ai donc fait un portage de LLVM vers CpcDos et ça fonctionne très bien.
Voici les premiers résultats :

Jit on CpcDos

Je pense que c'est une connerie.

Ok, le JIT c'est cool et plus performant sur le papier, mais en pratique ce n'est pas le cas pour une raison très simple: les optimisations poussées (celles qui importent vraiment) prennent beaucoup plus de temps que ce que le JIT peut se permettre (quand on voit que la compilation d'un moteur entier peut prendre plusieurs heures, le JIT n'a aucune chance de rivaliser). Ça et le fait que le JIT ne compile pas l'entièreté du moteur.

Il y a d'autres points à prendre en compte, comme le fait que l'hôte n'aura peut-être pas les ressources suffisantes pour JITer efficacement (toi qui veut un moteur très portable, ça t'affecte particulièrement).

Article à lire.

Je sais que tu risques de prendre ça mal et qu'on va repartir en débat à la con, et je trouverais ça dommage après des mois de trèves, mais j'aurais dis pareil à n'importe qui d'autre, il n'y a rien de personnel ici.

C'est pas comme si javais pas poster une vidéo qui montre réellement les performances et le temps de compilation, soit dis en passant, en -O2. C'est un premier test et ça peu être davantage optimisé.

Mon moteur prend environ 1 minute 30 à compiler de façon standard.
Ça en prend 5 secondes en Jit, il ne faut pas que tu oublie que c'est pré-compiler en LLVM IR, et bien d'autre astuces que je n'ai pas envie de te faire part.

De plus, tu peux compiler sans optimisation (plus rapide), et optimiser au runtime.

-
Edité par Maeiky 9 mai 2020 à 19:00:38

Pourquoi ne pas utiliser directement un langage dynamique, plutôt que de s'embêter à compiler du C++ ?

Maeiky a écrit:

C'est pas comme si javais pas poster une vidéo qui montre réellement les performances et le temps de compilation, soit dis en passant, en -O2. 

Désolé de te le dire, mais ta vidéo ne montre pas grand chose.

Maeiky a écrit:

Mon moteur prend environ 1 minute 30 à compiler de façon standard.
Ça en prend 5 secondes en Jit, il ne faut pas que tu oublie que c'est pré-compiler en LLVM IR

Je ne l'oublie pas, mais toi tu ne devrais pas oublier que jusqu'ici, le JIT n'a jamais battu l'AOT (sinon on serait beaucoup plus nombreux à l'utiliser).

Aussi, le LLVM n'est pas du binaire x86_64.

Maeiky a écrit:

bien d'autre astuces que je n'ai pas envie de te faire part.

Pauvre de moi.

Maeiky a écrit:

De plus, tu peux compiler sans optimisation (plus rapide), et optimiser au runtime.

C'est le principe du JIT oui, d'optimiser au runtime en fonction de ce qui prend le plus de temps, mais je le répète, ça ne vaut rien jusqu'ici pour un moteur de jeu.

Le JIT est très utile pour les langages de scripting (merci @Str4nger), passer du runtime officiel Lua à LuaJIT par exemple va sacrément améliorer les performances, mais passer du C++ à du JIT, à mon humble avis tu vas te ramasser.

Maeiky a écrit:

Ça fait assez longtemps que t'es sur mon dos, va te trouver quelqu'un d'autre à emmerder.

C'est pas comme si j'avais dis que ça n'avait rien de personnel après tout.

Str4nger a écrit:

Pourquoi ne pas utiliser directement un langage dynamique, plutôt que de s'embêter à compiler du C++ ?

Pour les raison ci-haut, si tu ne sait pas lire, entre autre pour de meilleurs performances XD

Si vous n'avez rien de constructif et n'avez rien à dire à part rabaisser les projets, passer votre chemin.

-
Edité par Maeiky 9 mai 2020 à 18:54:14

Maeiky a écrit:

Pour les raison ci-haut, si tu ne sait pas lire, entre autre pour de meilleurs performances XD

C'est triste, 2 pauvres ignorants, jaloux

Ça a fait ma soirée .. 

Je passe mon chemin pour ma part, je sais de source sûre que tu n'apprends de tes erreurs que trop tard à chaque fois.

Donc bonne continuation, appelle-moi le jour où tu veux faire un benchmark entre nos moteurs respectifs.

Merci

Merci de montrer un minimum de respect envers les gens, si tu n'es pas capable de répondre aux questions et commentaires sur ton sujet de présentation, je t'invite à le fermer. Traiter quelqu'un d'ignorant lorsqu'il pose une question est inacceptable (surtout dans le cas présent, où même sans connaitre précisément le sujet, j'ai ri au fait de traiter Str4nger d'ignorant).

Pardon, je vais rester polie pour la suite.
Je vais ouvrir ma parenthèse et tenter d' être le plus bref possible, pour ne pas que ça parte en queue de poisson.

@Lynix, juste lire ta première phrase  "Je pense que c'est une connerie.", ma enlevé tout respect et il en avait déjà très peu.
Cette réponse sur un sujet nowhere, genre "Le Jit est il une bonne idée", ne m'aurait pas choqué, mais ici je le prend très personnel.

@Str4nger,  "plutôt que de s'embêter à compiler du C++" Compiler du C++ en JIT , m'a  demander beaucoup d'effort, alors je le prend personnel aussi (étant directement sur le page de mon projet)

Vous avez tous 2 des projets qui fonctionnent très bien. Svp descendez d'une marche, car je peux aussi bien critiquer vos projets de la même manière pour en trouver les poux.

Fin de la parenthèse et je souhaite ne plus y revenir.

Je t'invite absolument à venir chercher les poux de mon projet, je te promet que je ne vais jamais te traiter d'ignorant jaloux...

Maeiky a écrit:

@Lynix, juste lire ta première phrase  "Je pense que c'est une connerie.", ma enlevé tout respect et il en avait déjà très peu.
Cette réponse sur un sujet nowhere, genre "Le Jit est il une bonne idée", ne m'aurait pas choqué, mais ici je le prend très personnel.

Je l'ai pourtant bien précisé, ma remarque n'était aucunement personnelle ni même à vocation insultante, c'est le genre de langage qu'on retrouve un peu partout entre les membres du forum, j'ai indiqué que c'était ce que je pensais, j'ai expliqué pourquoi, bref, si tu veux présenter des projets il va te falloir accepter la critique, venant de n'importe qui.

Maeiky a écrit:

@Str4nger,  "plutôt que de s'embêter à compiler du C++" Compiler du C++ en JIT , m'a  demander beaucoup d'effort, alors je le prend personnel aussi (étant directement sur le page de mon projet)

Même remarque, si tu n'es pas capable d'accepter les critiques sur tes idées, ne les présente pas.

Au lieu de réagir par l'insulte, tu aurais dû mieux détailler les avantages que tu trouves au C++ sur les autres langages dynamiques JITés, de bons arguments sont par exemple un runtime moins lourd (pas de GC), etc.

Maeiky a écrit:

Vous avez tous 2 des projets qui fonctionnent très bien. Svp descendez d'une marche, car je peux aussi bien critiquer vos projets de la même manière pour en trouver les poux.

Maeiky a écrit:

C'est triste, 2 pauvres ignorants, jaloux

C'est qui qui est jaloux/ignorants ... ? 

Plus sérieusement, je pense que la différence principale entre Str4nger/moi-même et toi, c'est que nous demandons à être critiqués, une critique n'est pas forcément négative et quand elle l'est, elle sert notamment à améliorer nos projets.

Tu crois qu'au long de mes six ans de développement de moteurs de jeux je n'ai jamais subis de critique négative ? J'en ai subis et même quelques unes, et à chaque fois je les prenais en compte. Soit je défendais mes choix, soit j'entrais dans un débat sur l'idée qu'on me soumet.

Pareil pour Str4nger, dont le jeu est en phase de tests alpha et a été très critiqués sur de nombreux points (comme le pire truc qu'on puisse reprocher à un jeu vidéo: de ne pas être amusant), il les a pris en compte et est allé de l'avant.

Maeiky a écrit:

Fin de la parenthèse et je souhaite ne plus y revenir.

Tu ne peux pas exposer un avis (ou autre chose) sur un forum de manière générale et demander à ce que personne n'y revienne, à moins d'avoir une certaine autorité (des pouvoirs ou dans certains cas être l'auteur d'un sujet, mais ça ne s'applique pas à la présentation de projets car le but dans ce cas est explicitement d'être critiqué).