Fast pixel routine - Page 3

Vous n'aviez pas une vrai table ici ? Je dois vraiment vous filer celle piquée d'un bouquin ? quelqu'un ici connait-il toutes les instructions ou vous faîtes semblant ?

lol conneries sur conneries faut m'excuser... j'ai fait un ptit melange de addq moveq.. qui elle utilise 1 octet signé donc de -2^8 à 2^8-1

Sinon:
[I]Whouaa TImad tu m'étonnes :
- addq et subq n'admettent en opérande source que des valeurs entre 1 et 8
[/I]
Etant donné que addq est définit que sur 3 bits.. on vas de 2^0+1 à 2^3 donc de 1 à 8, foudiou je dit vraiment des conneries mais c'est pas grave ca me plait
[I]
- lsl.w #6,dn bouffe BIEN PLUS que 6 cycles : 6 + 2*6 = 18 cycles
[/I]
ok

Non mais de toute maniere je sais pas encore quel technique je vais utilisé donc bon on vera bien ce qui est sur c'est que je vais adopter un technique que personne n'a encore uilise, car je ne vois pas l'utilite de programme qqc qui a deja ete fait... on vera bien

HerveRV:
Oui.. c'est pour ca que dans toute bonne routine de sprite, on teste le nombre de shift que l'on a a faire cmp... puis on ajuste en fonction du nombre de shift ... ce qui permet d'avoir une routine plutot equilibre au niveau du nombre de c/S pour n'importe quel x.. contrairement a certaines routines

Il y a une table des cycles à http://perso.wanadoo.fr/ti92-ti89.miclo/asm/resources/m68ktime.txt.
[edit]Edité par Kevin Kofler le 07-11-2001 à 21:40:10[/edit]

En version htm http://www.citeweb.net/MilesSite/shared/a68k/s10.htm
ou en français http://www.citeweb.net/MilesSite/communs/a68k/s10.htm

je savais que le 68000 était pas doué pour certains trucs, mais je pensais pas que même ça faut s'en méfier !

Je remets le topic au sommet.
Est-ce que ces routines qui marchent avec TIGCC sont les plus rapides possibles, SANS UTILISER DE PRECALCULE ?

// Sensibilité à PortSet.
void FastSetPixPort(short x,short y);
asm("xdef FastSetPixPort
FastSetPixPort:
move.w %d0,-(%sp)
move.w %d1,-(%sp)
pea (%a0)
pea (%a1)
move.w 16(%sp),%d0
move.w 18(%sp),%d1
add.w %d1,%d1
move.w %d1,%a0
lsl.w #4,%d1
sub.w %a0,%d1
move.w %d1,%a0
move.l 0x78C0,%a1
add.l %a1,%a0
move.w %d0,%d1
lsr.w #3,%d0
not.b %d1
bset.b %d1,0(%a0,%d0.w)
move.l (%sp)+,%a1
move.l (%sp)+,%a0
move.w (%sp)+,%d1
move.w (%sp)+,%d0
rts
")

// Plane en tant qu'argument
void FastSetPixPass(void *plane,short x,short y);
asm("xdef FastSetPixPass
FastSetPixPass:
move.w %d0,-(%sp)
move.w %d1,-(%sp)
pea (%a0)
move.w 16(%sp),%d0
move.w 18(%sp),%d1
add.w %d1,%d1
move.w %d1,%a0
lsl.w #4,%d1
sub.w %a0,%d1
move.w %d1,%a0
add.l 12(%sp),%a0
move.w %d0,%d1
lsr.w #3,%d0
not.b %d1
bset.b %d1,0(%a0,%d0.w)
move.l (%sp)+,%a0
move.w (%sp)+,%d1
move.w (%sp)+,%d0
rts
")

// Version grayscale de la routine précédente.
void FastSetGrayPix2B(void *light,void *dark,short x,short y);
asm("xdef FastSetGrayPix2B
FastSetGrayPix2B:
move.w %d0,-(%sp)
move.w %d1,-(%sp)
pea (%a0)
pea (%a1)
pea (%a2)
move.l 20(%sp),%a0
move.l 24(%sp),%a1
move.w 28(%sp),%d0
move.w 30(%sp),%d1
add.w %d1,%d1
move.w %d1,%a2
lsl.w #4,%d1
sub.w %a2,%d1
add.l %d1,%a0
add.l %d1,%a1
move.w %d0,%d1
lsr.w #3,%d0
not.b %d1
bset.b %d1,0(%a0,%d0.w)
move.l (%sp)+,%a2
move.l (%sp)+,%a1
move.l (%sp)+,%a0
move.w (%sp)+,%d1
move.w (%sp)+,%d0
rts
")

Les routines d'inversion, d'effacement et de test de pixel doivent logiquement se déduire de celles-ci en changeant bset en respectivement bchg, bclr et btst.

Non. Ca repond a la question ?
Et puis t'as des macros dans extgraph bien plus efficases.

je l'ai pas déjà dit quelque part que Extgraph était powerful pr les pixels ?

Ce sont des macros : des qu'une valeur vaut un entier, ou si les entiers suivent une logique lineaire, ca optimise tres bien.

oué...

Mais si la couleur change tout le temps aleatoirement, tout comme les coordonnees, c'est les memes perfs qu'avec genlib.

arf... je me disais aussi que tu laisseair pas passer ça

Evidememnt que non;

héhé

c entierement normal, vu que toutes les routines se ressemblent très étrangement !

je crois que, arrivé à un certain niveau d'optimisation, c dur d'optimiser plus ss changer de routine...
ET le plus dur, c de trouver la routine en question...

Erf pour ceux qui n'auraient toujours rien compris... quand on veut opitmiser un routines, on optimise d'abord l'algo puis ensuis les instructions....

Mais bon ...

oui, mais, en général, on se dit qu'on a le meilleur truc possible...
ET ce n'est que APRES avoir fait l'optimisation du code qu'on se rend compte que ce n'est pas assez rapide...
=> on cherche un autre algo, plus perofrmant...