Discussion :

[Freakazoid]

En ce moment Direct3D est en train de me taper sur les nerf. Je n'arrive pas à afficher une simple image BMP sans qu'elle soit déformer en taille ou au niveau des couleurs. Je me demande donc si Direct3D peut afficher une image de façon neutre comme le faisait DirectDraw et si oui quelqu'un pourait juste me donner un bout de code qui le fait, avec initialisation de Direct3D, chargement d'une image dans une texture et rendu de la texture.
Ce serais super sympa parcque je suis au bord de la crise de nerf ...

[Laurent Gomila]

C'est vrai que c'est pas évident au début. Il y a quelques p'tits trucs à bien régler, si t'en loupes un t'es foutu. Bon pour le code complet j'ai pas trop trop le temps (peut-être que quelqu'un l'aura 8)), au pire est-ce que tu peux uploader tes sources, ça irait plus vite de corriger/ajouter ce qui ne va pas ?

[Freakazoid]

Houai sa c'est pas un problème. Merci pour l'aide, je galere !!

[Freakazoid]

Voila le code source :
http://perso.wanadoo.fr/vincent.dera...up_sources.zip

[Laurent Gomila]

Apparemment, le problème vient du chargement de la texture : ton image 100x50 est chargée dans une texture de 128x64. Mon hardware supporte pourtant des dimensions de texture non multiples de 2, alors je suppose qu'un paramètre est erroné quelque part.

Commence par vérifier les caps de ta carte, notamment D3DPTEXTURECAPS_NONPOW2CONDITIONAL ou D3DPTEXTURECAPS_POW2.

Ensuite regarde les limitations imposées par D3DPTEXTURECAPS_NONPOW2CONDITIONAL dans la doc du SDK. J'ai essayé de mettre tous les paramètres qu'ils indiquent, mais ça ne change rien, tu auras peut-être plus de chance que moi.

Et quelques petites remarques : enlève tous les trucs non standards dans ton code, VC7 refuse toujours de compiler ton projet (en l'occurence, remplace <deque.h> par <deque> + using namespace std). Ensuite il y a un libci.lib avec lequel il veut absolument linker, je suppose que c'est un truc Borland.
Et puis tu mets tout ton code dans des headers, je trouve ça plutot bizarre (et ça ne doit pas accélerer ton temps de compilation !)

[Freakazoid]

Sa fait beaucoups de chose tous sa ... Merci LouLou je vais regarder sa mais je suis pas sur d'avoir plus de chance, j'ai une GF5900XT, une carte recente et j'ai ces problèmes donc point de vu compatibilité je ne suis pas sur que sa vienne de là.
Pour le reste, il y'a encore quelques petit truc de C++ que je ne comprend et maitrise pas, je n'est jamais compris comment marchais les headers .h et leur sources .cpp, enfin c pas trop le problème ici.

[Freakazoid]

J'ai regarder les deux caps et il sont gerer par ma carte. J'ai essayer quelque petit truc mais rien de tres concluant.
Je pense que je vais en restez la et que je vais utiliser uniquement des images avec des dimensions puissance de deux, ce sera juste une petite contrainte pour le graphiste ...

[bleyblue]

j'ai trouvé ton erreur... en fait il faut lire la doc directx : dans ton code de chargement de texture, tu as

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

D3DXCreateTextureFromFileEx(D3D_Device, FileName, 0, 0, 0, 0, D3DFMT_A8R8G8B8, D3DPOOL_DEFAULT, D3DX_F...

il se trouve que la paramètre 5 (le 3e zéro) corresponde au nombre de mipmaps que tu veux avoir dans ta texture. Or, 1 mipmap est le nombre par défaut pour une texture normale, alors que si tu met 0, ça gènère automatiquement les mip maps ! et je crois que les mip maps doivent être des puissances de deux (à vérifier).
Donc le code corrigé est :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if (D3DXCreateTextureFromFileEx(D3D_Device, FileName, 0, 0, 1, 0, D3DFMT_A8R8G8B8, D3DPOOL_DEFAULT, D3DX_FILTER_NONE, D3DX_FILTER_NONE, ColorKey, &ImgInfo, NULL, pTexture) == D3D_OK)

[Laurent Gomila]

J'avais essayé (c'est indiqué dans la doc) ça ne marchait pas mieux. Ca marche chez toi en changeant ça :

[bleyblue]

ouais ça marche !!! et à part ça je ne vois vraiment pas ce que ça pouvait être !!!! faut voir si ça marche chez lui maintenant

[Freakazoid]

Je vais essayer mais il me semble l'avoir déjà fait.

[Freakazoid]

Heu sa marche pas ...

[LeGreg]

Sinon pour les textures non puissance de deux.

Les hardwares qui ne les supportent pas sont rares (NV et ATI les supportent tous les deux).

Depuis la 6800 (geforce 6), Nvidia supporte aussi les mipmaps sur les dimensions exotiques comme 100x50.

D3Dx va creer automatiquement une texture de dimension puissance de deux (quoique ce serait interessant de tester sur une 6800..)
Tout simplement parce qu'il y a trop de restrictions si le CAPS D3DPTEXTURECAPS_NONPOW2CONDITIONAL.

Les restrictions usuelles sont:
- pas d'adressage WRAP|MIRROR seul le CLAMP est supporté.
- pas de mipmaps.
- vitesse de texturing réduite (la perte peut-etre énorme si ton jeu est texture limited)

Toutes ces raisons font que si tu veux VRAIMENT créer une texture de 100x50 avec toutes ces restrictions en tete:
- tu dois spécifier les dimensions à la main. Je n'ai pas testé dernièrement mais ça implique peut-etre de passer par device.CreateTexture, ou alors passer les bons arguments à la fonction D3DXCreateTextureEx.
- Ou alors imposer à ton jeu de ne tourner que sur Geforce 6.
- En général et c'est ce qui est conseillé dans les docs DX c'est de créer les textures à une taille qui va bien 128x64 ou 128x128 par exemple dès le départ. C'est ce que tous les jeux du commerce font.

[Freakazoid]

Hum ... faire tourné un jeu 2D uniquement sur des Gf6 sa me tente pas trop. En fait je vais utiliser uniquement des textures avec des dimensions puissance de deux, cependant j'ai lu dans la doc que les dimensions qui donne de meilleurs perf. sont les textures en 256*256 mais j'ai rien lu sur des textures de 128*128 ou 128*64.

vitesse de texturing réduite (la perte peut-etre énorme si ton jeu est texture limited)

Heu c'est quoi un jeu avec texture limited ??

[Laurent Gomila]

Heu c'est quoi un jeu avec texture limited ??

Ca signifie simplement que le facteur limitant les performances dans ton jeu sont les textures. Les autres limitations typiques peuvent être la géometrie, la bande passante, le CPU, le fillrate, ...

[Freakazoid]

Okk

[LeGreg]

vitesse de texturing réduite (la perte peut-etre énorme si ton jeu est texture limited)

Heu c'est quoi un jeu avec texture limited ??

enfin quand je dis perte énorme c'est rare et ce n'est probablement pas un problème pour un jeu en 2d.
Si c'est juste un titre de ton menu en 100x50 ça passe aussi (avec les restrictions précitées).

Pour les perfs des textures, je ne sais pas où tu as lu pour 256x256 mais je ne vois pas trop pourquoi (les 3dfx voodoo 1 et 2 avaient une limitation sur la taille des textures en 256x256 mais à part ça).

Enfin généralement: perf du texturing va en baissant avec la résolution de la texture (plus elle est grande plus ça pose des problèmes au cache) sans compter que si tu charges trop de textures en mémoire video le texturing se fait depuis l'AGP (hypothétique mais ça peut arriver rapidement sur des cartes bas de gamme avec peu de mémoire embarquée).
Sinon la dimension en terme de rapport entre la longueur et la largeur est un faux problème, tu verras peut-etre une différence suivant la façon dont tu lis la texture (notamment si tu fais intervenir l'anisotropie) mais dans ce cas-là ce n'est pas vraiment la taille de la texture qui est en cause mais la manière dont tu y accèdes. De manière générale il est toujours préférable d'avoir une texture 1024x256 que quatre petites textures 256x256 que tu colles ensemble si c'est à ça que tu pensais.

[Freakazoid]

Voila ma source : http://msdn.microsoft.com/library/en...imizations.asp apres moi je c pas si c vrais.

Enfin généralement: perf du texturing va en baissant avec la résolution de la texture (plus elle est grande plus ça pose des problèmes au cache) sans compter que si tu charges trop de textures en mémoire video le texturing se fait depuis l'AGP (hypothétique mais ça peut arriver rapidement sur des cartes bas de gamme avec peu de mémoire embarquée).

Heu je croyais que les textures etait d'abord chargé en mémoire video et apres en mémoire systeme quand il y'a plus de place.

De manière générale il est toujours préférable d'avoir une texture 1024x256 que quatre petites textures 256x256 que tu colles ensemble si c'est à ça que tu pensais.

Je croyais aussi qu'il etait preférable d'avoir de petite texture pour favorié les textures en cache proc.
Heu j'ai des doutes maintenant, si on peux m'éclairé.

[LeGreg]

je ne sais pas ce que la personne qui a tapé ça chez Microsoft avait en tete mais c'est très louche.

D'abord les textures de 128x128 c'est valable si tu programmes sur PS2 pas sur PC. Et le fait qu'ils mentionnent le fait que les textures doivent partager la meme palette (ce que les cartes modernes ne supportent plus!) ou du Level 2 du CPU (et pas GPU!), me fait penser que ce paragraphe a simplement été copié d'un document dépassé genre à l'époque de la Voodoo 1 de 3dfx...

Heu je croyais que les textures etait d'abord chargé en mémoire video et apres en mémoire systeme quand il y'a plus de place.

oui elles le sont. Quand tu as peu de mémoire embarqué et que tu montes la résolution ça arrive assez rapidement. Mais dans ce cas-là tu proposes une option dans programme qui permet d'utiliser des textures de résolution plus basse -> pas la peine de pénaliser les utilisateurs qui ont une machine correcte.

Je croyais aussi qu'il etait preférable d'avoir de petite texture pour favorié les textures en cache proc.
Heu j'ai des doutes maintenant, si on peux m'éclairé.

Je crois que tu n'as pas bien compris un truc. Quand tu réunis quatre textures de 256x256 en une seule de 1024x256, ça ne prend pas plus de place en mémoire video et l'accès à ces textures se fait de la même façon. Si c'était cache friendly avant, ça sera cache friendly après (sauf quelques cas liés à l'architecture mais que le programmeur n'a pas besoin de connaitre).
La raison pour laquelle tu aurais envie de réunir plusieurs textures en une seule, c'est que switcher les textures pendant le rendu a un certain cout (quasiment nul sur XBox mais relativement grand sur PC). Si tu modifies ton contenu en conséquence (modifier les texture coordinates pour adresser la partie de texture qui t'interesse) et que ça n'entraine pas de cout supplémentaire sur le CPU, alors tu peux potentiellement batcher plus de choses.
Et le batching c'est la meilleure chose qui puisse arriver à ton moteur .

[LeGreg]

bien entendu ce sont des guidelines.

Tu es toujours libre de choisir le format, taille etc.. des textures qui conviennent le mieux à ton moteur. Tu ne dois changer ça que si la performance ne te suffit pas (et il y a beaucoup de goulots d'étranglements possibles).