Débutant dans le monde de l'OpenGL MODERNE

Sahengette · 30/12/2011, 01h01

Bonjour,
Je débute à fond dans la programmation 3D, et je cherche vraiment à utiliser OpenGL pour m'amuser entre autre, mais d'une façon propre.
En effet sur le net je ne trouve que des tutos qui traite des vieilles versions d'OGL, trés trés peu sur OGL 3.3 et supérieur, à part celui du SDZ, j'ai même cherché sur des sites anglais mais rien de complet ...

D'ailleurs j'ai plein de question :

Sur le tuto du sdz, on apprend à recoder de vieilles fonctions (gluLookAt) vraiment en copiant totalement le fonctionnement de la fonction glu, sans intêret surtout qu'on n'optimise rien. Je trouve ça vraiment pas claire ...

Aussi, l'architecture de OGL, je la trouve improbable : en effet elle est trés puissante mais je ne vois vraiment par où commencer ...
Quelle est la "bonne manière" de procéder ?

En effet quand on débute dans OGL 2.x, on est un minimum aidé par Glu et les fonctions gl non dépréciés, mais dans OGL 3.x je trouve ça ardu pour commencer (je ne remet pas en cause OGL !).

Pourriez vous me conseiller un tuto en ligne (anglais comme francais) sur de l'OpenGL moderne de qualité (parce que je trouve les tutos du SDZ douteux en général) qui montre les vrais nouveautés et la vraie nouvelle idéologie de OGL, un livre peut-être ?

J'attend vraiment beaucoup de ce topic, en effet je suis complétement largué en ce bas monde, je cherche la voie du salut, un guide éternel pour une béatitude complète, ~~Dieu~~ vous ?

DonQuiche · 30/12/2011, 10h34

Citation:

Envoyé par Sahengette

Sur le tuto du sdz, on apprend à recoder de vieilles fonctions (gluLookAt) vraiment en copiant totalement le fonctionnement de la fonction glu, sans intêret surtout qu'on n'optimise rien. Je trouve ça vraiment pas claire ...

J'ai googlé sdz et je suis tombé sur siteduzéro, c'est ce dont tu parlais ? Par contre je n'ai pas trouvé le tuto en question.

De bons tutos, complets, je n'en connais pas. Tu peux par contre trouver les livres sur OpenGL 3.x voire OpenGL ES 2.0 (ce dernier est grosso modo équivalent à OpenGL 2 moins tout ce qui a été rendu obsolète dans OpenGL3 et quelques fonctions trop lourdes pour des mobiles).

Cela dit, si tu as compris comment utiliser un shader et que tu connais l'ancien OpenGL, il n'y a rien de très sorcier. Tu dois écrire un ou plusieurs shaders qui vont transformer tes sommets. Tu peux en écrire un qui prendra une, deux ou trois matrices en argument, un autre qui ne prendra qu'un point en argument, un autre qui prendra simplement trois facteurs d'échelle, etc. Il n'y a pas une bonne façon générique de faire, tout dépend de ton programme, de la nature des transformations à effectuer, de la fréquence à laquelle elles changent, de techniques d'équilibre de la charge CPU et GPU (par exemple, faire mettre en cache par le CPU des résultats de calculs qui changent rarement pour les passer prêts à l'emploi au GPU), etc. De toute façon tout ça ne relève que de l'optimisation.

Maintenant, si tu veux reproduire le comportement OGL1, c'est simple :
* Ecris un vertex shader qui prend deux matrices en argument et multiplie successivement les sommets par ces deux matrices pour obtenir la position à l'écran.
* Tu écris des primitives créant la matrice projection et une pile de matrices ViewModel. A chaque dessin tu passes en argument au shader ta matrice projection et le sommet de ta pile VM.

Mais supposons que tu dessines des modèles qui sont toujours à la même position sur l'écran (cockpit dans un jeu spatial à la première personne, la tête ne peut pas tourner) : dans ce cas autant appliquer les transformations côté CPU la première fois et utiliser un vertex shader vide. Ou si seule la caméra bouge et que les objets restent immobiles dans le monde (maisons identiques mais orientées différemment), on pourrait transformer une fois pour toute les sommets côté CPU pour les placer dans les coordonnées monde et ne passer qu'une matrice de projection au shader. Ou peut-être pas puisque cela augmenterait la conso mémoire (chaque clone devant maintenant avoir sa propre géométrie prétransformée), tout dépend donc des charges générées dans les deux cas et des goulets d'étranglement de ton appli. Enfin, si tu fais du dessin 2D avec des primitives qui ne font translater, on écrira un shader qui ne prendra qu'un vecteur 2D en argument et pas de matrices.

Il n'y a pas une seule façon de faire, il y a de nombreux problèmes possibles et pour chacun des réponses plus ou moins astucieuses. Bref ! C'est de la programmation !

Rappelle-toi simplement que ce n'est que de l'optimisation et que "premature optimization is the root of all evil". Enfin, pas toujours.

bru-no · 30/12/2011, 13h57

Citation:

Envoyé par Sahengette

[...]

Ben oui c'est ardu...

Il n'y a pas de changement véritable d'esprit entre les versions d'opengl, plutôt de méthodes.

Personnellement je te conseille, malgré ce que tu en penses, d'apprendre avec les tutoriaux du site du zéro SDL + Opengl 2.x (en passant directement aux VBO + shaders). Ces tutoriaux ne sont pas là pour te transformer en super gourou de la 3d, mais pour te donner des bases. L'optique c'est pas de te sortir un code super optimisé pour afficher un simple cube texturé, c'est de te faire comprendre les mécanismes nécessaires au fonctionnement d'Opengl. Une fois à l'aise avec l'API (y a du travail quand même), tu feras tes optimisations.

Cette version permet déjà de faire beaucoup de choses. Si je ne dis pas de bêtises, Doom 3 (ok c'est pas le jeu le plus récent) a été développé avec 2.x.

Après il faut du temps, beaucoup de temps, et de la patience...

DonQuiche · 30/12/2011, 14h08

Pour ma part je pense que c'est une bonne idée de travailler en OpenGL 2.0... Mais sans jamais utiliser tout ce qui a été rendu obsolète dans la 3.0 ! Autrement dit d'utiliser un pur pipeline programmable, de l'OpenGL 3.0 sans les additions de la 3.0.

Tout simplement parce que le pipeline programmable c'est l'avenir (le présent en fait) et que c'est déjà bien supporté par le parc actuel. Et que, aujourd'hui, en faisant ça on peut écrire un code qui tourne presque sans modifications sur des mobiles (OpenGL ES 2.0 c'est à peu près ça) et qui peut être assez facilement porté vers Dx9 (qui lui-même très bien supporté au niveau hardware par le parc existant). Et aussi parce que certaines des fonctions rendues obsolètes pourraient à l'avenir ne pas être supportées, ou être mal supportées, par les drivers.

Enfin, le pipeline fixe est plus compliqué à apprendre et à utiliser, son API est plus volumineuse et je ne vois donc pas en quoi ce serait un bon préalable. Pas de comparaison foireuse svp, l'asm est certes plus compliqué à apprendre mais il n'a pas été marqué obsolète, lui.

bru-no · 30/12/2011, 14h26

Citation:

Envoyé par DonQuiche

Pour ma part je pense que c'est une bonne idée de travailler en OpenGL 2.0... Mais sans jamais utiliser tout ce qui a été rendu obsolète dans la 3.0 ! Autrement dit d'utiliser un pur pipeline programmable, de l'OpenGL 3.0 sans les additions de la 3.0.

C'est l'idée que je voulais faire passer. On ne saurait mieux dire !

Sahengette · 30/12/2011, 14h56

Je commence un peu à comprendre, la force du pipeline programmable, c'est de optimiser son programmer comme on veut, il n'y a pas de "solution passe-partout", j'ai juste à faire mumuse avec différents shaders, en fonction du programme, en testant les perfs etc ...
Je me trompe ?

Sahengette · 30/12/2011, 14h58

Citation:

Envoyé par bru-no

C'est l'idée que je voulais faire passer. On ne saurait mieux dire !

Et c'est quoi ces fonctionnalitées supplémentaires, que propose OpenGL 3.3

DonQuiche · 30/12/2011, 15h34

Citation:

Envoyé par Sahengette

Je commence un peu à comprendre, la force du pipeline programmable, c'est de optimiser son programmer comme on veut, il n'y a pas de "solution passe-partout", j'ai juste à faire mumuse avec différents shaders, en fonction du programme, en testant les perfs etc ...
Je me trompe ?

Tu as tout juste.

Note que tester les perfs c'est tout de même délicat : ça varie d'une carte graphique à l'autre, d'une version des drivers à une autre et ça dépend du contexte : dans un programme dont le goulet d'étranglement est le CPU, les bonnes méthodes sont celles qui allègeront la tâche de ce dernier. Mais elles seront mauvaises dans d'autres cas. Il faut surtout voir les choses en termes de goulets d'étranglement (bottlenecks) même si, typiquement, c'est le CPU dans un programme optimisé (mais parfois parce qu'on lui a filé des tâches qui ont permis de faire en sorte que le reste ne soit plus un bottleneck et donc de rendre le programme plus rapide).

Citation:

Envoyé par Sahengette

Et c'est quoi ces fonctionnalitées supplémentaires, que propose OpenGL 3.3

Pour ça l'article US de Wikipedia est pratique parce qu'il liste toutes les versions et leurs changements, cela permet de retrouver en vitesse de quand datent telles et telles innovations et en déduire un support approximatif par tes utilisateurs.

bru-no · 30/12/2011, 16h10

Un outils qui pourra sans doute t'aider pendant le développement : gDEBugger

Les shaders vont te permettre de gérer l'affichage. Par exemple pour le fragment shader les points de l'image sont traités un par un avant d'être affiché. Imagine que tu fasses un jeu dans lequel y a des flashback en noir et blanc : il suffit que tu fasses un shader qui pour chaque pixel va faire la moyenne des valeurs r,g,b, et envoyer la valeur en sortie. Bon je simplifie énormément, mais c'est l'idée. Tu as accès à ce qui va être affiché et tu peux le modifier à ta convenance.

Sur geeks3d, tu as une shader library, ça peut te donner une idée de ce que l'on peut faire aussi.

Sahengette · 30/12/2011, 18h57

Merci beaucoup, c'est vraiment sympa tout ça !

Citation:

Pour ma part je pense que c'est une bonne idée de travailler en OpenGL 2.0... Mais sans jamais utiliser tout ce qui a été rendu obsolète dans la 3.0 ! Autrement dit d'utiliser un pur pipeline programmable, de l'OpenGL 3.0 sans les additions de la 3.0.

J'ai (encore) une question, pourquoi est ce que je devrez essayer de ne pas utiliser les nouveautés de OGL 3.3 ?

DonQuiche · 30/12/2011, 19h30

Pour deux raisons. La première tient au support. Non seulement parce que, comme je l'ai dit, si tu apprends à faire du pur pipeline programmable en OGL2, tu sais également programmer avec Dx9 et OpenGL ES 2.0. Autrement dit tu dois couvrir 50% du marché mobile+PC+Mac. 50% seulement pour une norme datant de 2004 ?! Oui ! Parce que plein d'utilisateurs ont des drivers pourris qui font qu'ils ne profitent pas de l'accélération et que Intel se fout royalement d'OpenGL (ex avec OGL2 : norme publiée en 2004, chipsets compatibles sortis en 2006 mais aucun driver avant mi-2009 ! Donc les utilisateurs qui ont acheté leur machine avant et n'ont jamais mis à jour leurs drivers ne profitent pas de OGL2). DirectX est clairement mieux loti (support Dx9 dès la sortie des chipsets)

Ça c'était pour OGL2 qui date de 2004. OpenGL 3.0 date quant à lui de 2008 et les premiers chipsets Intel compatibles sont sortis en 2011. J'ignore s'ils ont des drivers compatibles en revanche. Quant à OGL 3.3, la norme date de 2010 seulement. Autant dire que moins de 5% du parc PC doit être compatible. Quant au mobile, OpenGL ES 2.0 est la plus haute norme à ce jour et pas dispo sur tous les mobiles (pour iPhone, à partir de 2009).

Après, tout dépend. Si tu développes aujourd'hui un jeu PC devant sortir dans deux ans et destiné à un public de gamers ayant en moyenne des machines supérieures, tu peux optimiser pour OGL 3.0 et simplement assurer un support décent pour OGL 2.0. Mais pour la plupart des développements, on restera plutôt sur du 2.0/2.1 en assurant un support décent pour 1.1. Dans tous les cas, savoir se limiter au 2.0 sera obligatoire pendant de nombreuses années encore, ne serait-ce que pour une compatibilité a minima.

L'autre raison est purement pédagogique : connaître les "vieux" algorithmes (enfin, ceux utilisés aujourd'hui dans tous les jeux) plutôt que les nouveaux (ceux présents en option dans quelques jeux pour justifier l'achat de deux CG à 300€ chaque) peut se révéler utile. Ne serait-ce que parce qu'ils permettent de libérer de la puissance pour la dédier à autre chose. Ou encore parce que les astuces qu'ils utilisent ont souvent tendance à être recyclées ou transposées à de nouveaux problèmes. Les connaître te permettra d'avoir davantage d'outils pour élaborer tes solutions.

Sahengette · 01/01/2012, 18h29

Merci beaucoup pour toutes ces réponses, cest sympa.
Et ça fait plaisir de voir qu'on est prit au sérieux, quand je vois que vous parlez de "jeu qui doit sortir dans X temps", "couvrir le parc de PC" ...
Sinon, vous n'auriez pas un petit tutoriel en ligne à me mettre sous la dent, même en anglais, histoire de m'amuser un peu.

Bonne année !

DonQuiche · 01/01/2012, 22h03

Citation:

Sinon, vous n'auriez pas un petit tutoriel en ligne à me mettre sous la dent, même en anglais, histoire de m'amuser un peu.

Si seulement je connaissais un bon tuto OGL moderne, je lui ferais volontiers de la pub. Je pense qu'il faut vraiment se tourner vers les livres.

Citation:

Bonne année !

Merci et de même.

dragonjoker59 · 02/01/2012, 10h10

Ayant éprouvé le même genre de problèmes que toi (à savoir comment faire de l'OpenGL 3.x/4.x), je me suis aperçu que le plus gros du travail consiste à créer un contexte OpenGL compatible 3.x/4.x.
Pour ça, j'ai trouvé à peu près ce qu'il me fallait sur le net, ensuite l'utilisation des fonctionnalités de base propres à OpenGL 3.x/4.x (Frame Buffer Objects, Texture Buffer Objects, Vertex Array Objects, Uniform Buffer Object sous les petits noms de FBO, TBO, VAO et UBO

) sont assez simples à utiliser pour peu que l'on soit familiarisé avec les Vertex Buffer Object (VBO) qui sont disponibles depuis OpenGL 1.4 avec l'extension ARB.
Donc au final le plus gros de ton travail consistera à te familiariser avec ces VBO pour comprendre correctement le fonctionnement des nouvelles fonctions.
Sinon, je me suis pas mal appuyé sur ce site pour utiliser les fonctionnalités plus ou moins récentes (à partir des Pixel Buffer Object)

Sahengette · 02/01/2012, 14h47

Merci pour ces informations, j'ai commandé le livre et en attendant je pioche sur internet des tutoriels (super ton site dragonjoker !).

LittleWhite · 03/01/2012, 22h08

Bonjour,

N'oubliez pas de regarder sur cette page. Et puis ma page perso aussi (pour un tuto sur le GLSL, lien dans la signature).
En fait, je suis d'accord, le net français est bien pauvre en terme d'OpenGL. On essaie de remédier à cette situation et je vous invite à me contacter si vous souhaitez écrire des articles (@Sahengette une fois que vous maitriserez

). Sinon, les tutos de songho sont géniaux, je trouve

30/12/2011, 01h01	#1
Sahengette Nouveau Membre du Club Inscription : octobre 2011 Messages : 52 Détails du profil Informations personnelles : Sexe : Localisation : France Informations forums : Inscription : octobre 2011 Messages : 52 Points : 35 Points : 35	Débutant dans le monde de l'OpenGL MODERNE Bonjour, Je débute à fond dans la programmation 3D, et je cherche vraiment à utiliser OpenGL pour m'amuser entre autre, mais d'une façon propre. En effet sur le net je ne trouve que des tutos qui traite des vieilles versions d'OGL, trés trés peu sur OGL 3.3 et supérieur, à part celui du SDZ, j'ai même cherché sur des sites anglais mais rien de complet ... D'ailleurs j'ai plein de question : Sur le tuto du sdz, on apprend à recoder de vieilles fonctions (gluLookAt) vraiment en copiant totalement le fonctionnement de la fonction glu, sans intêret surtout qu'on n'optimise rien. Je trouve ça vraiment pas claire ... Aussi, l'architecture de OGL, je la trouve improbable : en effet elle est trés puissante mais je ne vois vraiment par où commencer ... Quelle est la "bonne manière" de procéder ? En effet quand on débute dans OGL 2.x, on est un minimum aidé par Glu et les fonctions gl non dépréciés, mais dans OGL 3.x je trouve ça ardu pour commencer (je ne remet pas en cause OGL !). Pourriez vous me conseiller un tuto en ligne (anglais comme francais) sur de l'OpenGL moderne de qualité (parce que je trouve les tutos du SDZ douteux en général) qui montre les vrais nouveautés et la vraie nouvelle idéologie de OGL, un livre peut-être ? J'attend vraiment beaucoup de ce topic, en effet je suis complétement largué en ce bas monde, je cherche la voie du salut, un guide éternel pour une béatitude complète, ~~Dieu~~ vous ?
	00

02/01/2012, 10h10	#14
dragonjoker59 Membre Expert Sylvain DOREMUS Ingénieur - Développeur Inscription : juin 2005 Messages : 534 Détails du profil Informations personnelles : Nom : Sylvain DOREMUS Âge : 30 Localisation : France, Alpes de Haute Provence (Provence Alpes Côte d'Azur) Informations professionnelles : Activité : Ingénieur - Développeur Secteur : High Tech - Éditeur de logiciels Informations forums : Inscription : juin 2005 Messages : 534 Points : 1 066 Points : 1 066	Ayant éprouvé le même genre de problèmes que toi (à savoir comment faire de l'OpenGL 3.x/4.x), je me suis aperçu que le plus gros du travail consiste à créer un contexte OpenGL compatible 3.x/4.x. Pour ça, j'ai trouvé à peu près ce qu'il me fallait sur le net, ensuite l'utilisation des fonctionnalités de base propres à OpenGL 3.x/4.x (Frame Buffer Objects, Texture Buffer Objects, Vertex Array Objects, Uniform Buffer Object sous les petits noms de FBO, TBO, VAO et UBO ) sont assez simples à utiliser pour peu que l'on soit familiarisé avec les Vertex Buffer Object (VBO) qui sont disponibles depuis OpenGL 1.4 avec l'extension ARB. Donc au final le plus gros de ton travail consistera à te familiariser avec ces VBO pour comprendre correctement le fonctionnement des nouvelles fonctions. Sinon, je me suis pas mal appuyé sur ce site pour utiliser les fonctionnalités plus ou moins récentes (à partir des Pixel Buffer Object) __________________ Si vous ne trouvez plus rien, cherchez autre chose... Chef de projet (et unique exécutant pour l'instant) pour Castor 3D
	00

03/01/2012, 22h08	#16
LittleWhite Responsable 2D/3D/Jeux Alexandre Laurent Étudiant Inscription : mai 2008 Messages : 6 560 Détails du profil Informations personnelles : Nom : Alexandre Laurent Localisation : France Informations professionnelles : Activité : Étudiant Informations forums : Inscription : mai 2008 Messages : 6 560 Points : 14 054 Points : 14 054	Bonjour, N'oubliez pas de regarder sur cette page. Et puis ma page perso aussi (pour un tuto sur le GLSL, lien dans la signature). En fait, je suis d'accord, le net français est bien pauvre en terme d'OpenGL. On essaie de remédier à cette situation et je vous invite à me contacter si vous souhaitez écrire des articles (@Sahengette une fois que vous maitriserez ). Sinon, les tutos de songho sont géniaux, je trouve __________________ Vous souhaitez participer à la section Jeux ? Contactez-moi La rubrique a aussi un blog ! Ma page sur DVP Mon Portfolio Qui connaît l'erreur, connaît la solution.
	00

30/12/2011, 14h08	#4
DonQuiche Expert Confirmé Inscription : septembre 2010 Messages : 1 350 Détails du profil Informations forums : Inscription : septembre 2010 Messages : 1 350 Points : 2 510 Points : 2 510	Pour ma part je pense que c'est une bonne idée de travailler en OpenGL 2.0... Mais sans jamais utiliser tout ce qui a été rendu obsolète dans la 3.0 ! Autrement dit d'utiliser un pur pipeline programmable, de l'OpenGL 3.0 sans les additions de la 3.0. Tout simplement parce que le pipeline programmable c'est l'avenir (le présent en fait) et que c'est déjà bien supporté par le parc actuel. Et que, aujourd'hui, en faisant ça on peut écrire un code qui tourne presque sans modifications sur des mobiles (OpenGL ES 2.0 c'est à peu près ça) et qui peut être assez facilement porté vers Dx9 (qui lui-même très bien supporté au niveau hardware par le parc existant). Et aussi parce que certaines des fonctions rendues obsolètes pourraient à l'avenir ne pas être supportées, ou être mal supportées, par les drivers. Enfin, le pipeline fixe est plus compliqué à apprendre et à utiliser, son API est plus volumineuse et je ne vois donc pas en quoi ce serait un bon préalable. Pas de comparaison foireuse svp, l'asm est certes plus compliqué à apprendre mais il n'a pas été marqué obsolète, lui.
	00

30/12/2011, 14h56	#6
Sahengette Nouveau Membre du Club Inscription : octobre 2011 Messages : 52 Détails du profil Informations personnelles : Sexe : Localisation : France Informations forums : Inscription : octobre 2011 Messages : 52 Points : 35 Points : 35	Je commence un peu à comprendre, la force du pipeline programmable, c'est de optimiser son programmer comme on veut, il n'y a pas de "solution passe-partout", j'ai juste à faire mumuse avec différents shaders, en fonction du programme, en testant les perfs etc ... Je me trompe ?
	00

30/12/2011, 16h10	#9
bru-no Membre du Club Inscription : juillet 2004 Messages : 49 Détails du profil Informations forums : Inscription : juillet 2004 Messages : 49 Points : 41 Points : 41	Un outils qui pourra sans doute t'aider pendant le développement : gDEBugger Les shaders vont te permettre de gérer l'affichage. Par exemple pour le fragment shader les points de l'image sont traités un par un avant d'être affiché. Imagine que tu fasses un jeu dans lequel y a des flashback en noir et blanc : il suffit que tu fasses un shader qui pour chaque pixel va faire la moyenne des valeurs r,g,b, et envoyer la valeur en sortie. Bon je simplifie énormément, mais c'est l'idée. Tu as accès à ce qui va être affiché et tu peux le modifier à ta convenance. Sur geeks3d, tu as une shader library, ça peut te donner une idée de ce que l'on peut faire aussi.
	00

30/12/2011, 19h30	#11
DonQuiche Expert Confirmé Inscription : septembre 2010 Messages : 1 350 Détails du profil Informations forums : Inscription : septembre 2010 Messages : 1 350 Points : 2 510 Points : 2 510	Pour deux raisons. La première tient au support. Non seulement parce que, comme je l'ai dit, si tu apprends à faire du pur pipeline programmable en OGL2, tu sais également programmer avec Dx9 et OpenGL ES 2.0. Autrement dit tu dois couvrir 50% du marché mobile+PC+Mac. 50% seulement pour une norme datant de 2004 ?! Oui ! Parce que plein d'utilisateurs ont des drivers pourris qui font qu'ils ne profitent pas de l'accélération et que Intel se fout royalement d'OpenGL (ex avec OGL2 : norme publiée en 2004, chipsets compatibles sortis en 2006 mais aucun driver avant mi-2009 ! Donc les utilisateurs qui ont acheté leur machine avant et n'ont jamais mis à jour leurs drivers ne profitent pas de OGL2). DirectX est clairement mieux loti (support Dx9 dès la sortie des chipsets) Ça c'était pour OGL2 qui date de 2004. OpenGL 3.0 date quant à lui de 2008 et les premiers chipsets Intel compatibles sont sortis en 2011. J'ignore s'ils ont des drivers compatibles en revanche. Quant à OGL 3.3, la norme date de 2010 seulement. Autant dire que moins de 5% du parc PC doit être compatible. Quant au mobile, OpenGL ES 2.0 est la plus haute norme à ce jour et pas dispo sur tous les mobiles (pour iPhone, à partir de 2009). Après, tout dépend. Si tu développes aujourd'hui un jeu PC devant sortir dans deux ans et destiné à un public de gamers ayant en moyenne des machines supérieures, tu peux optimiser pour OGL 3.0 et simplement assurer un support décent pour OGL 2.0. Mais pour la plupart des développements, on restera plutôt sur du 2.0/2.1 en assurant un support décent pour 1.1. Dans tous les cas, savoir se limiter au 2.0 sera obligatoire pendant de nombreuses années encore, ne serait-ce que pour une compatibilité a minima. L'autre raison est purement pédagogique : connaître les "vieux" algorithmes (enfin, ceux utilisés aujourd'hui dans tous les jeux) plutôt que les nouveaux (ceux présents en option dans quelques jeux pour justifier l'achat de deux CG à 300€ chaque) peut se révéler utile. Ne serait-ce que parce qu'ils permettent de libérer de la puissance pour la dédier à autre chose. Ou encore parce que les astuces qu'ils utilisent ont souvent tendance à être recyclées ou transposées à de nouveaux problèmes. Les connaître te permettra d'avoir davantage d'outils pour élaborer tes solutions.
	00

01/01/2012, 18h29	#12
Sahengette Nouveau Membre du Club Inscription : octobre 2011 Messages : 52 Détails du profil Informations personnelles : Sexe : Localisation : France Informations forums : Inscription : octobre 2011 Messages : 52 Points : 35 Points : 35	Merci beaucoup pour toutes ces réponses, cest sympa. Et ça fait plaisir de voir qu'on est prit au sérieux, quand je vois que vous parlez de "jeu qui doit sortir dans X temps", "couvrir le parc de PC" ... Sinon, vous n'auriez pas un petit tutoriel en ligne à me mettre sous la dent, même en anglais, histoire de m'amuser un peu. Bonne année !
	00

02/01/2012, 14h47	#15
Sahengette Nouveau Membre du Club Inscription : octobre 2011 Messages : 52 Détails du profil Informations personnelles : Sexe : Localisation : France Informations forums : Inscription : octobre 2011 Messages : 52 Points : 35 Points : 35	Merci pour ces informations, j'ai commandé le livre et en attendant je pioche sur internet des tutoriels (super ton site dragonjoker !).
	00

Outils de la discussion
Afficher une version imprimable Envoyer un lien vers cette page par email