> Elles sont trop lentes pour la machine.
Ben écoute, fais donc (c'est valable aussi pour TiMad) beaucoup mieux que ça en __stkparm__ (les versions __regparm__(n) arrivent, ne vous en faites pas) sans dérouler les boucles:
| C prototype: void Sprite16_OR(short x,short y,short h,unsigned long* sprite,void* dest) __attribute__((__stkparm__));
.data
.globl _Sprite16_OR
.even
_Sprite16_OR:
move.w 0+4+0(%sp),%d0
move.w 0+4+2(%sp),%d1
movea.l 0+4+6(%sp),%a1
move.w %d1,%d2
lsl.w #4,%d1
sub.w %d2,%d1
move.w %d0,%d2
lsr.w #4,%d0
add.w %d1,%d0
add.w %d0,%d0
movea.w %d0,%a0
adda.l 0+4+10(%sp),%a0
andi.w #0xF,%d2
moveq #16,%d1
sub.w %d2,%d1
move.w 0+4+4(%sp),%d2
bra.s __loop_Sprite16_OR
_loop_Sprite16_OR:
moveq #0,%d0
move.w (%a1)+,%d0
lsl.l %d1,%d0
or.l %d0,(%a0)
lea 30(%a0),%a0
__loop_Sprite16_OR:
dbf %d2,_loop_Sprite16_OR
rts
OK, comme vous aurez pu le voir, c'est la routine pour la prochaine version d'ExtGraph. Mais la routine C actuelle est moins de 10% plus lente. Les Sprite16_nnn sont les routines où les gains sont les plus faibles (à part la AND, l'algorithme a été changé et on gagne un peu moins de 20

, car l'algorithme en C est bon.
En revanche, sur les Sprite32_nnn, les gains sont aux alentours de 30%; sur les Sprite8_nnn, les gains sont aux alentours de 20% (sauf AND qui elle aussi a bénéficié d'une modification d'algorithme); SpriteX8_OR (contribuée par Ximoon) est 57% plus rapide d'après ce que m'a dit jackiechan. Tout ça sans dérouler les boucles.
Je commence vraiment à avoir marre de répéter ce que je dis à des gens bornés qui n'écoutent pas.
Bien sûr, je poste le principe du bench, parce que sinon je vais encore me faire accuser de ne pas poster des benchs par des personnes qui ne le font pas eux-mêmes:
for (i = 239-[horizontal_size_of_sprite]+1; (i--)

{
for (j = 127-[horizontal_size_of_sprite]+1; (j--)

{
[call_to_routine]
}
}
> Ben elles ne s'en sortent pas si mal je trouve.
Ca fait plaisir de voir qu'il y en a qui sont contents...