J´ai décidé de faire un petit jeu avec DirectX pour m´amuser et je rencontre un problème étrange :

Je charge une image à partir d´un fichier à l´aide de :

D3DXCreateTextureFromFile( g_peripherique3D, fichier, & )

Et lorsque je l´affiche ( avec un objet LPD3DXSPRITE nommé g_routineSprites ) ansi :

g_routinesSprites->Draw( image, NULL, NULL, NULL, 0, &3DXVECTOR2( ( float)x, ( float)y ) , 0xFFFFFFFF ) ;

Celui-ci apparait grossi et " blured", or le paramètre de scaling est NULL ( donc 1.0, 1.0 ) .
A quoi cela est il dû ?

Hier, j´ai mangé une pomme! J´ai absolument rien pigé!!!

Si c´était pour faire une réflexion comme ça, tu peux retourner d´où tu viens, on veut pas de toi

lag-it Tu as jeté un coup d´oeil sur les exemples du SDK je présume ( non ? zut) ben faut p´tet regarder la MSDN, ya surement un truc interessant, tu codes en DirectX 8 ? 9 ?

Le Géant te répondra de toute façon

--log

Oui j´ai jeté un oeil à la MSDN mais rien : ils expliquent les fonctions mais ne signalent pas ce type de problème.
Quand aux exemples, j´en ai quelques uns sous les yeux mais qui n´emploient pas cette méthoe.
J´utilise DirectX 9 et j´ai déjà rencontré ce problème, mais je sais plus comment je l´ai résolu
Sinon mon code est ultra-basique : à part les fonctions d´initialisation et les GeginScene . .. y a que ce que j´ai mis plus haut.
LJe rencontre ce problème aussi bien avec du PNG que du Bitmap...

c´est clair que l´interface ID3DXSPRITE est loin d´etre suffisamment documentée dans le SDK...

intuitivement, deux possibilités : soit ta texture est dans un mauvais format ( au sens dimensions), genre en 34x34 ce qui fait qu´elle se trouve implicitement convertie en 64x64 ( avec les mipmaps et tout le merdier) pour plus d´efficacité. A ce moment utilises plutot le D3DXCreateTextureFromFileEx() avec tous les paramètres ; chez moi ça ressemble à ça :

if ( FAILED(hr = D3DXCreateTextureFromFileEx(pD3DDevice, ( *it).cString(), Sprite::WIDTH, Sprite::HEIGHT, 1, 0, Sprite::TEXTURE_FORMAT,
D3DPOOL_MANAGED, D3DX_DEFAULT, D3DX_DEFAULT, Sprite::COLOR_KEY, NULL, NULL, &)))
{
return DXTRACE_ERR("CreateTextureFromFileEx", hr);
}

ou alors tes params de rendus ne sont pas au poil ; normalement le rect peut etre passé à NULL, mais ça bugue plus ou moins et ça c´est marqué nulle part dans la doc. Donc essaye de passer là encore tous les paramètres, style :

D3DXVECTOR3 center(m_center.x, m_center.y, 0.0f);

RECT rect = { 0, 0, WIDTH, HEIGHT };
LPDIRECT3DTEXTURE9 texture =
TextureLibrary::getInstance().find(m_nTextureID);

HRESULT hr;
if ( FAILED(hr = pD3DSprite->Draw(texture, &, &, &_position, m_blendingColor)))
{
return DXTRACE_ERR("Draw", hr);
}

Et voila la solution
Ma texture n´est pas dans un format à puissance de 2 ( ca me revient maintenant ) et c´est vrai qu´en ce cas, D3DXCreateTextureFromFileEx est préférable.
Merci bien

np, cela dit si tu peux utiliser une texture de puissance 2, tu gagneras en perfs ( léger... ou alors si tu dois les locker) ; dans tous les cas, pour du 2D, utilises toujours la version avec tous les paramètres pour éviter de créer la chaine de mipmaps ( qui en général ne sert à rien dans ces jeux et bouffe de la mem pour rien donc)

Ok

arf les puissances de 2 avec les textures, dis LGV, dans quel cas c´est mieux d´afficher une texture 1024x1024 plutot que repeter 4 fois une 256 ? j veux dire, puisque c´est possible pourquoi ya des gens qui s´évertuent a prendre des grosses tailles ? ça bouffe de la Vram et si on peut repeter la texture ça sert pas a grand chose...

si on peut répéter la texture, on la répete, y´a pas photo. De plus meme si les cartes supportent des hautes résolutions ( 4096x4096 compressé et tout le touintouin), le 256x256 en 16 ou 32 bits restera toujours le plus rapide ( enfin, avec les archis internes actuelles en tout cas).
L´interet d´une grosse texture, c´est que tu peux zoomer dessus sans avoir un gros blur ; maintenant comme c´est moins rapide, on a tendance à automatiser la découpe des textures. Par exemple stockées en 1024x1024 format compressé sur le disque, voire plus, et à l´init de l´appli tu ne crées pas UNE texture par fichier, mais 4, et tu découpes l´image en mémoire : à partir d´une 1024 tu crées 4 textures 256, et tu automatises le mapping de la meme manière.
Au final, si on retient : plus la texture est en haute résolution, meilleure est la qualité, mais plutot qu´afficher une grosse, on prefere afficher plusieurs petites.
A noter que répéter une texture, ça marche bien pour les trucs cycliques ( motifs d´herbe, briques, etc.) mais pour toutes les textures de " détails" ( genre un tag géant sur un mur) il FAUT avoir de la bonne résolution, sinon le rendu s´en ressent fortement.

Petite question encore : comment ce fait il que lorsque j´execute mon application en mode fenêtré, l´image est très légèrement grossie et " blured" alors qu´il n´en est rien en plein écran ?

hmmm... format des backbuffers ?

vérifie que quand le device subit un reset() les surfaces sont bien recréées avec les bons paramètres. Ex, si par défaut tu fais un backbuffer en 800x600, en plein écran 800x600, ça marche nickel ; mais en une fenetre de 1024x768 sur un bureau total de 1600x1200 avec un backbuffer toujours de 800x600 sera grossi donc flou. Quand tu resizes, resizes le backbuffer au format d´affichage.
Je pense que ça vient de là.

Merci, mais c´était une question conne c´est vrai.

Au fait LGV, t´as trouvé du boulot d´après MrGoto ?

yep ; ) j´attends mon contrat d´un jour à l´autre, qui aurait déjà du m´arriver par courrier postal d´ailleurs... En toute logique d´ici 2 semaines je serai donc officiellement engine/tool programmer pour jeux pc & console.

et hmmm on peut savoir chez qui ?

--log

J´allais poser la question également

c´est officieux mais pas officiel, j´attends de recevoir mon contrat pour le signer ; en attendant je n´en dirai pas plus. Quand je serai sur place ce sera autre chose ; )

Cryo.

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHHHHHHHHHHHHHHHHHH ! !!!!!!!!!!!!!!!!!!!!!!

Je plaisante =)