Discussion :

[bad_g]

Bonjour,

je débute en assembleur et je voudrais connaitre la démarche pour afficher un sprite.

Malgres mes recherches je ne trouve pas d'explication claires.
J'ai trouvé un logiciel "sprite-wizard" mais je ne sais pas trop comment m'en servir...

merci d'avance pour votre aide.

[Stabia]

Quelle machine, quel système ....

[bad_g]

je travaille sous win XP avec un pc intel

[Stabia]

Il me semble, pour aller au plus simple (si l'on peut dire) qu'en premier il vous faut récupérer l'adresse des données d'un "BITMAP" sélectionné dans un "DC" ; cela c'est assez simple.
Ensuite, et je pense que c'est l'objet de votre question, il faut "coller" vos données dans la portion de mémoire ad hoc.
Imaginons que vous soyez dans un mode 32 bits par pixels vos données sont organisées sous la forme de nl. lignes de np. pixels (pour faire simple on va admettre que np. est un multiple de 4).
En mémoire cela donne une suite d'octets ainsi fait :
ligne 1 : B V R A (pixel 1) B V R A (pixel 2) ... B V R A (pixel np)
ligne 1 : B V R A (pixel 1) B V R A (pixel 2) ... B V R A (pixel np)
ligne nl : B V R A (pixel 1) B V R A (pixel 2) ... B V R A (pixel np)

R, V et B sont des octets correspondant à la quantité de Rouge, de Vert et de Bleu pour chaque pixel, A (alpha) est d'un usage libre mais est généralement utilisé pour donner un indice de transparence.

Il est aisé de calculer le premier pixel de copie dans le "BITMAP" de l'écran, attention cependant à bien sauter au pixel d'en dessous au changement de ligne (cela dépend de la largeur de votre calque, et aussi de ...).

Vous allez dans un premier temps copier les pixels du "BITMAP" de l'écran dans un tampon de sauvegarde qui vous permettra de restituer le fond d'origine.
Puis ensuite vous aller copier vos données dans le même emplacement.
Il est plus rapide de faire les deux opérations dans la même boucle.

Mais me direz-vous si mon motif à des trous je détruit mon fond, et oui !
La solution passe par la définition d'un masque ou bien d'une couleur de transparence, ou bien d'un indicateur dans le plan A de votre motif.
Ensuite il suffit de tester et de ne rien copier lorsque un trou est prévu, en revanche je vous conseille de sauvegarder toute la partie recouverte ainsi au moment de la restitution il n'y a aucun test de transparence à effectuer.

Bon courage.

[bad_g]

En mémoire cela donne une suite d'octets ainsi fait :
ligne 1 : B V R A (pixel 1) B V R A (pixel 2) ... B V R A (pixel np)
ligne 1 : B V R A (pixel 1) B V R A (pixel 2) ... B V R A (pixel np)
ligne nl : B V R A (pixel 1) B V R A (pixel 2) ... B V R A (pixel np)

donc ca c'est une généralisation d'une adresse de donnée d'un bitmap, que je peux recupérer avec "sprite-wizard" ?

mais le code d'affichage du sprite ca serait quoi? à moins que ce dernier ne se limite qu'à l'adresse du bitmap....?

[Stabia]

Je ne connais pas "sprite-wizard", pour le reste j'essaye de vous mettre sur la voie ...

Mais peut être que le lieu (forum assembleur) n'est pas le plus approprié pour connaître une solution à votre problème.

En tout cas sous XP, a moins de vous compliquer énormément la vie, je ne vois pas d'autres solution que de passer par les fonctions GetDC(), SelectObject, etc.

[edfed]

pour afficher une image, il faut avoir des pointeurs:
un pointeur par dimension a traiter.
un image possede quatres dimensions:
X,Y,XL,YL
l'ecran aussi
donc, il faut bosser avec 8 pointeurs au minimum
en bossant avec le monde purement monodimentionel de la memoire, on peu se contenter de 2 pointeurs, chacun contient le traitement des dimensions en une seule valeur.

par exemple, la memoire ecran est en une dimension, n° de pixel.
l'image aussi.
les compteurs servent a sortir des boucles de traitement.
une boucle=une dimension.
et là aussi on peu compresser et croiser les boucles pour rendre l'algorythme encore plus performant.
puis il y a l'acceleration materielle 2D et 3D qui permet de plaquer des images en quelques instructions. au lieu de faire l'algorythme pour le µP X86, on le fait pour la carte graphique.
mais pour debuter, il vau mieu le faire en ecrivant sur l'ecran 13h 320*200*8 bits.
c'est plus simple, ça permet de comprendre la copie de tableaux et d'autres choses.

ça fonctionne sous WIN9X, WINXP, M$DO$, miniDOS, etc...
mais pas sous VI$ta , :-(

[Stabia]

'edfed' à raison lorsqu'il dit que des fonctions graphiques élaborées (logico-matérielles) permettent de faire ce que vous voulez, mais cela dépend de ce que vous voulez exactement, et puis il vaut toujours mieux comprendre...
Dans l'un de mes logiciel je fus confronté à l'inclusion de mires de formes variées , ayant des comportements particuliers dans deux images vidéo et servant de trame de corrélation ... bref c'est un cas où l'on est bien obligé de mettre les mains dans le charbon. Les fonctions d'accélérations des cartes sont toutes orientées vers les jeux (rendu 3D).
En revanche je ne suis pas de l'avis de 'edfed' lorsqu'il parle de ses 8 pointeurs.
Deux suffisent 'edi' et 'esi', il faut ensuite connaître le solde d'octets dans les lignes de données et de résultats ; il suffit d'ajouter ce solde à la valeur courante des pointeurs à chaque ligne. Bien entendu au début il faut :

xDst, yDst, lgDst, [htDst], [xSrc = 0], [ySrc = 0], lgSrc, htSrc

entre [] ce qui n'est pas indispensable.
il faut aussi savoir si 'Src' et 'Dst' sont en 24 ou 31bits/pixels (ou 8, ou 16!).

Essayez de coder à partir de cela, et, si vous le voulez, montrez-nous votre code.

[edfed]

lorsque je parle de 8 pointeurs, je parle de pointeur effectif, pas de pointeur reel.

les huits pointeurs sont les valeurs de base à exploiter.