Bin pourtant dans ma doc avec F1 :

Microsoft DirectX 8.1
ID3DXSprite::Draw
Draws a simple sprite in screen-space.

HRESULT Draw(
LPDIRECT3DTEXTURE8 pSrcTexture,
CONST RECT* pSrcRect,
CONST D3DXVECTOR2* pScaling,
CONST D3DXVECTOR2* pRotationCenter,
FLOAT Rotation,
CONST D3DVECTOR2* pTranslation,
D3DCOLOR Color
) ;

Parameters
pSrcTexture
[in] Pointer to an IDirect3DTexture8 interface, representing the source image used for the sprite.
pSrcRect
[in] A pointer to a RECT structure that indicates what portion of the source texture to use for the sprite. If this parameter is NULL, then the entire source image is used for the sprite; however, you can specify a sub-rectangle of the source image instead.
Before transformation, the size of the sprite is defined by pSrcRect with the top-left corner at the origin ( 0,0).

pScaling
[in] Pointer to a D3DXVECTOR2 structure, containing the scaling vector. If this argument is NULL, the value ( 1.0, 1.0) is used. Since pScaling is vector, a multiplier of 1.0 would preserve the source image size.
pRotationCenter
[in] Pointer to a D3DXVECTOR2 structure, containing the point in screen pixels that identifies the center of rotation. If this argument is NULL, the point ( 0,0) is used, which is the upper-left corner of the texture.
Rotation
[in] Value that specifies the rotation in radians, counter-clockwise.
pTranslation
[in] Pointer to a D3DXVECTOR2 structure, containing the translation in screen pixels. If this argument is NULL, the point ( 0,0) is used.
Color
[in] D3DCOLOR type. The color and alpha channels are modulated by this value. A value of 0xFFFFFFFF maintains the original source color and alpha data.
Return Values
If the method succeeds, the return value is D3D_OK.

If the method fails, the return value can be D3DERR_INVALIDCALL.

Remarks
This method must be called between an IDirect3DDevice8::BeginScene and IDirect3DDevice8::EndScene pair.

If ID3DXSprite::Begin has not been called, this method will internally call Begin and ID3DXSprite::End. When making successive calls to ID3DXSprite::Draw and/or ID3DXSprite::DrawTransform, be sure to call Begin to avoid the extra overhead of Draw and DrawTransform internally calling Begin and End each time.

The image can be mirrored by specifying a negative vector in the appropriate direction ( x, y, or both) for the pScaling parameter and adding the width and/or height of the source rectangle, specified in the pSrcRect parameter, to the values specified in the pTranslation parameter. Note that this will change the point of origin for rotations.

Requirements
Header: Declared in D3dx8core.h.
Import Library: Use D3dx8.lib.

See Also
ID3DXSprite::DrawTransform

Je précise qu´en dépit du " Microsoft DirectX 8.1", c´est bien extrait de DirectX9.0b

J´ai regardé sur msdn en ligne... J´ai l´impression que c´est le proto à 5 params qui est le + à jour... Voyez vous-même:

Proto 7 param:
http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/directx9_c/directx/graphics/reference/d3dx/interfaces/id3dxsprite/Draw.asp

" Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist."

Proto 5 param:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/directx9_c/directx/graphics/reference/d3dx/interfaces/ID3DXSprite/Draw.asp

Je viens de voir

D3DXMatrixScaling

Dans la documentation... Je vais essayer ça.

Essaye DrawTransform.
Mais l´avantage de LPDIRECT3DXSPRITE, c´est justement de te passer des matrices

Je trouve pas que c´est un avantage ( sauf peut-être au niveau performance ? ), c´est plutôt facile à utiliser ( les matrices de base, du moins, qui sont fournies avec le SDK).

Malheureusement c´est la version à 7 param qui vient avec DrawTransform.

La matrice de scaling marche bien, l´image grossie comme prévue.

Merci à vous deux, je pense que ça répond à toutes mes question !

lag-it : et si tu prends seulement la doc du SDK de DX, il te dit pareil pour le proto ?
moi je serai tenté de dire que tu as le SDK 9.0b d´AVANT le Summer Update 2003, qui a justement apporté pas mal de modifs à ID3DXSPRITE. Si c´est le cas, il parait ( je n´utilisais pas avant, donc je ne peux pas comparer) que les perfs se sont GRANDEMENT amélioré entre les deux, donc tu peux p-e y gagner :-?

techslash : matrice ou pas, moi je trouve zarb que dans le draw on ne garde que 2 transfos sur trois ( rotation/scaling/translation) : ou bien il fallait garder les 7 params, ou alors tout passer via la SetTransform pour rester cohérent. Là il faut utiliser les params du draw pour la position et le scaling et le transform pour la rotation, j´ai trouvé ça bizarre mais apparement c´est prévu pour fonctionner comme ça

Par curiosité...

Est-ce que la version de ID3DXSPRITE avant la summer update supporte le color keying pour la transparence ?

Parce que la dernière version ne le fait pas, le color keying de D3DXCreateTextureFromFileEx remplace tout les pixels d´une couleur ARGB en noir transparent ( ce qui, je suppose, veut dire noir avec un alpha de 0). Conséquemment, il faut faire de l´alpha blending. Superbe casse-tête, les explications à ce sujet étant absente d´msdn .

Oui, je dois avoir une version pré-summer update 2003

Et oui, ID3DXSPRITE supporte le color keying pour la transparence.
Mais c´est bizarre d´avoir à faire de l´alpha-blending, y pas une autre méthode

Pour une fois que je trouvais DirectX très accessible pour les débutants, voila qu´ils nous suppriment des paramètres qui facilifiaient la vie et qu´il posent des problèmes de transparence...

ben il se trouve qu´avant le Summer Update, le Draw était en fait un Blit sélectif, le masque étant défini par la colorkey ; seulement ça coûte pas mal en perf, puisque le blitter doit tester les pixel pour s´avoir s´il doit les afficher ou pas ; de plus ça peut poser pb si le sprite est scalé. Donc leur idée retenue dans la derniere implémentation, pour améliorer la rapidité, c´est effectivement de substituer à la création de la texture les pixels correspondants à la colorkey par du noir. Du coup pour arriver au meme résultat, il n´y a plus qu´à faire une des unités de texturing plutot qu´un blitter, ce qui s´avère TRES intéressant en terme d´efficacité ( surtout à partit des GF3 en fait). Mais bon evidémment, pour pas que le noir s´affiche, faut blender : et comme c´est du noir en alpha 0, sa contribution est de zéro.
Donc c´est principalement pour utiliser une autre partie de l´archi interne, plus rapide, que le blit a été remplacé par un texturing standard.

M´enfin, bonne chance pour blender pour une personne qui s´y connait pas. Tout les guides, articles et tuto du net parle de la version avant la summer update 2k3. J´avance par tatonnement. Je remplace une couleur par du noir alpha 0 sans problème sauf que le blending refuse de se faire, peut importe les renderstates que je mets ( autrement dit le noir " transparent"/cgn´est pas transparent du tout).

/ cg ? ! Qu´est-ce que c´est que cette faute de frappe qui est apparue toute seule ? lol

ben comme l´interface ID3DXSPRITE gère ses propres renderstates ( une partie seulement, un peu comme pour les matrices : celles habituelles n´ont pas d´influence sur les sprites), tu dois utiliser les params du Begin ; chez moi ça ressemble à :

if ( FAILED(hr = m_pd3dSprite->Begin(D3DXSPRITE_ALPHABLEND)))
{
return DXTRACE_ERR("Begin", hr);
}

pis ensuite les Draw normaux

Urgh, merci beaucoup, tu as raison, 1 heure d´essai et erreur avec les renderstates pour finalement toutes les enlever . J´ai un peu de mal à comprendre, j´avais déjà ce paramètre dans Begin ( en plus de D3DXSPRITE_SORT_DEPTH_BACKTOFRONT que j´ai ajouté parce que MSDN parle de sorting de sprite avec transparence). Je pense que le problème venait ou bien d´un begin mal fait ( j´avais p-e utilisé un autre opérateur que | par accident ? ), d´une image qui ne faisait pas l´affaire ( j´ai changé la texture avec laquelle je test pour un mega-man ) ou alors du clear du device que j´ai modifié hier et qui ne semblait pas plair au programme ( du garbage en fond d´écran au lieu d´une couleur unie).

Quoiqu´il en soit, merci beaucoup !

J´aurais une nouvelle question, si un programme doit avoir des sprites qui passent l´une devant l´autre ( en 3D on dirait deux valeurs de Z différentes), qu´elle est la méthode propre pour gérée qu´elle image est en avant et quelle est en arrière ? Je pense que c´est une question d´ordre dans lequel les ´draw´ sont fait ? Est-ce que c´est l´utilité des paramètres de sorting ( ex.: D3DXSPRITE_SORT_DEPTH_BACKTOFRONT) ?

Merci encore et encore et toujours

Oui c´est fonction de l´ordre d´apparition des draw.
Donc pour un jeu de plateformes par exemple, commence par afficher les tiles du background, puis les tiles du décors et enfin les " entitées" ( héro, monstres, . .. )

t´as beau manipuler des sprites 2D, ce n´est qu´une restriction du monde 3D de D3D, donc tes sprites ONT un positionnement selon l´axe de profondeur.
Le param du begin te permet de trier facilement, donc ça fait exactement ce que tu veux ; si tu peux remplacer par une gestion maison sous forme de layers, c´est encore mieux : tu éviteras de demander à DX de te trier tes polygones en les fournissant toi meme dans l´ordre qui va bien pour ton affichage.
En général, dans un jeu 2D tu vas avoir 1 ou plusieurs plans de background ( pour du scrolling différentiel par exemple), 1 plan de jeu dans lequel évolue le perso, et 1 plan de foreground, pour faire qq petits effets sympas ; vient ensuite l´interface. Donc avec qqch comme 5 layers, tu dois pouvoir facilement gérer l´ordre d´affichage.

LOL, c´est fort, avec lag-it on se débrouille tout le temps pour répondre en meme temps on dirait ; )

Et bien je n´ai plus de questions ! Merci beaucoup, votre aide ( et votre patience ) a été précieuse.

Ouaip ^^

Sauf que moi c´est les méthodes simples ( bêtes ? )

Hey hey, le vieux topic est de retour !

Je viens de me casser les dents sur un problème pour lequel je ne trouve pas de solution.

J´ai une fenêtre 480x480...

HWND hWnd = CreateWindow( " DXFramework", " DXFramework", WS_OVERLAPPEDWINDOW, 100, 100, 480, 480, GetDesktopWindow(), NULL, wc.hInstance, NULL ) ;

Dans laquelle je charge une sprite 480x480...
D3DXCreateTextureFromFileEx(g_pd3dDevice, " background.png", 480, 480, D3DX_DEFAULT, D3DUSAGE_RENDERTARGET, D3DFMT_A8R8G8B8, D3DPOOL_DEFAULT, D3DX_DEFAULT, D3DX_DEFAULT, D3DCOLOR_ARGB(255,0,255,0), NULL, NULL, &_pd3dTexture)

Et que je dessine...
g_pd3dSprite->Draw(g_pd3dTexture, &, &3DXVECTOR3(0.0f, 0.0f, 0.0f) , &3DXVECTOR3(0.0f, 0.0f, 0.0f), D3DCOLOR_ARGB(255,255,255,255))

Pour une raison que j´ignore, on morceau de l´image est coupé ( à droite). Un peu comme si la caméra avait zoomé, si un scaling avait eu lieu ( parce qu´en changeant les coordonnées de l´image dans le draw, je peux manuellement recentrer le tout). Pourquoi est-ce que je n´ai pas un ratio 1:1 texture/ce qui est affiché par mon programme ? Je ne vois pas ce qui peut causer ça.

Je pense que ça pourrait avoir lien avec le vidage des buffers alors voici la ligne concernée, au cas où...
g_pd3dDevice->Clear(0, NULL, D3DCLEAR_TARGET, D3DCOLOR_ARGB(255, 0, 0, 155), 1.0f, 0)

Ça ne vient pas non plus de mon rectangle ( rectTexture) dans le draw...
RECT rectTexture;
rectTexture.bottom = 480;
rectTexture.left = 0;
rectTexture.right = 480;
rectTexture.top = 0;

• Je sais que c´est une façon un peu longue de remplir un objet, je l´ai fait comme ça pour m´assurer que les données étaient les bonnes.

Merci d´avance !