Discussion :

[MatRem]

Merci, tout ça est moins flou.

Personnelement, dans un souci de portablilité j'aimerais quand même que mes logiciels fonctionnent aussi avec des cartes graphiques de l'époque des geforce 4.
Je n'aurais sans doute pas la possibilté d'adhérer au programme developpeur de nvidia . Donc il va falloir se débrouiller tout seul pour savoir ce que chaque carte à dans le ventre.

En fait, il est vrai que tout la config n'a pas besoin de se faire automatiquement, on peut laisser l'utilisateur choisir la config qui lui va bien à l'aide d'un menu (il verra lui même, si les textures ne s'affichent pas).

Mais bon, pour avoir une config par défaut qui ne soit pas la plus mauvaise, ça serait pas mal de faire un petit benchmark invisible (ou pas d'ailleurs).
Cependant, il ne doit pas simplement falloir testes les fps. Par exemple avec une texture 96x96 sur geforce 4mx, ça va aller vite, mais ça sera tout blanc...
Enfin bref c'est peu être pas si facile à faire que ça.

[bafman]

les voodoo 3 supporte le 512*512... par contre forcement si tu met des texture non puissance de 2 (mais c'est completement intraductible ce terme de non power of 2 ), la forcement tu aura des problemes... pourquoi ne pas tout faire en puissance de 2, c'est plus rapide et supporté par tout le monde...

[Groove]

Et avec l'avenement des shaders, la gestion des codepaths ne va pas en se simplifiant XD

Par contre le probleme de la taille max des textures, je pense vraiment qu'il est n'egligable. Depuis le TNT2 la taille max est 2048x2048. Depuis le GeForceFX5200 c'est 4096x4096. Par contre la taille de la memoire embarqué sur la carte c'est un vrai probleme.

Une texture de 4096x4096 RGBA : 64Mo => La ram peu etre bien vite saturé, mais a mon avis c'est d'avantage le probleme des artistes que celui des programmeurs.

Pour les textures a NPOT (non power of two), les performances sont tres bonne sur les cartes qui les supportent en hardware mais ca reste a utiliser le moins possible. Si c'est pour fait du 96x96 => oublie si c'est pour du 640*480 pour faire un effet post processing, ou le HUD alors c'est parfait.

Voila pour mon opinion dans cet interessant debat

[Groove]

Un petit conplement d'optimisation par plateform comme vous evoquiez le sujet.

A mon avis les textures NPOT ne doivent etre utilisé que pour le rendu texture projeté sur l'écran. Sur les GeForce 3, 4 et 5 elle ne sont malheureusement pas supporté.

Malheureusement pas car pour repondre au probleme on pourrait utilisé des textures a puissance de 2 mais soit on les fait deborder de l'ecran sois on les deforme pour les caser dans l'ecran. Le coup pour une qualité equivalente, c'est de la memoire video en plus.

Une meilleure solution consiste a utiliser l'extension ARB_texture_rectangle qui permet d'avoir des textures de taille NPOT mais sans filtrage et sans mipmaps, ce qui est inutil pour une texture projecté a l'ecran.

Avec l'integration de ARB_texture_non_power_of_two dans les specs d'OpenGL 2.0 on peut penser que ARB_texture_rectangle n'a pas d'avenir et ne sera jamais integré au spec comme ce fut le cas pour ARB_vertex_blend ou les extensions pour les shaders "genre ASM"

[MatRem]

C'est sur qu'il vaut mieux éviter l'utilisation des textures NPOT, ça simplifie la vie (c'est cool quand on trouve tout un package d'une centaine de textures 96x96 sur le net ).

Par contre, ce probleme avec les textures n'est qu'un exemple, mais il doit surement y en avoir d'autres qui perturbent la creation d'un code portable (multi carte), en ne testant que sur une carte vidéo?

[bafman]

ho oui il en existe pleins...
par exemple a une epoque (si ca se trouve c'est toujours d'actualité, je n'ai pas re testé), sur carte ATI, pour pouvoir avoir l'alpha test d'activé, il fallais obligatoirement activer le blending.. oui ca n'a rien a voir mais c'est comme ca
un autre "truc" a savoir, c'est que les fragment program sur ATI ont une limitations du nombre de lecture de textures, ainsi, si on essaye trop d'aller lire dans une texture, le fragment program plante et on a droit a du noir... tres sympa surtout qu'il ne dit rien a la compilation...

en fait, plus generalement, l'implementation openGL d'ATI laisse à desirer sur pas mal de points... d'ou, pour developper de l'openGL, toujours le faire sur une carte ATI car si ca marche sur ATI ca marchera sur nVidia

[MatRem]

Oui mais pour ceux qui developpent d'abord sous linux et qui passe le tout aprés sous windows, développer sur ATI n'est pas des plus agréable.

En effet leur pilote laissent encore à désirer, ils ne sont pas encore au niveau de NVIDIA sur ce point là.

Merci pour les petites astuces à connaitre...

[bafman]

Oui mais pour ceux qui developpent d'abord sous linux et qui passe le tout aprés sous windows, développer sur ATI n'est pas des plus agréable.

En effet leur pilote laissent encore à désirer, ils ne sont pas encore au niveau de NVIDIA sur ce point là.

Merci pour les petites astuces à connaitre...

c'est exactement ce que je dit... et il n'y a pas que sous windows que leurs pilotes openGL ne sont pas au points...