Ardakaniz a écrit:

Ça resemble à une bibliothèque bas-niveau type openGL avec des préfix particuliers et tout.

Bas niveau? C'est une bonne chose? Ça serait quoi de haut niveau?

Ardakaniz a écrit:

Sinon, je trouve que plusieurs fonctions ont la même utilité : WnX() et TnX()

W = Wrap et T = To, ce sont 2 choses très différentes, un est pour le déplacement avec interpolation à une certaine position et l'autre est pour téléporter l'objet.

Au départ j’avais conçu mon moteur en spécifiant directement la valeur :

oImg->nX = 500; //Wrap
//ou
oImg->nX += 10; //Move

Mais ça comporte plusieurs lacunes, premièrement pas de easing, mais le principal défaut est que, selon la plateforme, le framerate varie. Tu auras un résultat différent, soit plus rapide ou plus lent. Je veux que tout ça soit géré automatiquement sans que l'utilisateur ce casse la tête.

Il n'y a qu'une lettre qui les différencie car ce sont les fonctions qui seront les plus utilisés, c'est plus jolie dans le code et moins long à écrire. De plus, il y a beaucoup de propriété et le modificateur (la lettre) :

Modificateur :

W = Wrap -> Ça téléporte l'objet à une position précise
T = To -> Ça déplace l'objet jusqu’à une certaine position
M = Move -> Ça déplace l'objet continuellement (+=)
L = Limit -> Ça configure la vitesse maximal (avec To)
E = Ease -> Ça configure easing croisant ou décroissant(avec To)
G = Get -> Getter sur l’attribut (On obtienr ça valeur)

Le modifier s'ajoute à l'attribut, voici la liste :

nX = Position X
nY = Position Y
nZ = Position X

nWidth  = Largeur
nHeight = Hauteur
nLength = Profondeur

nRoll  = Rotation X
nPitch = Rotation Y
nYaw   = Rotation Z

nRed = Luminosité Rouge
nBlue = Luminosité Bleu
nGreen = Luminosité Vert
nAlpha = Transparence Alpha 
nBright = Luminosité global (Rouge/Bleu/Vert)

En fait c'est la seul partie un peu spécial qui contient des modificateurs, ça peut sembler compliquer au début mais c'est très puissant une fois maitrisé. Pour le reste j'utilise toujours le même standard pour la clarté et surtout pour l'auto-completion . Exemple :

n = Nombre (float/int)
f = Fonction
o = Objet
etc.

Il y a aussi des préfixe sur mes classes comme j'inclue toujours "GZ_" pour tout ce qui est global, comme ça rien ne peux être en collision avec ma lib.

Ardakaniz a écrit:

Sinon si tu a besoin d'aide je peux t'aider (ou même faire parti du projet )

C'est certain que j'ai besoin d'aide, mais quel sont tes compétences? J'aimerais bien avoir un associé qui ne me lâche pas après un mois non plus.

C’est un peu difficile de m'aider car je n'ai pas encore fait de release pour l'instant, la première chose serait de tester la lib et de voir si tu as toujours le courage de faire partie du projet 

J'ai aussi besoin d'aide pour mon site Web qui est déjà commencé, le plus difficile selon moi à été fait, qui est le design qui fonctionne sur tout les navigateurs.

Ardakaniz a écrit:

EDIT : J'ai essayé GZE_Demo_Roll et mon antivirus (Avira (gratuit)) le bloque et dit qu'il contient le virus ou le programme indésirable "HEUR/APC (cloud)"

Depuis que j'ai inclue OpenGL, Avast vire fou (je suppose que c'est de même avec Avira). Il faut le désactivé ou inclure un répertoire à exclure. Ça me fait la même chose avec n'importe quel projet OpenGL, donc je suppose que ce n'est pas mon code ...

-
Edité par Maeiky 31 décembre 2014 à 21:55:54

Bonne année !! Bon je te redis tout ça demain... tout a l'heure en fait.

Moi je vais me coucher... 

-
Edité par Anonyme 1 janvier 2015 à 5:04:40

Bonjour Maeiky!

Je voulais savoir si l'on peut utiliser GZE pour développer une interface graphique de jeu vidéo? Si oui, de quelle manière? (projet avec des amis)

Maeiky a écrit:

Ardakaniz a écrit:

Ça resemble à une bibliothèque bas-niveau type openGL avec des préfix particuliers et tout.

Bas niveau? C'est une bonne chose? Ça serait quoi de haut niveau?

Bas niveau et haut niveau veulent dire : (issue du cours de C++) :

Qu'est-ce qu'un langage de haut niveau ?

C'est un langage assez éloigné du binaire (et donc du fonctionnement de la machine), qui vous permet généralement de développer de façon plus souple et rapide.
Par opposition, un langage de bas niveau est plus proche du fonctionnement de la machine : il demande en général un peu plus d'efforts mais vous donne aussi plus de contrôle sur ce que vous faites. C'est à double tranchant.

Le C++ ? On considère qu'il fait partie de la seconde catégorie : c'est un langage dit « de bas niveau ». Mais que cela ne vous fasse pas peur ! Même si programmer en C++ peut se révéler assez complexe, vous aurez entre les mains un langage très puissant et particulièrement rapide. En effet, si l'immense majorité des jeux sont développés en C++, c'est parce qu'il s'agit du langage qui allie le mieux puissance et rapidité. Voilà ce qui en fait un langage incontournable.

Le schéma ci-dessous représente quelques langages de programmation classés par « niveau » (figure suivante).
Les niveaux des langages

Donc bas niveau ça veut dire que ce sera plus dificile pour les débutants en C++.

Maeiky a écrit:

Ardakaniz a écrit:

Sinon si tu a besoin d'aide je peux t'aider (ou même faire parti du projet )

C'est certain que j'ai besoin d'aide, mais quel sont tes compétences? J'aimerais bien avoir un associé qui ne me lâche pas après un mois non plus.

C’est un peu difficile de m'aider car je n'ai pas encore fait de release pour l'instant, la première chose serait de tester la lib et de voir si tu as toujours le courage de faire partie du projet 

J'ai aussi besoin d'aide pour mon site Web qui est déjà commencé, le plus difficile selon moi à été fait, qui est le design qui fonctionne sur tout les navigateurs

Pour ça je t'ai MP.

gamizgaming a écrit:

Bonjour Maeiky!

Je voulais savoir si l'on peut utiliser GZE pour développer une interface graphique de jeu vidéo? Si oui, de quelle manière? (projet avec des amis)

Oui très certainement, j'ai spécifier moteur graphique car au début c'était seulement graphique, maintenant ça devient plus un moteur à tout faire, jeux 2d/3d ou application/widget. J'ai une grande expérience en réalisation de jeux vidéo, le moteur va s’orienter de plus en plus dans cette direction.

Ardakaniz a écrit:

Donc bas niveau ça veut dire que ce sera plus dificile pour les débutants en C++.

La bibliothèque est pensé pour être le plus simple possible, même pas besoins de ce casser la tête avec OpenGL, la portabilité et tout. Ce qui est bas niveau c'est le langage lui même. Pour ce qui est du langage j'ai encore une surprise en réserve.

Merci pour ta réponse

Je suis, super projet ! Très ambitieux

Enfin, la première version du code source est disponible sur GitHub!!!!

Ce sont les premiers pas du moteur, il contient encore des bogues et ne dispose pas de tous les features
Un tutoriel est inclue(Lisez-moi), pour installer et compiler le tout en 32 et 64 bits.

https://github.com/Maeiky/GZE

J'ai updater mon premier post. La première release est la plus compliqué, les autres vont être plus simple car ce ne seront que des updates. Ça fait si longtemps que je travaille sur ce projet que je commençais un peu à m' impatienté pour enfin avoir un code à publier. C'est loin d'être parfait et il manque encore plusieurs optimisations.  C’est en quelque sorte, une mini release, pour l'instant je ne publie que sur la plateforme Windows, les autres n'étant pas tout à fait au point.

Je crois qu'il y a moyen de s'amuser un peu, alors n'hésitez pas à prendre 2 minutes de votre temps pour l'essayer, l’installation se fait sans douleurs

Salut, J'ai testé... mais j'ai des erreurs :

J'en ai aussi d'autre mais j'arrivai pas a tous les afficher. En fait c'est juste les même que les première mais aux lignes 86, 87 et 89.

Donc voilà. Je vais quand même continuer de chercher.

EDIT : si tu vois mal va ici : http://tof.canardpc.com/view/991b5ed0-da37-41be-acb9-3fdfd0bf7588.jpg

EDIT 2 : C'est bon j'ai réussi mais il ne s'affiche rien dans la fenetre (voici le message de la console : http://pastebin.com/zfjuPD5w) et pour la correction du code : http://pastebin.com/6ceCiSd9

-
Edité par Anonyme 18 janvier 2015 à 16:03:46

Pour moi ça marche très bien

Il est clair d'après ton message qu'il y a un souci avec le fichier SysGpuShader_GzShader.h

donc pour le fichier des vertex shader.

Peux-tu utiliser le déboggeur pour voir à quelle ligne ça coince ?

Ardakaniz a écrit:

Salut, J'ai testé... mais j'ai des erreurs :

J'en ai aussi d'autre mais j'arrivai pas a tous les afficher. En fait c'est juste les même que les première mais aux lignes 86, 87 et 89.

Donc voilà. Je vais quand même continuer de chercher.

EDIT : si tu vois mal va ici : http://tof.canardpc.com/view/991b5ed0-da37-41be-acb9-3fdfd0bf7588.jpg

EDIT 2 : C'est bon j'ai réussi mais il ne s'affiche rien dans la fenetre (voici le message de la console : http://pastebin.com/zfjuPD5w) et pour la correction du code : http://pastebin.com/6ceCiSd9

-
Edité par Ardakaniz il y a environ 1 heure

Désolé mais je ne suis plus sur pc

j´irai voir ça plus tard

EDIT: je viens de comprendre le code. En fait normalement ça doit marcher, je ne voit pas pourquoi. 

-
Edité par Anonyme 18 janvier 2015 à 18:33:15

Ok, ça semble être une erreur avec une passe-passe pour faire une string multi-lignes. Avec le #define STR(a) #a de la première ligne.

Voir ici:

http://sevennet.org/2014/12/08/how-to-c-multiline-string-literal/

L'erreur est dû à la différence entre la version 4.8 et 4.7 de minGW

Il va falloir que je trouve un autre moyen de faire mes shaders, ça va être un peu moins jolie

-
Edité par Maeiky 18 janvier 2015 à 20:19:09

C'est corrigé, j'ai updaté le git, le problème était que MinGW 4.7, n'aimait pas en avoir 2 strings multi-lignes de suite.

Edit :

Bon, j'ai re-updater car  j'ai utilisé les "escape sequences" pour faire un "#" à la précompilation du shader coté GPU, il me fallait transformé un # en caractère. Ma première tentative à été de mette la valeur hexa :
\x23, sauf que pour faire un "endif" ça donne \x23endif. À la première vue ça marche sauf que ... , il y a des compilateurs comme celui d'Android qui pense que \x23e donne \x3E en hexa qui donne le caractère '>' au lieu de '#'.

Donc la solution est d'utilisé le octal avec la valeur \043, puisque c'est limité de 0-7 le "e" ne dérange pas, ce qui donne  \043endif\n pour un #endif

-
Edité par Maeiky 19 janvier 2015 à 4:15:23

Salut,

Pour commencer, bravo pour le travail accompli, je ne doute pas que cela t'a demandé beaucoup d'efforts, et je suis impressionné de voir la portabilité du machin.

Cependant, j'ai quelques points à critiquer, comme par exemple les performances, je pense te l'avoir déjà dit mais le rendu fait par le CPU et le rendu fait par le GPU, ça n'est pas du tout, la même chose, il ne suffit pas de transposer des algorithmes, il faut penser différemment la façon dont on gère le tout (essaie de faire du branching sur le GPU pour voir).

Tu nous dis ensuite que tes algorithmes de rendu CPU sont très optimisés, et honnêtement je n'en doute aucunement, mais l'architecture des CPU n'est pas prévue pour des calculs massivement parallèles, ce qui est la spécialité du GPU, et le calcul de pixels c'est un très bon exemple de calcul massivement parallèle (chaque pixel étant indépendant du pixel à côté de lui).

J'aimerai donc en savoir plus sur la façon dont tu gères ça, si tu le gères.

Ensuite j'ai un peu regardé le code:

-Pour commencer, tu fais l'assertion que les int font 32 bits, ce qui est faux sur quelques plateformes sur lesquelles j'ai déjà travaillé (certains microcontrôleurs ont des int 16bits, ce qui est d'ailleurs le minimum selon la norme, d'autres plateformes ont des int de 64 bits).

-Pourquoi utiliser une relique telle que wchar_t ? L'encodage varie d'un compilateur à l'autre, certains compilateurs peinent à le supporter (certaines distributions de MinGW notamment) et ça ne sert honnêtement à rien, autant passer par une vraie solution portable: l'Unicode (l'UTF-8 est ton ami).

-Pourquoi écrire des valeurs en durs dans le code plutôt qu'utiliser le header standard (même en C++03) <limits> ? (Je pense à GZ_nMaxFloat32 par exemple).

-

//64 bits use the same types as 32 bits because there smaller and faster
typedef unsigned int gzUInt;
typedef   signed int gzInt;

et ça vient d'où ça ? Si je ne me trompe, un processeur 64 bits traitera plus vite avec des entiers 64 bits qu'avec des entiers 32 bits (car les entiers 32 bits obligeront un masquage).

-Ensuite, pour ta façon de programmer en C++, si je prends un fichier au hasard, disons Queue.cpp, pourquoi est-ce que j'ai l'impression de lire du C ?

Pour en dire plus, il faudrait que je me plonge un peu plus dans les sources, parce qu'à première vue je m'y perds un peu.

Accepte ces remarques comme des critiques pour améliorer ton code, je ne cherche pas à te descendre

Tout d’abord merci pour ton intérêt et d'avoir pris le temps de lire et les critiques sont les bienvenue, ça me permet de débattre et éventuellement améliorer le tout.

Lynix a écrit:

Cependant, j'ai quelques points à critiquer, comme par exemple les performances, je pense te l'avoir déjà dit mais le rendu fait par le CPU et le rendu fait par le GPU, ça n'est pas du tout, la même chose, il ne suffit pas de transposer des algorithmes, il faut penser différemment la façon dont on gère le tout (essaie de faire du branching sur le GPU pour voir).

Je suis tout as fait d'accord sur ce point, mais j'y perçois tout de même des ressemblances surout pour les shader où la traduction ce fais assez aisément. Mon rendu GPU n'est vraiment pas optimal, pour l'instant c'est un rendu de façon "naïve", je fais simplement en sorte que ça fonctionne sur le plus de plateforme, ensuite je pourrais pensé à optimisé. La plus grosse optimisation sera de batcher le plus possible de choses, mais c'est un vrai casse-tête avec OpenGL ES2 avec les textures. Ensuite sur desktop je vais utilisé les bindless texture avec probablement du indirect.
Que veux-tu dire par branching?

Lynix a écrit:

Tu nous dis ensuite que tes algorithmes de rendu CPU sont très optimisés, et honnêtement je n'en doute aucunement, mais l'architecture des CPU n'est pas prévue pour des calculs massivement parallèles, ce qui est la spécialité du GPU, et le calcul de pixels c'est un très bon exemple de calcul massivement parallèle (chaque pixel étant indépendant du pixel à côté de lui).

J'aimerai donc en savoir plus sur la façon dont tu gères ça, si tu le gères.

Ah oui, mon algo CPU est très optimisé, j'y ai passé beaucoup de temps et même trop, probablement plus de 6 mois que sur ce bout de code. Tu as raison le CPU n'est pas bon pour le parallèle, c'est pour ça que j'ai implémenté le GPU avec les même appels, donc on peut passer directement d'un rendu CPU à GPU et même combiné les 2. Si on regarde les applications qui doive dormir la plupart du temps, le GPU n'est pas nécessaire en plus de pouvoir faire des Widgets transparent. La raison principal est la portabilité, créer au départ pour faire du graphique sur un microcontrôleur. Ensuite si le PC ne supporte pas complètement la version et extensions GPU, le rendu passe en CPU.

Lynix a écrit:

-Pour commencer, tu fais l'assertion que les int font 32 bits, ce qui est faux sur quelques plateformes sur lesquelles j'ai déjà travaillé (certains microcontrôleurs ont des int 16bits, ce qui est d'ailleurs le minimum selon la norme, d'autres plateformes ont des int de 64 bits).

//64 bits use the same types as 32 bits because there smaller and faster
typedef unsigned int gzUInt;
typedef   signed int gzInt;

et ça vient d'où ça ? Si je ne me trompe, un processeur 64 bits traitera plus vite avec des entiers 64 bits qu'avec des entiers 32 bits (car les entiers 32 bits obligeront un masquage).

Seul les microcontrôleur d'un minimum de 32 bit sont supporté et plus bas que ça, ça n'aurais pas la puissance pour faire du graphique de toute manière. Sinon le Int est toujours 32 bit à ma connaissance, dans le cas contraire je peu le modifier.

Pour mes types on à le choix de spécifier la dimension, gzInt8/gzInt16/gzInt32/gzInt64 ou d'utilisé la dimension libre au compilateur de choisir la plus rapide (d'un minimum de 32bit)

Ensuite, le short vs int n'est pas exactement pareille qu'un int vs long long. N'aller pas croire que je n'ai pas tester, je croyais aussi au départ qu'un int64 sur une machine 64bit serait plus rapide. Mais il y à autre chose à prendre en considération, il ne faut la oublier les instruction SSE2 qui sont supporter automatiquement sur un système 64bit.
Si on prend 2 addition 32bit de suite, le compilateur peu les transformer en 1 instruction contrairement à des additions 64bit.

Lynix a écrit:

-Pourquoi utiliser une relique telle que wchar_t ? L'encodage varie d'un compilateur à l'autre, certains compilateurs peinent à le supporter (certaines distributions de MinGW notamment) et ça ne sert honnêtement à rien, autant passer par une vraie solution portable: l'Unicode (l'UTF-8 est ton ami).

Je crois être parfaitement Unicode, je ne voie pas ce que tu veux dire, wchar_t est nécessaire dans certain cas surtout pour écrire des "String Littéral" sur 16bit : L"16bit"

Lynix a écrit:

-Pourquoi écrire des valeurs en durs dans le code plutôt qu'utiliser le header standard (même en C++03) <limits> ? (Je pense à GZ_nMaxFloat32 par exemple).

Premièrement je n'optimise pas seulement l'exécution mais aussi la rapidité de compilation, jene mets que ce qui est nécessaire. De plus limit.h n'est pas nécessairment existant sur tout les compilateur et leurs valeur peuvent différer.

Lynix a écrit:

-Ensuite, pour ta façon de programmer en C++, si je prends un fichier au hasard, disons Queue.cpp, pourquoi est-ce que j'ai l'impression de lire du C ?

Bon ma façon de programmer n'est sans doute pas parfaite pour plusieurs raison:

-Il est presque impossible en C++ de faire un code flexible, portable, performant et jolie à utilisé

Si j'ai le choix je préfère la ce qui est flexible, portable, performant plutôt qu'un code jolie et cette raison s’explique aussi par mon prochain point

-Ce projet est la première partie d'un plus gros projet, si on regarde le code dans GZE/GFX, tous c'est fichier on été générer par mon projet en parallèle qui est de créer un langage de programmation.

GZE est la base du langage qui est quand même fonctionnel, je vais ensuite créer un IDE qui inclura le C++ facilement compilable sur toute plateforme et ensuite j'y ajouterai le langage en question.

Bon je ne m'attarderais pas trop la dessus au risque de m'égarer du sujet principal qui est GZE.

Donc Queue.cpp est effectivement du C car je trouve que ça fait partie d'un type vraiment de base tout comme les array dynamique et les strings que l'on peut considérer comme des exceptions. Cela joue beaucoup sur ma façon d'écrire les fonctions et comment ils vont être appelé et comme on peu le remarqué j'utilise énormément de préfix, surtout pour l'autocomplétion et les collisions de noms.

-
Edité par Maeiky 29 janvier 2015 à 19:07:44

Maeiky a écrit:

La plus grosse optimisation sera de batcher le plus possible de choses, mais c'est un vrai casse-tête avec OpenGL ES2 avec les textures. Ensuite sur desktop je vais utilisé les bindless texture avec probablement du indirect. 

Que veux-tu dire par branching?

Ce qu'il faut batcher en priorité ce sont surtout les shaders, ensuite les textures et les buffers, les bindless textures et l'indirect rendering ne te sauveront pas si le reste n'est pas bien optimisé.

Quant au branching, il s'agit concrètement d'un jump conditionnel (un if si tu veux), les CPU sont très bons pour gérer ça, et les GPUs sont très, très mauvais (une mauvaise condition dans un mauvais shader peut plomber les performances de façon monstrueuse).

Maeiky a écrit:

Ah oui, mon algo CPU est très optimisé, j'y ai passé beaucoup de temps et même trop, probablement plus de 6 mois que sur ce bout de code. Tu as raison le CPU n'est pas bon pour le parallèle, c'est pour ça que j'ai implémenté le GPU avec les même appels, donc on peut passer directement d'un rendu CPU à GPU et même combiné les 2. 

Les mêmes appels, tu parles du même algorithme ? Parce qu'on en revient à ce que je te disais "Le GPU doit être traité très différemment du CPU".

Quant à combiner le rendu CPU et GPU, là ça me semble être une feature un peu inutile...

Maeiky a écrit:

Seul les microcontrôleur d'un minimum de 32 bit sont supporté et plus bas que ça, ça n'aurais pas la puissance pour faire du graphique de toute manière. Sinon le Int est toujours 32 bit à ma connaissance, dans le cas contraire je peu le modifier. 

Passons sur le fait que rien n'empêcherait certains CPU 16 bits de foutre une branlée à certains CPU 32/64 bits, le int n'est pas toujours de 32 bits, la norme spécifie qu'il fait au moins 16 bits, c'est tout.

Maeiky a écrit:

Ensuite, le short vs int n'est pas exactement pareille qu'un int vs long long. N'aller pas croire que je n'ai pas tester, je croyais aussi au départ qu'un int64 sur une machine 64bit serait plus rapide. Mais il y à autre chose à prendre en considération, il ne faut la oublier les instruction SSE2 qui sont supporter automatiquement sur un système 64bit. 

Si on prend 2 addition 32bit de suite, le compilateur peu les transformer en 1 instruction contrairement à des additions 64bit.

Il est vrai, mais le SIMD à base d'entiers est extrêmement rare dans un moteur de jeu, ça se voit beaucoup plus au niveau des flottants par exemple.

Maeiky a écrit:

Je crois être parfaitement Unicode, je ne voie pas ce que tu veux dire, wchar_t est nécessaire dans certain cas surtout pour écrire des "String Littéral" sur 16bit : L"16bit"

wchar_t n'a rien à voir avec l'Unicode, c'est une légende urbaine, rien de plus. L'encodage utilisé dépend entièrement du compilateur.

D'ailleurs même la norme recommande de ne pas utiliser wchar_t pour être portable.

Source 1

Source 2

Maeiky a écrit:

Premièrement je n'optimise pas seulement l'exécution mais aussi la rapidité de compilation, jene mets que ce qui est nécessaire. De plus limit.h n'est pas nécessairment existant sur tout les compilateur et leurs valeur peuvent différer. 

Bien sûr que les valeurs vont différer, c'est le but de ce header: pouvoir les récupérer.

<limits> est un header standard dans la norme C++03 (celle que tu sembles utiliser), il est donc disponible partout (sauf si le compilateur ne supporte pas la norme mais en 2015 ce serait triste.).

Quant à la vitesse de compilation, si tu me parlais de Boost je comprendrais, mais là on parle de la bibliothèque standard, c'est pas ça qui va faire passer ton temps de compilation de quelques dizaines de secondes à quelques minutes hein.

Maeiky a écrit:

-Il est presque impossible en C++ de faire un code flexible, portable, performant et jolie à utilisé

Ah ? Je dois être un surhomme alors, parce que j'y arrive.

Maeiky a écrit:

-Ce projet est la première partie d'un plus gros projet, si on regarde le code dans GZE/GFX, tous c'est fichier on été générer par mon projet en parallèle qui est de créer un langage de programmation.

Est-ce que ça te donne une excuse pour mal utiliser ceux qui existent déjà ?

Maeiky a écrit:

Donc Queue.cpp est effectivement du C car je trouve que ça fait partie d'un type vraiment de base tout comme les array dynamique et les strings que l'on peut considérer comme des exceptions. Cela joue beaucoup sur ma façon d'écrire les fonctions et comment ils vont être appelé et comme on peu le remarqué j'utilise énormément de préfix, surtout pour l'autocomplétion et les collisions de noms.

Ben, les écrire en C++ (surtout que là ils passent par le compilateur C++) aurait été plus aisé, plus uniforme vis à vis du reste du code, tu pourrais même utiliser le RAII.

Quant aux préfixes, je sais que j'ai pas de leçon à donner là-dessus mais ils ne facilitent pas l'autocomplétition et les namespaces évitent tout autant les collisions de noms (je ne te suggère pas d'utiliser les namespaces au lieu des préfixes, je dis juste que ce ne sont pas de bonnes raisons de les utiliser).

Et puis bon, des casts à la C, des void* un peu partout, des fonctions au lieu de méthodes, je suis désolé mais c'est juste moche sans être plus performant qu'un code équivalent fait en C++, et lisible.

 Lynix a écrit:

Ce qu'il faut batcher en priorité ce sont surtout les shaders, ensuite les textures et les buffers, les bindless textures et l'indirect rendering ne te sauveront pas si le reste n'est pas bien optimisé.

Je fais tout en 1 seul shader, avec des "if" sur des variable uniform qui me semble acceptable, sinon j'ai pas de condition dans mon fragment shader. Après ce qui ralentie, c'est surtout le transfère de valeur au GPU et le nombre de drawcall qui est en conséquence du nombre de texture combiné et de l'ordre d’affichage.
 

Lynix a écrit:

Quant à combiner le rendu CPU et GPU, là ça me semble être une feature un peu inutile...

....
Juste un  exemple comme ça tu veux testé si la position de la sourie arrive sur un pixel non transparent, tu garde en mémoire ton image coté CPU et GPU, puis tu teste le pixel une fois transformé à la position indiqué.

Tout ça sans parler d'une portabilité sans avoir à changer une seul ligne de code

Lynix a écrit:

Passons sur le fait que rien n'empêcherait certains CPU 16 bits de foutre une branlée à certains CPU 32/64 bits, le int n'est pas toujours de 32 bits, la norme spécifie qu'il fait au moins 16 bits, c'est tout.

J'ai bel et bien entendu quelques rumeur de l’existence de microcontrôleur 16 bit. Mais trop de chose serait incompatible, un moment il faut que j'impose des limite sinon je finirais pu, c'est déjà extraordinaire de supporter un microcontrôleur 32bit.

Lynix a écrit:

wchar_t n'a rien à voir avec l'Unicode, c'est une légende urbaine, rien de plus. L'encodage utilisé dépend entièrement du compilateur.

D'ailleurs même la norme recommande de ne pas utiliser wchar_t pour être portable.

Source 1

Source 2

 Non seulement Windows est remplie de fonction wchar_t qui commence tous par w, mais j'utilise wchar_t surtout pour les string literal, quand on écris par exemple  L"ʡʢʤʥ"

Si tu lis ce que retourne le compilateur tu te rendrais compte que celui-ci considère ceci comme un wchar_t

Je me moque pas mal du wchar_t, en principe ça peu être un short, j'utilise seulement wchar pour être compatible avec le fait d'écrire une string litéral avec L"", on peu aussi faire du 32 bit avec U"". Tout ça pour faire plus beau car je pourrais écrire les caractères un à un.

Si tu fait L"Test" sous Winows et que t'arrive sous linux la même chose L"Test", tout ton code ne fonctionnera plus car par défaut la string litéral de linux est en 32bit, ce qui prend inutilement de l'espace. Après s'être rendu compte de leur boulette ils ont fait un flag pour le rendre sur 16bit : -fshort-wchar
C'est la seul façon d'être réellement portable avec les string littéral.

Ce que tu utilise ce n'est pas du Unicode, mais simplement les caractère étendu inférieur à 256.

Lynix a écrit:

<limits> est un header standard dans la norme C++03 (celle que tu sembles utiliser), il est donc disponible partout (sauf si le compilateur ne supporte pas la norme mais en 2015 ce serait triste.).

Je n'inclue que ce qui est nécessaire, et je préfère être certains de la disponibilité de ces valeurs, surtout si je spécifie une limite aux point flottant, d’ailleurs ce n'est pas disponible sur ARM. Quand on fait de la portabilité on apprend à ne pas faire confiance aveuglément. Ce n'est peut-être qu'un fichier, mais si tout les autres l'inclue c'est du traitement inutile à la compilation.

Lynix a écrit:

Maeiky a écrit:

-Il est presque impossible en C++ de faire un code flexible, portable, performant et jolie à utilisé

Ah ? Je dois être un surhomme alors, parce que j'y arrive.

Ton moteur est très bien, mais je n'ai pas la même définition de flexibilité (sans parler de portabilité). Pour ma part je tente de me rapproché le plus possible des langage comme Java, car je crée un langage du même genre. La flexibilité c'est une bonne gestion de la mémoire peu importe l'endroit sans être prisonnier du scope ou d'avoir des conteneurs en dur qui vont exécuté des opérations inutilement.

Lynix a écrit:

Est-ce que ça te donne une excuse pour mal utiliser ceux qui existent déjà ?

Le C++ est moche peut importe comment il est écris, il n'y a pas de vrai standard et tu ne trouvera pas 2 code semblable. Puisque j'invente un langage qui corrige tous ça, je me priorise sur les performances.

Lynix a écrit:

Ben, les écrire en C++ (surtout que là ils passent par le compilateur C++) aurait été plus aisé, plus uniforme vis à vis du reste du code, tu pourrais même utiliser le RAII.

C'est du C++ ... façon C. Mais je ne voie aucun avantage d'en faire une classe, c'est comme une fonction spécifique à la lib. La RAII est un peu incompatible avec la philosophie Java.

Lynix a écrit:

Quant aux préfixes, je sais que j'ai pas de leçon à donner là-dessus mais ils ne facilitent pas l'autocomplétition

C'est tout le contraire et ça va être la vrai force de mon langage, par exemple si tu tape "n" ça te liste les variable de nombre, si tu tape "f" ça te liste les fonctions, si tu tappe "o" ça te liste les objet, etc, etc. Chaque petite chose à son préfixe, ça accélère et facilite grandement la programmation.

Lynix a écrit:

les namespaces évitent tout autant les collisions de noms (je ne te suggère pas d'utiliser les namespaces au lieu des préfixes, je dis juste que ce ne sont pas de bonnes raisons de les utiliser).

J'ai logement hésité à utilisé les namespace, mais j'en ai conclue qu'ils sont à évité car le fait d'avoir le "::" ne permet plus d'avoir d'utilisé les "define" et les marco, qui sont bien plus performant que des constante statique et me forcerais à avoir 2 écritures différente pour mes fonctions et variables constante.

En gros pourquoi je n' utilise pas les namespaces :

-Oblige à utilisé les "::" qui sont incompatible avec les instructions préprocesseur
-Pas d'optimisation possible des variable "static const" , du moins sur la plupart des compilateur et agi comme une variable global.
-Impossible de faire des fonction générique ou hyper optimisé en macro sans avoir une écriture différente  (encore les "::")
-Source de nombreuses erreurs si deux lib utilise simultanément "using namspace" et qu' une classe ou autre ont le même nom, et c'est encore pire si cela arrive après un update d'une des lib.

Lynix a écrit:

Et puis bon, des casts à la C, des void* un peu partout, des fonctions au lieu de méthodes, je suis désolé mais c'est juste moche sans être plus performant qu'un code équivalent fait en C++, et lisible.

Vraiment :

MyClass*m =(MyClass*)ptr;

MyClass*m =static_cast<MyClass*>(ptr);

Maeiky a écrit:

Je fais tout en 1 seul shader, avec des "if" sur des variable uniform qui me semble acceptable, sinon j'ai pas de condition dans mon fragment shader. Après ce qui ralentie, c'est surtout le transfère de valeur au GPU et le nombre de drawcall qui est en conséquence du nombre de texture combiné et de l'ordre d’affichage.

Je n'ose imaginer le nombre de conditions, si tu fais ça en un seul shader. Ce qui ralentit ce ne sont pas les drawcall (et encore moins les uniformes), ce sont les changements d'états du GPU.

Maeiky a écrit:.... 

Juste un  exemple comme ça tu veux testé si la position de la sourie arrive sur un pixel non transparent, tu garde en mémoire ton image coté CPU et GPU, puis tu teste le pixel une fois transformé à la position indiqué.

Tout ça sans parler d'une portabilité sans avoir à changer une seul ligne de code

Si je veux faire ça j'utiliserais une représentation différente sur le CPU, plus efficace (quelques transformations matricielles et un masque) et portable (aucun code spécifique n'entrant en ligne de compte, juste des calculs mathématiques).

Maeiky a écrit:

 J'ai bel et bien entendu quelques rumeur de l’existence de microcontrôleur 16 bit. Mais trop de chose serait incompatible, un moment il faut que j'impose des limite sinon je finirais pu, c'est déjà extraordinaire de supporter un microcontrôleur 32bit.

Des rumeurs ? Moi je travaille avec

Mais oui soyons clairs, ça n'a pas grand intérêt de les supporter, et c'est vrai que supporter les micro contrôleurs 32 bits est assez inédit..

Mais ce que je voulais dire c'est qu'un code bien conçu respecte la norme, et donc peut être porté sur du 16/32/64 bits très facilement, justement parce qu'il ne fait pas d'assertions sur la plateforme.

Maeiky a écrit:

Non seulement Windows est remplie de fonction wchar_t qui commence tous par w, mais j'utilise wchar_t surtout pour les string literal, quand on écris par exemple  L"ʡʢʤʥ"

Si tu lis ce que retourne le compilateur tu te rendrais compte que celui-ci considère ceci comme un wchar_t

Je me moque pas mal du wchar_t, en principe ça peu être un short, j'utilise seulement wchar pour être compatible avec le fait d'écrire une string litéral avec L"", on peu aussi faire du 32 bit avec U"". Tout ça pour faire plus beau car je pourrais écrire les caractères un à un.

Si tu fait L"Test" sous Winows et que t'arrive sous linux la même chose L"Test", tout ton code ne fonctionnera plus car par défaut la string litéral de linux est en 32bit, ce qui prend inutilement de l'espace. Après s'être rendu compte de leur boulette ils ont fait un flag pour le rendre sur 16bit : -fshort-wchar
C'est la seul façon d'être réellement portable avec les string littéral.

Désolé mais ce que tu dis là c'est juste du grand n'importe quoi.

Windows est remplit de fonctions utilisant des wchar_t ? C'est normal, ils se fichent pas mal d'être portables, les wchar_t sont définis sous Windows, tout comme leur encodage (UTF-16), mais c'est toi qui veut être portable, alors il faut supporter les autres plateformes (et surtout les autres compilateurs ...).

"Leur boulette", je rêve là, sous Linux les wchar_t sont clairements définis comme étant de l'UCS-4, la vraie boulette c'est d'utiliser le flag -fshort-wchar, ou d'utiliser wchar_t tout court (qui n'a aucune vocation portable).

Les wchar_t je les utilise également, mais comme détail d'implémentation pour communiquer avec l'OS, c'est leur seul intérêt.

Oh et quid de l'encodage de ton fichier ? Parce que ça fout un peu tout en l'air (soit tu es obligé d'écrire ton Unicode sous la forme de nombres pour ne pas dépendre de l'encodage de ton fichier, soit tu précises un encodage pour chaque fichier, l'UTF-8 est un bon candidat).

Maeiky a écrit:

 Ce que tu utilise ce n'est pas du Unicode, mais simplement les caractère étendu inférieur à 256.

Ce que j'utilise est de l'UTF-8, difficile d'être plus Unicode que ça ...

Maeiky a écrit:

 Je n'inclue que ce qui est nécessaire, et je préfère être certains de la disponibilité de ces valeurs, surtout si je spécifie une limite aux point flottant, d’ailleurs ce n'est pas disponible sur ARM. Quand on fait de la portabilité on apprend à ne pas faire confiance aveuglément. Ce n'est peut-être qu'un fichier, mais si tout les autres l'inclue c'est du traitement inutile à la compilation.

Moi je n'ai pas de souci avec ce header sur ARM. Après si certaines plateformes ne respectent pas la norme, je pense que les supporter sera plus problématique qu'autre chose.

Quant au traitement inutile à la compilation, bah, si tu utilises les valeurs de ce header, ce n'est plus "inutile" justement.

Maeiky a écrit:

Ton moteur est très bien, mais je n'ai pas la même définition de flexibilité (sans parler de portabilité).

Niveau flexibilité, je te conseille de jeter un coup d'oeil à mes particules, c'est la définition même de la flexibilité (parce que concrètement, tu peux en faire absolument ce que tu veux). Et je pensais adopter l'Entity Component System, plus flexible que ça, à part du Lua, je vois pas.

Quant à la portabilité, certes, je n'ai absolument pas la vocation ni les connaissances pour faire tourner mon moteur sur un micro-contrôleur, mais néanmoins je compte le faire fonctionner (à long terme) sur un Raspberry Pi, sur Android et sur iOS (en plus de Linux/Mac OS X), je pense qu'on peut quand même parler de portabilité.

Maeiky a écrit:

Pour ma part je tente de me rapproché le plus possible des langage comme Java, car je crée un langage du même genre. La flexibilité c'est une bonne gestion de la mémoire peu importe l'endroit sans être prisonnier du scope ou d'avoir des conteneurs en dur qui vont exécuté des opérations inutilement. 

 Java tourne en machine virtuelle, ce qui fait qu'il est en effet très portable (passons sur le fait que la machine virtuelle soit elle-même en C) mais également pas du tout adapté aux applications temps-réel qui ne doivent subir absolument aucun overhead.

 Quant à ta définition de flexibilité, je suis presque sûr que tu te trompes de mot, mais là je vais avoir besoin d'exemples pour voir ce dont tu parles (et de quelles opérations inutiles tu parles).

Maeiky a écrit:

 Le C++ est moche peut importe comment il est écris, il n'y a pas de vrai standard et tu ne trouvera pas 2 code semblable. Puisque j'invente un langage qui corrige tous ça, je me priorise sur les performances.

Le C++ est multi-paradigme, c'est sa force (et également une faiblesse pour les débutants). Il y a un vrai standard (sinon nous n'aurions pas de norme), tout ce qu'on peut lui reprocher c'est d'être moins bien fourni que d'autres bibliothèques standards (comme celle de Java).

Pour combler à ça, de nombreuses personnes utilisent Boost, qui peut être vu comme une bibliothèque presque standard, mais l'utiliser est un choix qu'il faut assumer.

Pour le coup du "j'invente un langage qui corrige tout ça" et qui sera donc "plus performant que le C++", je pense juste qu'il est impossible de te raisonner, et que ce que j'ai à dire sur le sujet a déjà été dit.

Maeiky a écrit:

C'est du C++ ... façon C.

Ce n'est donc pas du C++ si ton code tiens plus du C que du C++ (et ce même s'il a besoin d'être compilé en C++).

Maeiky a écrit:

La RAII est un peu incompatible avec la philosophie Java.

Qu'est-ce que le Java vient foutre dans l'histoire ?

Maeiky a écrit:

C'est tout le contraire et ça va être la vrai force de mon langage, par exemple si tu tape "n" ça te liste les variable de nombre, si tu tape "f" ça te liste les fonctions, si tu tappe "o" ça te liste les objet, etc, etc. Chaque petite chose à son préfixe, ça accélère et facilite grandement la programmation.

... La vraie force de ton langage sera l'auto complétion par un IDE ? 

Maeiky a écrit:

J'ai logement hésité à utilisé les namespace, mais j'en ai conclue qu'ils sont à évité car le fait d'avoir le "::" ne permet plus d'avoir d'utilisé les "define" et les marco, qui sont bien plus performant que des constante statique et me forcerais à avoir 2 écritures différente pour mes fonctions et variables constante.

Non seulement les constantes et fonctions inlines sont tout aussi performantes que les #define et macro, mais elles sont aussi beaucoup plus sûres ...

Maeiky a écrit:

-Oblige à utilisé les "::" qui sont incompatible avec les instructions préprocesseur

-Pas d'optimisation possible des variable "static const" , du moins sur la plupart des compilateur et agi comme une variable global.

Pardon ?

Maeiky a écrit:

-Source de nombreuses erreurs si deux lib utilise simultanément "using namspace" et qu' une classe ou autre ont le même nom, et c'est encore pire si cela arrive après un update d'une des lib.

Ben justement, pourquoi une lib utiliserait un using namespace ? Son rôle étant de tout caser dans un namespace.

Ensuite des collisions, ça arrive même avec des préfixes hein .. (Même beaucoup plus avec des préfixes, vu que ça inclut alors le C).

Maeiky a écrit:

Vraiment :

MyClass*m =(MyClass*)ptr;

MyClass*m =static_cast<MyClass*>(ptr);

Ben, oui ?

C'est plus lisible et plus sûr que le cast façon C (qui te permet de const_cast, reinterpret_cast ou static_cast en une forme), et tu fais moins d'erreurs.

Bon après si tu n'aimes pas la syntaxe là je n'y peux effectivement rien.

Bref, je préfère le rappeler, mes critiques ne sont pas des attaques, j'ai beaucoup de respect pour ta volonté et les connaissances que tu as dû acquérir sur tout ce temps, mais il y a certains points où il faut redescendre un peu sur Terre.

Ok, rien n'est coulé dans le béton.

Bon oublions le fais de faire du graphique CPU et GPU, ça fait trop de chose en même temps. (Mais les If sur Uniform sont optimisé à la compilation, comme si on nouveau Shader serait généré)

Je ne comprend pas comment tu fais ton UTF8, UTF8  ce n'est pas les caractères qui change en dimension tantôt 8bit tantôt 16bit? Ça doit avoir un impact sur les performance?

Pour la flexibilité en réalité ce que je veux faire c'est un comptage par référence avec des objet hors du scope. Pour l'instant la création et la réassignation est géré par mon langage qui génère le code automatiquement.

Le seul moyen de faire ça en C++  pour que ça respect la RAII serait que tout les objets aurait un conteneur où je pourrais appliqué une fonction à la réassignation par exemple, mais ça doit avoir un impact sur les performances?

Pour les cast, je peux le changer n'importe quand mais je trouve juste ça plus long à lire et ça alourdie le code.

Pour un #define Bob 4 vs static const int  SomeClass::Bob 4, le défine est bel et bien plus rapide,dans ma boucle graphique qui est très critique avec des define je peux gagner plus de 5% d'utilisation CPU et peut-être bien le double du framerate sur microcontrôleur.
Je ne sais pas si il y à une méthode pour faire des constante avec une fonction inline?

Pour les micro 16bit eh bien juste le fait que mes couleurs sont sous la forme 32 bit RGBA, ça change tout le principe.

-
Edité par Maeiky 30 janvier 2015 à 14:16:13

Maeiky a écrit:

Bon oublions le fais de faire du graphique CPU et GPU, ça fait trop de chose en même temps. (Mais les If sur Uniform sont optimisé à la compilation, comme si on nouveau Shader serait généré)

Source ? Je sais que certains drivers NVidia sont susceptibles de recompiler le shader à la volée lors de certains changement d'états, mais là tu me parles d'une optimisation sur un if sur une valeur inconnue. Autant utiliser les ÜberShader et le problème est réglé.

Maeiky a écrit:

Je ne comprend pas comment tu fais ton UTF8, UTF8  ce n'est pas les caractères qui change en dimension tantôt 8bit tantôt 16bit? Ça doit avoir un impact sur les performance?

Chaque caractère Unicode encodé en UTF-8 peut l'être sur un, deux, trois ou quatre octets, selon le caractère en question.

Quant à l'impact sur les performances, le seul petit souci c'est quand tu veux accéder au troisième caractère de ta chaîne, ça ne correspond plus alors forcément à str[2], il faut itérer depuis le début pour retrouver le début du caractère.

Est-ce que c'est un problème ? Pas vraiment, ce n'est pas quelque chose qu'on fait souvent (encore moins lors du rendu, on ne manipule pas de chaîne de caractère lors du rendu).

Maeiky a écrit:

Pour la flexibilité en réalité ce que je veux faire c'est un comptage par référence avec des objet hors du scope. Pour l'instant la création et la réassignation est géré par mon langage qui génère le code automatiquement.

Le seul moyen de faire ça en C++  pour que ça respect la RAII serait que tout les objets aurait un conteneur où je pourrais appliqué une fonction à la réassignation par exemple, mais ça doit avoir un impact sur les performances?

1) Pourquoi faire ça ?

2) "Un objet hors du scope" en C++, ça se résume au mot-clé static, qui étend le scope à tout le programme.

Maeiky a écrit:

Pour les cast, je peux le changer n'importe quand mais je trouve juste ça plus long à lire et ça alourdie le code.

Si tu parles du code généré, c'est exactement le même, pour le coup du "plus long à lire", au contraire, un static_cast est souvent d'une couleur différente dans l'affichage et se reconnaît du coup très rapidement (là où le cast, tu dois chercher plus longtemps pour le voir).

Après c'est quelques caractères en plus, mais les casts en général ça s'évite donc bon...

Maeiky a écrit:

Pour un #define Bob 4 vs static const int  SomeClass::Bob 4, le défine est bel et bien plus rapide,dans ma boucle graphique qui est très critique avec des define je peux gagner plus de 5% d'utilisation CPU et peut-être bien le double du framerate sur microcontrôleur. 

C'est normal, si tu rends ton entier statique alors il doit être accédé en lecture, plutôt que remplacé par le compilateur. Contrairement à:

const int a = 4;

Que tu peux même caser dans un namespace, qui est plus sûr (au moins tu es certain de ne rien remplacer par inadvertance), etc.

Maeiky a écrit:

Je ne sais pas si il y à une méthode pour faire des constante avec une fonction inline?

Faire des constantes avec une fonction inline ? Tu me parles de générer ta constante depuis une fonction inline (ou mieux, constexpr mais ça c'est du C++11) ? Ben, euh, oui.

Maeiky a écrit:

Pour les micro 16bit eh bien juste le fait que mes couleurs sont sous la forme 32 bit RGBA, ça change tout le principe.

Mon arduino (8bits) est capable de calculer des entiers 32 bits, pourquoi un micro contrôleur 16 bits n'en serait pas capable ?

-
Edité par Lynix 30 janvier 2015 à 14:47:01

Uniform vs multiple Sharder : http://stackoverflow.com/questions/6539774/glsl-multiple-shaderprogram-vs-uniforms-switches

Je ne comprend pas très bien le ÜberShader, sa définition est très vague, c'est quoi pour toi?

Lynix a écrit:

Chaque caractère Unicode encodé en UTF-8 peut l'être sur un, deux, trois ou quatre octets, selon le caractère en question.

Quant à l'impact sur les performances, le seul petit souci c'est quand tu veux accéder au troisième caractère de ta chaîne, ça ne correspond plus alors forcément à str[2], il faut itérer depuis le début pour retrouver le début du caractère.

Est-ce que c'est un problème ? Pas vraiment, ce n'est pas quelque chose qu'on fait souvent (encore moins lors du rendu, on ne manipule pas de chaîne de caractère lors du rendu).

Je crois que tu as compris que je ne fais pas un moteur que pour des jeux, mais aussi des application. Le UTF8 est n'est pas utile pour faire du traitement, c'est utile pour compressé un fichier, normalement on préfère une plus grande utilisation de mémoire pour une meilleurs rapidité d'exécution. Je me sert très souvent de accès par index, par exemple faire une recherche qui commence à un index précis. Sans parler d'un traitement spécial du UTF8 à chaque caractère pour connaitre sa dimension.

De plus le UTF8 ne règle pas le problème des sting litéral, si tu veu entré des lettres greque tu fais comment? On utilise la lettre L à la précompilation, c'est le compilateur qui l'intéreprete en wchar, la seul solution pour contourné ça c'est d'enté les caractère manuellement, un par un.

Lynix a écrit:

C'est normal, si tu rends ton entier statique alors il doit être accédé en lecture, plutôt que remplacé par le compilateur. Contrairement à:

const int a = 4;

Que tu peux même caser dans un namespace, qui est plus sûr (au moins tu es certain de ne rien remplacer par inadvertance), etc.

Maeiky a écrit:

Je ne sais pas si il y à une méthode pour faire des constante avec une fonction inline?

Faire des constantes avec une fonction inline ? Tu me parles de générer ta constante depuis une fonction inline (ou mieux, constexpr mais ça c'est du C++11) ? Ben, euh, oui.

Il me semble avoir testé avec static et sans, et le résultat avait aucune différence, tu as un exemple avec des contante inline?

Lynix a écrit:

Maeiky a écrit:

Pour les micro 16bit eh bien juste le fait que mes couleurs sont sous la forme 32 bit RGBA, ça change tout le principe.

Mon arduino (8bits) est capable de calculer des entiers 32 bits, pourquoi un micro contrôleur 16 bits n'en serait pas capable ?

Ok, l'idée n'est pas mauvaise, j'ai déjà un define pour le 64 bit, Sys64 et par défaut Sys32, il me suffit d'ajouté Sys16. Par contre c'est optimisé pour le 32bit, un micro de 16bit va prendre exactement 2 fois plus de temps pour les mêmes opérations.

Lynix a écrit:

1) Pourquoi faire ça ?

2) "Un objet hors du scope" en C++, ça se résume au mot-clé static, qui étend le scope à tout le programme.

Tu ne comprend mal mon idée, mon but est de tout créer en mémoire dynamique (heap) au lieu du Stack qui détruit l'objet à al fin du scope. Tout ça gérer par un comptage par référence, donc par exemple à la réassignation d'un objet au lieu du "=" puisque c'est un pointeur je dois appeler une fonction fSet , mais dans mon langage ça reste un "=". Pour pourvoir utilisé le = en C++ il faudrait un conteneur, mais je crois que c'est moins performant.

-
Edité par Maeiky 30 janvier 2015 à 17:02:59

Maeiky a écrit:

Uniform vs multiple Sharder : http://stackoverflow.com/questions/6539774/glsl-multiple-shaderprogram-vs-uniforms-switches

Je ne comprend pas très bien le ÜberShader, sa définition est très vague, c'est quoi pour toi?

http://stackoverflow.com/questions/4649801/organizing-glsl-shaders-in-opengl-engine?rq=1

Un ÜberShader dans Nazara est un ensemble de variations d'un même code source, j'ai dans l'idée trois façons de faire varier mes shaders, dont une seule est implémentée actuellement:

-Le préprocesseur, lors de la compilation d'une variation, le moteur va rajouter au code un bon nombre de #define pour effectuer du "branching statique", supporté partout, c'est la seule méthode actuellement employée. (Exemple de code source d'Über-Shader)

-Une variable uniformes, contenant des flags, pour faire varier au runtime certaines uniformes contrôlant le branching (utilisé en combinaison du préprocesseur qui reste majoritaire).

-Et la bonne façon de faire, les subroutines (du linkage dynamique), qui nécessite OpenGL 4, concrètement tu changes des pointeurs de fonctions dans le shader, utilisé en combinaison du préprocesseur et éventuellement des flags.

Mon architecture supporte déjà pleinement la possibilité de ces trois implémentations, il ne manque que les implémentations en question (on va dire que j'avais d'autres priorités).

Maeiky a écrit:

Je crois que tu as compris que je ne fais pas un moteur que pour des jeux, mais aussi des application. Le UTF8 est n'est pas utile pour faire du traitement, c'est utile pour compressé un fichier, normalement on préfère une plus grande utilisation de mémoire pour une meilleurs rapidité d'exécution. Je me sert très souvent de accès par index, par exemple faire une recherche qui commence à un index précis. Sans parler d'un traitement spécial du UTF8 à chaque caractère pour connaitre sa dimension.

Très souvent ? Mais encore ? Parce que le ralentissement dont je te parle ne va pas t'empêcher de faire des milliers de recherches par indices par seconde dans tes chaînes de caractères (et si tu as besoin de garder la position d'un caractère dans la chaîne, hé bien tu la stockes, c'est aussi simple que ça).

Tu sembles atteint du "mal des performances", tu vois des ralentissements partout, surtout là où il n'y en a pas vraiment. Tu penses que ça va faire une différence pour l'utilisateur de faire une recherche sur une chaîne en UTF-8 plutôt qu'en UTF-32 ? Ne sous-estime pas la vitesse des ordinateurs.

D'ailleurs tu penses qu'il n'y a que l'UTF-8 qui fait ça ? Erreur, l'UTF-16 (et donc les wchar_t sous Windows ?) peuvent avoir des "surrogate pair", pour stocker de l'Unicode sur deux caractères.

Bref, soit tu utilises de l'UTF-32 (rapidité de traitement, mais chaînes lourdes, lourdes, et incompatibles avec l'ASCII), soit tu utilises l'UTF-8 (qui a l'avantage d'être compatible avec l'ASCII, de ne pas causer de problème de boutisme, et d'être ultra répandu, la plupart des sites web que tu regardes sont en UTF-8, pareil pour les applications).

Maeiky a écrit:

De plus le UTF8 ne règle pas le problème des sting litéral, si tu veu entré des lettres greque tu fais comment? On utilise la lettre L à la précompilation, c'est le compilateur qui l'intéreprete en wchar, la seul solution pour contourné ça c'est d'enté les caractère manuellement, un par un.

 Les wchar_t non plus ne règlent pas ce problème, étant donné que l'encodage du fichier peut varier (je ne sais pas comment le compilateur s'arrange, probablement en détectant l'encodage, mais c'est généralement pas fiable).

Ou alors tu appliques ma solution (dont je t'ai parlé un peu plus haut): Encoder tes codes sources en UTF-8 (CodeBlocks permet de s'occuper de ça), et là tu peux entrer des symboles chinois, du grec, tout ce que tu veux en faisant ça:

"Je suis en UTF-8 héhéhé ♫"

Et ça fonctionnera sans autre traitement particulier (si ce n'est transformer en wchar_t pour communiquer avec Windows, Nunux utilisant déjà l'UTF-8 il me semble).

Maeiky a écrit:

Il me semble avoir testé avec static et sans, et le résultat avait aucune différence, tu as un exemple avec des contante inline?

 Tu ne peux pas "inline" une constante, mais si elle est définie en tant que tel (un entier constant par exemple) et que sa valeur est accessible, le compilateur fera le remplacement lui-même.

Maeiky a écrit:

Ok, l'idée n'est pas mauvaise, j'ai déjà un define pour le 64 bit, Sys64 et par défaut Sys32, il me suffit d'ajouté Sys16. Par contre c'est optimisé pour le 32bit, un micro de 16bit va prendre exactement 2 fois plus de temps pour les mêmes opérations.

 Attention que je ne t'ai jamais dit que ça valait la peine de les supporter, je m'en sers juste comme exemple pour te dire que ton code supporterait déjà tout ça nativement s'il ne faisait pas d'assertions sur la plateforme.

Maeiky a écrit:

Tu ne comprend mal mon idée, mon but est de tout créer en mémoire dynamique (heap) au lieu du Stack qui détruit l'objet à al fin du scope. Tout ça gérer par un comptage par référence, donc par exemple à la réassignation d'un objet au lieu du "=" puisque c'est un pointeur je dois appeler une fonction fSet , mais dans mon langage ça reste un "=". Pour pourvoir utilisé le = en C++ il faudrait un conteneur, mais je crois que c'est moins performant.

C'est complètement con, tu veux réinventer Java en C++ ? On peut tout à fait avoir un objet compteur de référence que tu peux assigner (lien), et c'est une grave erreur que de vouloir TOUT faire en mémoire dynamique, même Java n'a pas osé le faire.

Et arrête de croire que tout est moins performant sans raison, si le C++ est utilisé aussi massivement quand on a besoin de performances, c'est pas pour rien. Tu crois être le premier à avoir eu l'idée d'inventer un langage faisant mieux ce boulot que le C++ ? Il y en a qui sortent chaque année, et il semblerait que le C++ ait encore de très beaux jours devant lui (surtout depuis que le comité a décidé de se sortir les doigts du cul et de sortir le C++11).

Quel intérêt de tout avoir sur le tas ? Quel intérêt de virer le RAII qui est le symbole même de la bonne conception C++ ?

Il n'y a que quelques objets qui ont besoin de vivre en comptage par référence (pour reprendre mon moteur: les ressources en sont de bons exemples), les autres doivent avoir une fixe clairement définie, ainsi est le C++.

Edit: Je te confirme que les wchar_t peuvent avoir des surrogate pair (un caractère définit par deux wchar_t) et que donc il n'est pas fiable de les accéder par indice:

Source 1

Source 2 (Microsoft)

-
Edité par Lynix 31 janvier 2015 à 16:10:51

J'utilise déja le point 2 du Uber Shader, ensuite si ce n'est pas assez optimisé je peux toujours le splitter en plusieurs shaders.

Lynix a écrit:

Maeiky a écrit:

Je crois que tu as compris que je ne fais pas un moteur que pour des jeux, mais aussi des application. Le UTF8 est n'est pas utile pour faire du traitement, c'est utile pour compressé un fichier, normalement on préfère une plus grande utilisation de mémoire pour une meilleurs rapidité d'exécution. Je me sert très souvent de accès par index, par exemple faire une recherche qui commence à un index précis. Sans parler d'un traitement spécial du UTF8 à chaque caractère pour connaitre sa dimension.

Très souvent ? Mais encore ? Parce que le ralentissement dont je te parle ne va pas t'empêcher de faire des milliers de recherches par indices par seconde dans tes chaînes de caractères (et si tu as besoin de garder la position d'un caractère dans la chaîne, hé bien tu la stockes, c'est aussi simple que ça).

Le seul avantage étant une utilisation réduite en mémoire, si les compilateur utiliserait ce procéder on passerait d'un temps de compilation de 20 seconde à 20 minutes. Ceci-dit pour un moteur 3d ça va sans doute passer inaperçu.

Tu ma toujours pas dit comment tu fais pour mettre des caractères grecque dans une NzString

wchar_t ce n'est qu'une dimension exactement comme nzInt16 ou nzInt32 sur linux, si tu veux mettre de surrogate dedans c'est comme tu veux, seul l'interprétation change.

Lynix a écrit:

 Tu ne peux pas "inline" une constante, mais si elle est définie en tant que tel (un entier constant par exemple) et que sa valeur est accessible, le compilateur fera le remplacement lui-même.

Je t'accorde ce point, j'ai peut-être mal fait mon test en limitant la visibilité de mes constantes à l'époque. Du coup si c'est vrai ça me donne la possibilité de faire des namespaces.

Lynix a écrit:

Maeiky a écrit:

Tu ne comprend mal mon idée, mon but est de tout créer en mémoire dynamique (heap) au lieu du Stack qui détruit l'objet à al fin du scope. Tout ça gérer par un comptage par référence, donc par exemple à la réassignation d'un objet au lieu du "=" puisque c'est un pointeur je dois appeler une fonction fSet , mais dans mon langage ça reste un "=". Pour pourvoir utilisé le = en C++ il faudrait un conteneur, mais je crois que c'est moins performant.

C'est complètement con, tu veux réinventer Java en C++ ? On peut tout à fait avoir un objet compteur de référence que tu peux assigner (lien), et c'est une grave erreur que de vouloir TOUT faire en mémoire dynamique ...

Quel opinion complètement arrêter et même déplacé.
http://programmers.stackexchange.com/questions/118295/did-the-developers-of-java-consciously-abandon-raii
"Now looking at C# and its Java roots I am wondering... did the developers of Java fully appreciate what they were giving up when they abandoned the stack in favor of the heap"


Bon, j'ai noté plusieurs chose :

-Évité les fonctions C
-Faire des static const
-Enlever wchar ? Si possible...
-Compilation 16bit
-Utiliation de namespace
-Conteneur pour géré le comptage par référence et respecté la RAII (Si le compilateur l'optimise bien)

Je vais tenter de corriger ces points, merci encore de tes conseils

-
Edité par Maeiky 31 janvier 2015 à 19:32:03

Maeiky a écrit:

Le seul avantage étant une utilisation réduite en mémoire, si les compilateur utiliserait ce procéder on passerait d'un temps de compilation de 20 seconde à 20 minutes. Ceci-dit pour un moteur 3d ça va sans doute passer inaperçu.

C'est n'importe quoi, le compilateur va d'abord tokeniser le fichier, ce qui nécessite d'itérer sur chaque caractère, ce qui n'est pas vraiment plus lent en UTF-8 qu'en UTF-16 ...

... D'ailleurs mes fichiers sont en UTF-8, le compilateur passe par là ...

Maeiky a écrit:

Tu ma toujours pas dit comment tu fais pour mettre des caractères grecque dans une NzString

Je te l'ai dit deux fois déjà (bon c'est du russe mais c'est le même principe):

NzString str("Картофель фри");

Petit exemple:

NzString windowTitle = "Картофель фри";
window.SetTitle(windowTitle);

// Ou encore:
window.SetTitle("Картофель фри");

Résultat.

Tout ça grâce à la magie de l'UTF-8.

Maeiky a écrit:

wchar_t ce n'est qu'une dimension exactement comme nzInt16 ou nzInt32 sur linux, si tu veux mettre de surrogate dedans c'est comme tu veux, seul l'interprétation change.

Ce que tu n'as pas compris c'est que ce n'est pas toi qui va mettre les surrogate pair, mais le compilateur avec certains caractères qui ne rentrent pas dans un seul wchar_t.

Autrement dit, ce que tu reproches à l'UTF-8 (d'avoir une taille variable), tu l'as aussi avec les wchar_t, tu y es juste moins confronté parce que l'UTF-16 code la plupart de nos caractères en un wchar_t sous Windows, mais essaie avec d'autres caractères et tu auras une surprise.

Maeiky a écrit:

Quel opinion complètement arrêter et même déplacé.

Dixit celui qui s'invente des problèmes de performance.

Maeiky a écrit:

http://programmers.stackexchange.com/questions/118295/did-the-developers-of-java-consciously-abandon-raii
"Now looking at C# and its Java roots I am wondering... did the developers of Java fully appreciate what they were giving up when they abandoned the stack in favor of the heap"

Et la réponse de cette question est "très probablement que le créateur du langage n'avait pas compris le RAII et la destruction déterministe à l'époque de la conception du langage"...

Maeiky a écrit:

-Évité les fonctions C

Éviter de programmer "à la C", si tu utilises memcpy personne ne t'en voudra.

Maeiky a écrit:

-Enlever wchar ? Si possible...

Ce que tu reproches à l'UTF-8, tu l'as avec tes wchar_t, mais ce que je reproche aux wchar_t, tu ne l'as pas avec l'UTF-8.

Donc bon.

Maeiky a écrit:

-Conteneur pour géré le comptage par référence et respecté la RAII (Si le compilateur l'optimise bien)

Arrête de croire que les bonnes pratiques en C++ vont faire ralentir ton programme, par pitié, à chaque fois que tu cherches un coupable pour la perte de performances tu te trompes d'adversaire.

C'est le fait de tout avoir sur le tas qui va plomber tes performances par exemple, l'allocation sur le tas n'est pas gratuite (celle sur la pile, si), sans parler des risques de leaks (références cycliques).

Et désolé si ça te choque mais oui, faire du C++ en rejetant le RAII, qui est un élément-clé du langage, c'est complètement con.

Pour L'UTF8 je suis à la limite d'accord (je vais creuser le sujet), mais ça ne battra jamais des chaines sous 32bits ..

Mais en réalité le compilateur mets le fichier en mémoire et puis fait des traitement dessus, un peu comme décompresser une image.

Lynix a écrit:

Maeiky a écrit:

http://programmers.stackexchange.com/questions/118295/did-the-developers-of-java-consciously-abandon-raii
"Now looking at C# and its Java roots I am wondering... did the developers of Java fully appreciate what they were giving up when they abandoned the stack in favor of the heap"

Et la réponse de cette question est "très probablement que le créateur du langage n'avait pas compris le RAII et la destruction déterministe à l'époque de la conception du langage"...

Ça n'a pas empêcher de faire des langages très performants comme Java ou AS3 (Flash) en faisant tout en heap, ce qui permet à l'utilisateur de ne pas avoir à se préoccupé de la mémoire et rendre le tout universel.

Lynix a écrit:

C'est le fait de tout avoir sur le tas qui va plomber tes performances par exemple, l'allocation sur le tas n'est pas gratuite (celle sur la pile, si), sans parler des risques de leaks (références cycliques).

Avec un petit memory pool, on arrive aux même performances sinon meilleurs. Et puis ce n'est pas pour rien que Java et autre utilise des garbages collectors.

Et puis rien n'empêche de faire un petit mélange des 2, si je détecte que la porté d'une classe reste ciblé à la porté du scope, je peux la créer en stack automatiquement.

Je peux comprendre que tu n'aime pas l'idée, mais ça ne sert à rien d'essayé de caler les autres projets.

-
Edité par Maeiky 1 février 2015 à 0:27:48

Maeiky a écrit:

Pour L'UTF8 je suis à la limite d'accord (je vais creuser le sujet), mais ça ne battra jamais des chaines sous 32bits ..

Et c'est toi qui me parlait d'opinions arrêtées ?

UTF-8 vs UTF-16 vs UTF-32

Difference between UTF-8 and UTF-16

Encore une fois, les opérations sur les chaînes sont loin d'être ce qui prend le plus de temps dans un moteur, même si les chaînes sont en UTF-8.

Maeiky a écrit:

Mais en réalité le compilateur mets le fichier en mémoire et puis fait des traitement dessus, un peu comme décompresser une image.

Il les représente différemment, il les tokénise, oui... (qui prendra moins de place en mémoire que des chaînes).
Tiens d'ailleurs, il aurait plus de mal avec de l'UTF-32 qu'avec de l'UTF-8 (compatible ASCII). 

Ou alors tu m'expliques comment on décompresse un fichier texte.

Le compilateur travaille très peu avec les chaînes de caractères, vu qu'il y a très peu de chaînes de caractères dans ce qu'il fait, une fois le code transformé en tokens (ce qui ne prend même pas 10% du temps de compilation).

Maeiky a écrit:

Ça n'a pas empêcher de faire des langages très performants comme Java ou AS3 (Flash) en faisant tout en heap, ce qui permet à l'utilisateur de ne pas avoir à se préoccupé de la mémoire et rendre le tout universel.

Java et Flash très performants ?

Maeiky a écrit:

Avec un petit memory pool, on arrive aux même performances sinon meilleurs. Et puis ce n'est pas pour rien que Java et autre utilise des garbages collectors.

"un petit memory pool", oui sauf qu'un memory pool t'oblige à avoir des types de taille identique, donc plusieurs memory pool, donc un algorithme plus compliqué, donc des perfs en nette baisse, c'est pas magique les pools hein.

Concrètement tu crois que l'OS il gère sa mémoire comment ?..

Quant au garbage collector, il est présent pour que le programmeur n'ait pas à se soucier de la mémoire, pas parce que c'est plus performant, bien au contraire (le GC est un gros handicap pour le temps réel par exemple).

Maeiky a écrit:

Et puis rien n'empêche de faire un petit mélange des 2, si je détecte que la porté d'une classe reste ciblé à la porté du scope, je peux la créer en stack automatiquement.

J'ai encore une meilleure idée, plutôt que d'essayer de détecter ça, tu laisses le programmeur le spécifier, et choisir ce qu'il alloue sur le tas.

Ah tiens, c'est exactement comme ça que fonctionne le C++, et ça marche plutôt bien tu ne trouves pas ? Pourquoi vouloir réinventer la roue façon carrée ?

Maeiky a écrit:

Je peux comprendre que tu n'aime pas l'idée, mais ça ne sert à rien d'essayé de calerles autres projets.

Honnêtement je n'essaie pas de "caler" ton projet, loin de là, juste de te faire réfléchir dessus, tu avancerais nettement plus vite en te concentrant sur les points essentiels, plutôt qu'en essayant de défendre la programmation Java dans un environnement C++ par exemple, ou en cherchant à réinventer ton propre langage.

Attention hein, je trouve que c'est une prouesse et ça t'a apporté des connaissances monstres j'en suis sûr, mais ce serait triste de perdre ton temps à inventer des choses qui existent déjà, et qui ont déjà prouvé leur efficacité, alors que tu pourrais améliorer ton moteur, améliorer ses performances, le rendre utilisable pour des jeux ou applications diverses.

C'est quelque chose que j'ai appris sur le long terme dans le développement de mon moteur, je me suis concentré trop longtemps sur des choses qui ne me serviront absolument pas (par exemple les hashs MD5/SHA-X/Whirlpool), si j'avais consacré plus de temps à l'essentiel, j'aurais probablement déjà sorti un jeu avec le moteur, qui serait plus avancé vers l'objectif que je me suis fixé.

-
Edité par Lynix 1 février 2015 à 0:53:22

Lynix a écrit:

Maeiky a écrit:

Pour L'UTF8 je suis à la limite d'accord (je vais creuser le sujet), mais ça ne battra jamais des chaines sous 32bits ..

Et c'est toi qui me parlait d'opinions arrêtées ?

Quand je dis que je suis à la limite d'accord et je vais creuser le sujet, c'est que je garde l'esprit ouvert et peut-être même que je vais me convertir à l'UTF8, ça demande un peu de réflexion. Il est vrai qu'une fois en token ça ne change plus rien, mais il faut garder à l'esprit qu'il y a beaucoup de recherche et de manipulation de caractères avant d'en arrivé là.

Et ton site dit justement que l'UTF32 est rapide/simple :
"UTF32 is opposite, it uses the most memory (each character is a fixed 4 bytes wide), but on the other hand, you know that every character has this precise length, so string manipulation becomes far simpler. You can compute the number of characters in a string simply from the length in bytes of the string. You can't do that with UTF8."

Lynix a écrit:

"un petit memory pool", oui sauf qu'un memory pool t'oblige à avoir des types de taille identique, donc plusieurs memory pool, donc un algorithme plus compliqué, donc des perfs en nette baisse, c'est pas magique les pools hein.

Un memory pool n'est pas si compliqué, tu as un tableau d'un longueur fixe, chacun de ses index contient une liste. Par exemple l'index 1 contient des élément de taille 1 qui peut contenir beaucoup d'éléments et plus les index augmentes avec des élément de plus grosse taille et moins il en contient sous forme de droite. L'accès est très rapide. Les éléments de très grande taille auront évidement un appel à malloc/new mais ce sera de rare cas.

Lynix a écrit:

Quant au garbage collector, il est présent pour que le programmeur n'ait pas à se soucier de la mémoire, pas parce que c'est plus performant, bien au contraire (le GC est un gros handicap pour le temps réel par exemple).

Je crois que je peux évité les garbages collector en détectant les références cycliques et en obligeant de spécifier si c'est un pointeur "Weak" ou de comptage par référence.

Lynix a écrit:

J'ai encore une meilleure idée, plutôt que d'essayer de détecter ça, tu laisses le programmeur le spécifier, et choisir ce qu'il alloue sur le tas.

Ah tiens, c'est exactement comme ça que fonctionne le C++, et ça marche plutôt bien tu ne trouves pas ? Pourquoi vouloir réinventer la roue façon carrée ?

J'ai fais beaucoup de jeux vidéo auparavant et j'ai toujours fonctionner d'une certaine façon et je ne vois pas comment je pourrait faire autrement.

Selon ce principe tout est créer en heap, je ne vois pas comment ça pourrait fonctionné de façon stack.

Voici le principe :

Tout objets peut contenir plusieurs autre objets. Il y a donc un parent qui contient des enfant et ainsi de suite. Les enfants peuvent changé de parent.
On retrouve ce principe avec Flash (AS3), on a des MovieClips et tout les sous MovieClips qu'il contient sont affecté par les transformation des parents (rotation/scale/position)

Ce principe compose peut-être 90% du moteur et de la création d'un jeu. Je ne vois même pas de cas où il y a de la création en stack. C'est flexible et très utilisé en jeux vidéo.

À moins que tu aie une solution miracle, je ne voie pas d'autre moyen.

-
Edité par Maeiky 1 février 2015 à 4:58:22

Évidemment que la gestion de l'UTF-32 est plus rapide, mais comme je ne cesse de te le répéter, ça ne changera rien du tout à ce niveau-là, teste si tu ne me crois pas. 

Pour le MemoryPool, je sais ce que c'est merci, et l'implémentation que tu conseilles me semble inefficace (combien de taille différentes et d'espace alloué ?) 

En plus c'est réellement un faux problème, la plupart des allocations, dans une application bien conçue, sont évitées grâce à la pile, ce qui permet de n'avoir aucune allocation lors du rendu par exemple, chose impossible (?) dans des langages gérant la mémoire pour toi. 

Ton idée de référence n'est pas mauvaise, mais penses-tu être le premier à l'avoir eu ? Pourquoi Java ne fonctionne pas comme ça ? 

Pour les jeux vidéos, évidemment que beaucoup d'objets doivent être alloués dynamiquement, mais la pile sert également beaucoup. 

Pour ma part je vais arrêter le dialogue, j'ai pu te faire avancer sur certains points mais je sens que ceux qu'il reste vont être impossibles à débattre. Bref, bonne continuation, je reste à ta disposition si tu as des questions. 

-
Edité par Lynix 1 février 2015 à 13:48:29

Lynix a écrit:

Pour le MemoryPool, je sais ce que c'est merci, et l'implémentation que tu conseilles me semble inefficace (combien de taille différentes et d'espace alloué ?)

Pour le memory pool j'explique juste comment je pourrais l'implémenté en partant du principe qu'il y a beaucoup plus de petits objets qui sont créer/détruit souvent. La taille peut varié, selon le système ou même la taille total disponible. Le nombre total de taille différentes pourrait aller jusqu’à 100 par exemple. L'espace total utilisé serait le factorielle de tout ça.

Lynix a écrit:

Ton idée de référence n'est pas mauvaise, mais penses-tu être le premier à l'avoir eu ? Pourquoi Java ne fonctionne pas comme ça ?

Je ne fais pas ça juste pour être original, c'est ce que j'ai toujours utilisé pour faire des jeux vidéo et c'est le point fort de Flash. Je sais que c'est fiable, je n'irais pas dans quelque chose que je ne connais pas.

Lynix a écrit:

Pour ma part je vais arrêter le dialogue, j'ai pu te faire avancer sur certains points mais je sens que ceux qu'il reste vont être impossibles à débattre. Bref, bonne continuation, je reste à ta disposition si tu as des questions. 

La seule chose impossible à débattre est peut-être l'utilisation majoritaire du heap vs stack, car les 2 choix sont aussi bon l'un que l'autre. Sinon merci, il y a plusieurs choses qui vont s'améliorer grâce à toi.

-
Edité par Maeiky 1 février 2015 à 15:07:53

Salut

Super projet, topic ajouté direct aux favoris

J'ai une question :

sur la première page, tu parle de l'interpolation, comment fonctionne ton algorithme ?

cordialement