D’accord, malgré tout les questions sont pertinentes

Lynix a écrit:

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).

Lynix a écrit:

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 désavantage que tu énonce, qui semble être le seul, est un long temps de compilation au lancement qui rendrait le tout inutilisable.

Bon, j'ai poster pour monter mes premiers avancement, donc ils est un peu tôt pour dire que je n'ai pas ce problème. Mais je peux donner les vrai chiffres que j'ai en se moment et j'en suis assez satisfait.

C'est un premier jet et je suis certain que je peux améliorer le tout bien d'avantage.

Alors pour mon moteur entier, (je suis conscient qu'il n'est pas 100% complet, mais il n'en sera pas beaucoup plus lourd une fois fini), il prend 1 minute 39 en AOT



Ensuite pour la version JIT, avec exactement les même options de compilation (incluant l'optimisation -O2 ).
Ça prend 6 secondes.

J'ai un rapport 16 fois plus rapide.

Le lancement peu être encore bien plus rapide sans activer les optimisations, je vais tester lorsque j'aurais 2 minutes.

Ça me semble utilisable pour plusieurs milliers de lignes de codes, et quand on y pense un jeu ne va prendre qu'une fraction de cela.
J'ai aussi pensé à rendre le moteur comme une lib déjà chargé à l'avance , on peut voir ça comme une dll et les jeux s'y connectent.

Lynix a écrit:

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

Si on parle de JIT et non de rendu GPU, tu va pouvoir tester toi même, je conçois une VM qui va accepter pratiquement tout code C++ sans trop de dépendances. Au niveau des performances, et bien elles seront exactement les mêmes que si tu compile en AOT (Façon non portable, dernière version SEE, x64, etc).
La différence est lorsque tu distribue ton programme, il va pouvoir être compiler différemment selon l’architecture.

-
Edité par Maeiky 1 juin 2016 à 11:58:35

Maeiky a écrit:

Au niveau des performances, et bien elles seront exactement les mêmes que si tu compile en AOT (Façon non portable, dernière version SEE, x64, etc).
La différence est lorsque tu distribue ton programme, il va pouvoir être compiler différemment selon l’architecture.

Ça encore une fois, c'est la théorie du JIT, en pratique seuls les "hotspots" sont jités, et bien moins que s'ils étaient compilés en AOT -msse4 -O3 -fvectorize etc.

Je ne veux pas parler de chiffres, mais plutôt de faits:

-l'AOT est très majoritairement utilisé dans les applications performantes.

-Android, qui utilisait le JIT, est passé à l'AOT (c'est ça le fameux "Optimisation des applications" au lancement), avec pour mention que ça allait "améliorer les performances" (note: les applications sont compilées sur la plateforme même, donnant l'avantage du JIT à l'AOT, cependant la compilation est elle-même plutôt longue, j'utilise cet exemple pour indiquer que le JIT manque clairement de temps par rapport à l'AOT et ne peut donc atteindre les mêmes performances).

Comment tu expliques ces deux faits ? Tu es plus malin que les ingénieurs de Google et les développeurs de moteurs de jeux ?

-
Edité par Lynix 1 juin 2016 à 13:10:40

Pas plus malin, je procèdes différemment depuis longtemps, je sort des chantiers battu, tu devrais le savoir

Lynix a écrit:

Ça encore une fois, c'est la théorie du JIT, en pratique seuls les "hotspots" sont jités, et bien moins que s'ils étaient compilés en AOT -msse4 -O3 -fvectorize etc.

Nonon, LLVM applique les optimisations sur l'ensemble. Par contre si je veux me compliquer la vie, je peux séparer mes modules et appliquer des optimisations différentes.
L'idée des "hotspots" est de séparer les "classes" qui sont gourmandes, mais je ne suis même pas certains que ce sera nécessaire.

J'ai déjà un bon résultat 6 secondes en full optimisé avec le moteur complet.

Ce que je vais faire surtout est d'enlever tout ce qui est lourd à compiler et qui ne risque pas trop de changer avec le temps et de l'inclure dans la VM.

Je vais inclure le plus de chose dans la VM, du genre Freetype, lecture Audio, etc.

Ensuite le reste sera très léger à compiler et exécuter.

J'ai pas essayer la nouvelle API "orc" non plus, qui améliore peut-être les performances, à voir.

Une vidéo qui explique un peu mieux le truc :

Kernel Cpcdos OSx + LLVM

Je suis conscient que l'AOT a des avantages, c'est pour cela que je vais probablement combiner les 2 méthodes.
En fait on peut optimiser un code LLVM IR pour donner un autre LLVM IR, l'optimisation peut se faire à n'importe quel étape, donc on peut imaginer une phase d'installation pour la première exécution, ensuite le LLVM IR sera plus rapide à démarrer.

Bonjour, je reprend officiellement le développent après une looooongue absence.  Dernièrement, j'ai été pris par de nombreux projets.
Entre autre, j'ai bien avancé le toolchain WebGL, ce qui va me permettre de montrer mes avancements.

Je vais donc montrer le développement au fur et à mesure. Bon tout ceci ne sont que de prototype, j'ai rien pour l'instant de très stable.


Alors où en étais-je? Ah oui le système de Tile, avec le logiciel Tiled.

J'ai pensé que ça serait bien d'ajouter un effet 3d, une profondeur, j'ai fais le test et ça rend plutôt bien

Avec un peu de lumière et quelques animations, il faut dire que les tiles sont à la fois des objet déconnectés les un des autres et connectés, le challenge est de faire un rendu contigu sans voir de délimitations, ici entre autre, j'ai fais une interpolation custom entre tiles.
J'ai également ajouté un bump mapping traité de façon "live", et puis faire une normal map ne marche pas très bien sur des tiles

Voici le résultat:




Plus clairement le bump mapping:



Pour tester Live dans WebGL:

https://cwc-gze.github.io/GZE_3D_Tiles/Example/Animated/App.html

-
Edité par Maeiky 14 novembre 2019 à 15:27:55

Bonjour,

Je présente aujourd'hui une petite expérimentation, je voulais savoir si c' étais possible de faire un "merge" de 2 images 2D.

Par exemple prendre un buisson et ajouter un rocher au travers, avec un test de profondeur.

Je crois avoir réussi quelque chose de potable:

Ici les images que je tente de combiner:




Ce qui donne ce résultat:



Vous pouvez tester live ici:

Two images merging test

Salut, comment faire pour télécharger le moteur ? Et pas de documentation ?

Hello,

Oui je présente un moteur en cours d'évolution, il n'est pas encore suffisamment au point.

La documentation n'est toujours pas prête, mais voici les grandes lignes:

GZE est programmé dans un langage de mon invention, le C~ (plus textuellement le CWayv), ça particularité c'est qu'il peut interagir avec le C++ un peu comme le "subset" C

J'ai également réalisé un compilateur, Cwc, qui va chercher les toolchains automatiquement (pour l'instant Windows Only).
Un peu comme CMake, il suffit de double cliquer sur un fichier make ".cwMake" et sans casse tête, il va te sortir le binaire de la plateforme souhaité.

Donc n'importe quel projet fait avec GZE contient un .cwMake, celui-ci va aller télécharger la version de GZE requise, le Toolchain requis et compiler automatiquement le tout.

Cwc peut également être utilisé pour n’importe quel projet C++, C, Python ou même d'autres langages.
Par exemple, quelques projets

Et ici, je mets mes projets fait avec GZE, dedans ce trouve un ".cwMake". Il suffit d'aller chercher la dernière version de Cwc de le lancer une fois pour qu'il associe les fichiers cwMake.

Pour les sources du moteur: https://github.com/VLiance/GZE

-
Edité par Maeiky 27 novembre 2019 à 23:21:51

Tu fais ton propre langage de programmation et ton propre compilateur ? 

Tu te casses un peu la tête là surtout si cmake fait pareil.

"cmake fait pareil"

Ton choix, mais pas adapté pour ça, si tu regarde la plupart des langages haut niveau, ils compilent directement vers un binaire sans avoir à configurer quoi que ce soit, sans avoir à "premake" ou configurer un compilateur.

Avec Cwc la compilation est simplifier au maximum, si je veux compiler vers WebGL, Linux ou Android, il se charge de tout sans modifier les variables d’environnement ou quoi que se soit sur le système de l'utilisateur, ce qui est très inadapté du coté de CMake

En plus d'ajouter plein de features, comme la compilation par dossier et la modularisation par Libs et Toolchain où chacun peut appliquer leur propre configuration selon la plateforme et autres.

La config est différente suivant la plateforme avec CMake et c'est assez relou de devoir configurer un compilateur.

Bonjour,

Voici une Font qui est généré et affiché en "Pixel Perfect"

C'est-à-dire, de taille minimale possible sans être flou, tout en gardant un filtrage bilinéaire, ce qui permet d'appliquer une rotation 3D par exemple.

-
Edité par Maeiky 3 décembre 2019 à 22:56:58

Salut, je vois que tu présentes à chaque fois des images.

Je trouves celà très bien.

Mais as tu déjà pensé à faire un jeux complet avec le moteur ?

Je ne vois pas non plus de vidéos.

Tu fais comment pour coupler deux images ensemble ?

Moi je ne vois pas de trop comment faire à part en utilisant des linked list et de changer la position en z des sommets de manière à ce que certains pixels viennent au dessus et d'autres viennent en dessous.

Mais je ne fais pas ça, j'utilise un masque de transparence avec gimp, pour les transitions.

PS : a oui mais il n'y a pas de semi-transparence sur tes images donc un simple test de profondeur suffit.

Je pense que je vais changer mes tiles et mettre un sommets au centre avec des Triangles fan au lieu de quads, et mettre un z plus bas sur les sommets au bord et un z plus élevé sur le sommet au centre c'est comme ça que tu fais non ? 

Je trouve que c'est une bonne idée je devrais l'implémenté dans mon framework.

-
Edité par OmbreNoire 5 décembre 2019 à 10:26:04

OmbreNoire a écrit:

Mais as tu déjà pensé à faire un jeux complet avec le moteur ?

Salut, oui j'y pense sérieusement dernièrement, car le moteur commence à être fonctionnel. Il manque encore beaucoup de chose certes, mais c'est en créant un premier jeu qu'on peut roder le tout.

OmbreNoire a écrit:

Tu fais comment pour coupler deux images ensemble ?

Tien je me demandais si quelqu'un allait poser la question, il y en a qui suive  (il ce peut que j'ai omis d'expliquer ). 

OmbreNoire a écrit:

... mettre un sommets au centre avec des Triangles fan au lieu de quads, et mettre un z plus bas sur les sommets au bord et un z plus élevé sur le sommet au centre c'est comme ça que tu fais non ? 

Bien essayé, mais ce n'est pas ça.  Je voulais un résultat au pixel près, subdivisé et changer les vertex ça va être lourd pour rien (et un résultat douteux). Ce que je fais en réalité c'est que je définie une profondeur avec une "DepthMap", donc chacun des pixels de l'image contient l'information sur un Z différent. Je peux aussi jouer avec la lumière avec cette méthode.

Voici à quoi ressemble la DepthMap des mes 2 objets:

J'ai fais ce prototype pour l'appliquer à un jeu justement, pouvoir faire de grande map détaillé en utilisant des "particules" qui se fondent ensemble.

À voir.

Du nouveau, voilà j'ai enfin mon Toolchain pour Android fonctionnel [DroidRT]. Donc en plus de pouvoir exporter vers WebGL, on peut maintenant créer facilement un Apk, toujours sans même avoir à changer une ligne de code. Tout ça, sans avoir à modifier votre environnement avec l'installation ou la configuration de compilateurs ou autres.

Comme première exemple, une implémentation de mon Shadertoy qui est littéralement un copier/coller d'un shader que j'ai  réalisé, puis inséré dans GZE.
Voici ce que ça donne sous WebGL:

*Vous pouvez tester ici

Et le même résultat sous Android:


Ou tout simplement, voir la page Github du projet

Juste pour le fun, un petit "bush" vite fait, je trouve l'effet plutôt sympa:





https://cwc-gze.github.io/GZE_Bush/Test/Bush1/App.html

Oupss, petite erreur de manipulation de ma part, parfois on obtiens des résultats surprenant complètement par erreur