afficher un sprite a l'envers - Page 1

hello world!
Je cherche le moyen d'afficher un sprite a l'envers, pour eviter de devoir enregistrer plein d'images en double (par exemple lorsque qu'un personnage fait un pas a gauche, puis a droite). C'est possible ?

Oui, mais très lent.
Ce que je te conseille, c'est de "dessiner" ton sprite inversé au lancement de ton programme dans un buffer, et d'aller le chercher là ensuite pour l'afficher avec une fonction d'affichage de sprite classique.

ya pas moyen de creer un genre de sprite16 qui affiche les images directement a l'envers ?

Si.
Mais c'est lent...

EDIT : oups j'avais pas vu qu'il parlait de miroir horizontal

oui c'est très lent, à vue de nez un peu plus de 12 cycles par pixel noir&blanc en plus, donc ça divise par 3 la vitesse de ta routine ^^ et tu n'iras pas significativement plus vite en faisant une routine spéciale qu'en mettant le miroir du sprite dans un buffer juste avant de le tracer...

J'ai une fonction si tu veux
Utilisez pour Nebulus, très rapide, focntionne sur des sprites de 32x32 mais aussi 16x16... avec utilisation d'une table précalculée. Le principe est simple, suffit d'utiliser un buffer, d'inverser le sprite et de le copier dans ce buffer, la routine ce charge de ça, ensuite afficher le buffer à l'écran avec le sprite inversé. Pour gagner des ressources tu peux tester si le sprite doit être inversé ou non.

ya pas moyen de creer un genre de sprite16 qui affiche les images directement a l'envers

Il y a des fonctions de ExtGraph qui font ça non ?

non à ma connaissance.

Ta fonction est plus rapide qu'en utilisant la methose de Sasume ? Parce qu'on dirait la meme. En tout cas, ca pourrait etre interessant.
Je precise que j'aimerais utiliser des sprites en niveaux de gris, donc ca devrait etre pire...

Voici la fonction en ASM pour des spirtes de 32x32:
Maintenant tout dépend du format de ton sprite, pour ma part entrelacé de cette façon:
line0: mask
line1: lightplane
line2: darkplane
...

La fonction est simple, h=hauteur du sprite en pixel, src=sprite à renverser, dest=buffer avec le sprite renversé.
Si tu me donne la taille des sprites à renverser suivant x et le format, je pourrais modifier cette routine.

| C prototype: void GraySprite32_FLIPV (register short h asm("%d2"), register void *sprt asm("%a0"), register void *dest asm("%a1"));

.data
.globl GraySprite32_FLIPV
.even

GraySprite32_FLIPV:
    dbf      %d2,__Rest_of_GraySprite32_FLIPV
    rts

__Rest_of_GraySprite32_FLIPV:
    move.l   %a2,-(%sp)
    move.l   %d3,-(%sp)
    lea.l    tbl_flipv(%PC),%a2
    
__Loop_GraySprite32_FLIPV:
    moveq.l  #0,%d3
    moveq.l  #0,%d1
    move.l   (%a0)+,%d0
    
    |Partie n°1
    move.b   %d0,%d1
    move.b   0(%a2,%d1.w),%d3
    rol.l    #8,%d3
    lsr.l    #8,%d0
    
    |Partie n°2
    move.b   %d0,%d1
    move.b   0(%a2,%d1.w),%d3
    rol.l    #8,%d3
    lsr.l    #8,%d0
    
    |Partie n°3
    move.b   %d0,%d1
    move.b   0(%a2,%d1.w),%d3
    rol.l    #8,%d3
    lsr.l    #8,%d0
    
    |Partie n°4
    move.b   %d0,%d1
    move.b   0(%a2,%d1.w),%d3
    
    move.l   %d3,(%a1)+
    dbf      %d2,__Loop_GraySprite32_FLIPV
    
    move.l   (%sp)+,%d3
    move.l   (%sp)+,%a2
    rts


tbl_flipv:
	.byte	0b00000000
	.byte	0b10000000
	.byte	0b01000000
	.byte	0b11000000
	.byte	0b00100000
	.byte	0b10100000
	.byte	0b01100000
	.byte	0b11100000
	.byte	0b00010000
	.byte	0b10010000
	.byte	0b01010000
	.byte	0b11010000
	.byte	0b00110000
	.byte	0b10110000
	.byte	0b01110000
	.byte	0b11110000
	.byte	0b00001000
	.byte	0b10001000
	.byte	0b01001000
	.byte	0b11001000
	.byte	0b00101000
	.byte	0b10101000
	.byte	0b01101000
	.byte	0b11101000
	.byte	0b00011000
	.byte	0b10011000
	.byte	0b01011000
	.byte	0b11011000
	.byte	0b00111000
	.byte	0b10111000
	.byte	0b01111000
	.byte	0b11111000
	.byte	0b00000100
	.byte	0b10000100
	.byte	0b01000100
	.byte	0b11000100
	.byte	0b00100100
	.byte	0b10100100
	.byte	0b01100100
	.byte	0b11100100
	.byte	0b00010100
	.byte	0b10010100
	.byte	0b01010100
	.byte	0b11010100
	.byte	0b00110100
	.byte	0b10110100
	.byte	0b01110100
	.byte	0b11110100
	.byte	0b00001100
	.byte	0b10001100
	.byte	0b01001100
	.byte	0b11001100
	.byte	0b00101100
	.byte	0b10101100
	.byte	0b01101100
	.byte	0b11101100
	.byte	0b00011100
	.byte	0b10011100
	.byte	0b01011100
	.byte	0b11011100
	.byte	0b00111100
	.byte	0b10111100
	.byte	0b01111100
	.byte	0b11111100
	.byte	0b00000010
	.byte	0b10000010
	.byte	0b01000010
	.byte	0b11000010
	.byte	0b00100010
	.byte	0b10100010
	.byte	0b01100010
	.byte	0b11100010
	.byte	0b00010010
	.byte	0b10010010
	.byte	0b01010010
	.byte	0b11010010
	.byte	0b00110010
	.byte	0b10110010
	.byte	0b01110010
	.byte	0b11110010
	.byte	0b00001010
	.byte	0b10001010
	.byte	0b01001010
	.byte	0b11001010
	.byte	0b00101010
	.byte	0b10101010
	.byte	0b01101010
	.byte	0b11101010
	.byte	0b00011010
	.byte	0b10011010
	.byte	0b01011010
	.byte	0b11011010
	.byte	0b00111010
	.byte	0b10111010
	.byte	0b01111010
	.byte	0b11111010
	.byte	0b00000110
	.byte	0b10000110
	.byte	0b01000110
	.byte	0b11000110
	.byte	0b00100110
	.byte	0b10100110
	.byte	0b01100110
	.byte	0b11100110
	.byte	0b00010110
	.byte	0b10010110
	.byte	0b01010110
	.byte	0b11010110
	.byte	0b00110110
	.byte	0b10110110
	.byte	0b01110110
	.byte	0b11110110
	.byte	0b00001110
	.byte	0b10001110
	.byte	0b01001110
	.byte	0b11001110
	.byte	0b00101110
	.byte	0b10101110
	.byte	0b01101110
	.byte	0b11101110
	.byte	0b00011110
	.byte	0b10011110
	.byte	0b01011110
	.byte	0b11011110
	.byte	0b00111110
	.byte	0b10111110
	.byte	0b01111110
	.byte	0b11111110
	.byte	0b00000001
	.byte	0b10000001
	.byte	0b01000001
	.byte	0b11000001
	.byte	0b00100001
	.byte	0b10100001
	.byte	0b01100001
	.byte	0b11100001
	.byte	0b00010001
	.byte	0b10010001
	.byte	0b01010001
	.byte	0b11010001
	.byte	0b00110001
	.byte	0b10110001
	.byte	0b01110001
	.byte	0b11110001
	.byte	0b00001001
	.byte	0b10001001
	.byte	0b01001001
	.byte	0b11001001
	.byte	0b00101001
	.byte	0b10101001
	.byte	0b01101001
	.byte	0b11101001
	.byte	0b00011001
	.byte	0b10011001
	.byte	0b01011001
	.byte	0b11011001
	.byte	0b00111001
	.byte	0b10111001
	.byte	0b01111001
	.byte	0b11111001
	.byte	0b00000101
	.byte	0b10000101
	.byte	0b01000101
	.byte	0b11000101
	.byte	0b00100101
	.byte	0b10100101
	.byte	0b01100101
	.byte	0b11100101
	.byte	0b00010101
	.byte	0b10010101
	.byte	0b01010101
	.byte	0b11010101
	.byte	0b00110101
	.byte	0b10110101
	.byte	0b01110101
	.byte	0b11110101
	.byte	0b00001101
	.byte	0b10001101
	.byte	0b01001101
	.byte	0b11001101
	.byte	0b00101101
	.byte	0b10101101
	.byte	0b01101101
	.byte	0b11101101
	.byte	0b00011101
	.byte	0b10011101
	.byte	0b01011101
	.byte	0b11011101
	.byte	0b00111101
	.byte	0b10111101
	.byte	0b01111101
	.byte	0b11111101
	.byte	0b00000011
	.byte	0b10000011
	.byte	0b01000011
	.byte	0b11000011
	.byte	0b00100011
	.byte	0b10100011
	.byte	0b01100011
	.byte	0b11100011
	.byte	0b00010011
	.byte	0b10010011
	.byte	0b01010011
	.byte	0b11010011
	.byte	0b00110011
	.byte	0b10110011
	.byte	0b01110011
	.byte	0b11110011
	.byte	0b00001011
	.byte	0b10001011
	.byte	0b01001011
	.byte	0b11001011
	.byte	0b00101011
	.byte	0b10101011
	.byte	0b01101011
	.byte	0b11101011
	.byte	0b00011011
	.byte	0b10011011
	.byte	0b01011011
	.byte	0b11011011
	.byte	0b00111011
	.byte	0b10111011
	.byte	0b01111011
	.byte	0b11111011
	.byte	0b00000111
	.byte	0b10000111
	.byte	0b01000111
	.byte	0b11000111
	.byte	0b00100111
	.byte	0b10100111
	.byte	0b01100111
	.byte	0b11100111
	.byte	0b00010111
	.byte	0b10010111
	.byte	0b01010111
	.byte	0b11010111
	.byte	0b00110111
	.byte	0b10110111
	.byte	0b01110111
	.byte	0b11110111
	.byte	0b00001111
	.byte	0b10001111
	.byte	0b01001111
	.byte	0b11001111
	.byte	0b00101111
	.byte	0b10101111
	.byte	0b01101111
	.byte	0b11101111
	.byte	0b00011111
	.byte	0b10011111
	.byte	0b01011111
	.byte	0b11011111
	.byte	0b00111111
	.byte	0b10111111
	.byte	0b01111111
	.byte	0b11111111

Sinon, il y a toujours ma méthode (shifts LIFO) pour inverser:
* un octet (8 bits):

unsigned char reverse_byte(unsigned char b asm("d1"));
asm("
.globl reverse_byte
reverse_byte:
moveq.l #7,%d2
0:
add.b %d1,%d1
roxr.b #1,%d0
dbra.w %d2,0b
rts");

* un word (16 bits):

unsigned short reverse_word(unsigned short s asm("d1"));
asm("
.globl reverse_word
reverse_word:
moveq.l #15,%d2
0:
add.w %d1,%d1
roxr.w #1,%d0
dbra.w %d2,0b
rts");

* un long (32 bits):

unsigned long reverse_long(unsigned long l asm("d1"));
asm("
.globl reverse_long
reverse_long:
moveq.l #31,%d2
0:
add.l %d1,%d1
roxr.l #1,%d0
dbra.w %d2,0b
rts");

(Tout ceci pouvant s'utiliser à l'intérieur d'une routine de sprites.)
C'est ce qu'il y a de plus compact (taille du code), mais c'est aussi relativement lent.

bit à bit #beurk#

On peut aussi faire comme les fonctions d'affichage de AMS et appeler DrawPix pour chaque pixel du sprite. Ça permet aussi d'afficher "à l'envers". Bref, on peut faire encore plus lent que mon code.

Ouai et pourquoi pas ajouter une temporisation entre chaque pixel tant qu'on y est.

darkein> Le code de geogeo est plus rapide que l'idée que j'avais de calculer pixel par pixel le flipping (chose qui prendrait moins de place, comme l'a précisé Kevin), mais est quand même très lente par rapport à l'appel d'une fonction de sprite non flippé.
Donc je te conseille très fortement de calculer le sprite après flipping dans un buffer et de l'afficher ensuite comme un sprite normal.
Cela dit, pour des sprites 16x16, il y a moyen de faire plus rapide, je pense. Et pour les sprites 8x8 encore plus.

bon, ben je te le dis, c'est pour des sprites 16*16. Par contre, je peux integrer et utiliser ca directement dans mon programme en C, ou est-ce que je dois changer quelque chose? Je n'ai jamais inseré d'asm dans un programme C...

Ca fait drole de voir des routines dans un autre asm que le 80x86
En gros la méthode de geogeo ca revient à inverser chaque octet en allant chercher l'octet correspondant dans une table, ou bien j'ai vraiment pas capté?

C'est vrai que moi jusqu'ici je codais tous mes sprites en double (gauche/droite) en me disant que ct le plus efficace, mais faudra pitet que je revois ca un jour

Orwell :
Ca fait drole de voir des routines dans un autre asm que le 80x86
En gros la méthode de geogeo ca revient à inverser chaque octet en allant chercher l'octet correspondant dans une table, ou bien j'ai vraiment pas capté?

oui c'est ça, de mémoire c'est ce qui est aussi fait dans genlib

C'est vrai que moi jusqu'ici je codais tous mes sprites en double (gauche/droite) en me disant que ct le plus efficace, mais faudra pitet que je revois ca un jour

bah coder les sprites en double sera toujours plus rapide que de les inverser en live, un bon compromis serait de les inverser à l'initialisation du programme, mais là faut faire un choix par exemple entre perdre de la place en flash ou en ram... perso je préfère avoir les sprites en double et archivés.

a

Ximoon
:un bon compromis serait de les inverser à l'initialisation du programme, mais là faut faire un choix par exemple entre perdre de la place en flash ou en ram... perso je préfère avoir les sprites en double et archivés.

Les sprites que j'utilise sont de toute facon chargés de la flash vers la ram... Donc ca me permettrait sans doute de gagner un peu de place en flash; maintenant ca fait encore du chipotage, faut voir si c utile ou pas

Perso j'ai toujours utilise massivement l'inversion des sprites en temps reel, et ca n'est franchement pas visible.

ah, c'est pour ça que SMA est si lent

Nan. Parce que 92+ HW1 est lente et que je veux pas que ca soit + rapide pour les autres
(Sinon je peux doubler le FPS sans pb, surtout avec la prochaine version de genlib ou ca sera double d'office - ca devrait fonctionner a 30 sur ma 92+HW1 a piles nazes).

SMA est déjà trop rapide! Beaucoup trop rapide même!

en même temps, ct un peu le but, non, aussi ?

PpHd :
Nan. Parce que 92+ HW1 est lente et que je veux pas que ca soit + rapide pour les autres (Sinon je peux doubler le FPS sans pb, surtout avec la prochaine version de genlib ou ca sera double d'office - ca devrait fonctionner a 30 sur ma 92+HW1 a piles nazes).

On l'attent tjrs ^^

LOL Kevin ... Imagine ce que serait SMA lent pour voir

pphd: héhé, c afait pas mal de temps en effet qu'on l'attend celle-ci ^^

Oue mais j'ai toujours plein de choses a faire. Mais vous pouvez me faire confiance. Ca sortira.

ouai comme Xlibv2

Desole je m'en occupe aussi. Ca sortira lorsque j'aurai le temps. j'adore raconter des conneries. ouou, lecteur, me lis-tu ?

dis Geogeo, tu pourrais faire la meme fonction mais pour des sprites de taille 16*16 ?