Fast Graphic Routines... - Page 1

Est-ce que quelqu'un pourrait poster les routines les plus rapides possibles, en ASM 68k, pour:
- dessin/effacement de lignes
- dessin/effacement de rectangles vides et de rectangles pleins ?

Merci d'avance.

mmh... cherche "bresenham line" sur internet et recopie en adaptat a ton langage ... t'aurais un bon truc pour la ligne

pour le rectangle ... ne serait-ce pas plusieurs lignes ?? (mais là, c que suppositions)

Merci. Ca m'aide, mais est-ce que quelqu'un aurait une routine toute prête, car franchement je la trouve pas en ASM 68k.

"pour le rectangle ... ne serait-ce pas plusieurs lignes ?? (mais là, c que suppositions)": je pense qu'on doit pouvoir faire beaucoup mieux que ça... J'ai fait une routine de remplissage, mais il doit y avoir plus optimisé ou plus malin que ce que j'ai fait. J'ai vu quelques lignes de code à supprimer, ça bouffe de la place et du temps pour rien...

ben déjà, balance ta routine de remplissage de rectangle...

je parie qu'elle consiste à récupérer le x de départ, le x d'arrivée le y de départ et celui d'arrivée, de faire une boucle pour chaque ligne jusqu'à-ce que ycourant=ymax, et dans cette boucle, une boucle qui dessine une ligne horizontale...

bon, mais je pense que tu l'as fait, déjà, pour accélérer, fo tester si la ligne fé plus de 32 pixels, si oui, t'allumes un .l, sinon, si elle fé + que 16 px, t'allumes un .w, sinon, tu boucles pixel par pixel... et comme ça jusqu'à la fin de la ligne, pis tu passe à la ligne suivante.

c ça que tu fé?

J'ai pensé à faire avec des .l et des .w si il y a plus de 16 pixels, mais d'abord je voulais faire une routine qui marche avec des .b avant d'être confrontée aux problèmes d'alignement. Cela accélèrera nettement la routine sur de grands rectangles, c'est sûr.

Voici ma routine (200% plus rapide que ScrRectFill dans les mêmes conditions):
Bon, c'est sûr, j'ai viré le checking...
Et au fait: il semble sur VTI que le movem.w (%sp)+,%d0-%d7 de la fin écrase aussi la partie haute des registres de données. Ne peut-il pas y avoir des problèmes avec d'autres programmes ? (Mais ça, c'est très facile à corriger).

// C Source File
// Created 05/09/2001; 13:42:36

void FastFilledRect(short x1,short y1,short x2,short y2,short mode,void *plane);
asm("xdef FastFilledRect
FastFilledRect:
movem.w %d0-%d7,-(%sp)
movem.l %a0/%a2-%a3,-(%sp)
/*moveq #0,%d0
moveq #0,%d1
moveq #0,%d2
moveq #0,%d3
moveq #0,%d4
moveq #0,%d5
moveq #0,%d6
moveq #0,%d7*/
lea 0.w,%a2
lea 0.w,%a3 | pas utile je pense, j'ai des lea.l sur a3.

move.w 32(%sp),%d0 | x1
move.w 34(%sp),%d1 | y1
move.w 36(%sp),%d2 | x2
move.w 38(%sp),%d3 | y2

| Suppress checking... This slows down the routine.
/*moveq #-16,%d4 | bounds checking
cmp.w %d0,%d4
bge end
cmp.w %d2,%d4
bge end
moveq #-128,%d4
cmp.w %d1,%d4
bge end
cmp.w %d3,%d4
bge end*/

| let's verify parameter mode
/*cmpi.w #3,56(%sp)
bge end*/
move.w %d2,%d4
sub.w %d0,%d4 | dx
sub.w %d1,%d3 | dy

tst.w %d3
bgt.s continueFR

move.w %d3,%d5 | dy<0
add.w %d1,%d5
move.w %d5,%d1
neg.w %d3
continueFR:
tst.w %d4
bge.s calc_start_addrFR
neg.w %d4
exg %d0,%d2

calc_start_addrFR:
move.w %d0,%d5
move.w %d1,%d6
mulu.w #30,%d6
lsr.w #3,%d5
add.w %d5,%d6
move.l 42(%sp),%a0
adda.l %d6,%a0
| a0=address of the rectangle in memory.

move.w %d2,%d1
lsr.w #3,%d1
sub.w %d5,%d1
move.w %d1,%d7

lea byte_1st_vals,%a3
move.w %d0,%d6
lsl.w #3,%d5
sub.w %d5,%d6

cmpi.w #1,%d7
blt.s dx_1bFR | if 0 then it's only one byte.
bgt.s dx_3pbFR | if 2 or more then it's 3 bytes or more.
| 2 bytes: use of words impossible because of address errors...
| damn the 68000, this would increase speed...
move.b 0(%a3,%d6),%d5

move.b %d2,%d6
move.b %d6,%d7
lsr.b #3,%d6
lsl.b #3,%d6
sub.b %d6,%d7

lea byte_last_vals,%a3
move.b 0(%a3,%d7),%d7
move.w #28,%a2
clr.w -(%sp) | to get rid of move.w %d0,-(%sp) in dx_3pb
move.w 42(%sp),%d4
bra draw2FR
dx_1bFR:
move.w %d4,%d5
neg.w %d5
addq.w #7,%d5
move.b 0(%a3,%d5),%d6
move.w %d0,%d1
lsr.w #3,%d1
lsl.w #3,%d1
sub.w %d1,%d0
sub.w %d0,%d5
lsl.w %d5,%d6
move.w #29,%a2
clr.w -(%sp) | to get rid of move.w %d0,-(%sp) in dx_3pb
move.w 42(%sp),%d4
bra.s draw1FR
dx_3pbFR:
move.b 0(%a3,%d6),%d6

move.w %d2,%d5
move.w %d5,%d7
lsr.w #3,%d5
lsl.w #3,%d5
sub.w %d5,%d7

lea byte_last_vals,%a3
move.b 0(%a3,%d7),%d7

move.w %d0,%d4
move.w %d2,%d1
lsr.w #3,%d1
lsr.w #3,%d4
sub.w %d4,%d1
move.w %d1,%d0
subq.w #2,%d0
neg.w %d1
add.w #29,%d1
move.w %d1,%a2

move.w %d0,-(%sp)
move.w 42(%sp),%d4
bra.s draw3pFR

draw1FR:
cmpi.w #1,%d4
blt.s _clr1FR
bgt.s eor1FR
or1FR:
or.b %d6,(%a0)+
adda.l %a2,%a0
dbf %d3,or1FR
bra finish
_clr1FR:
not.b %d6
clr1FR:
and.b %d6,(%a0)+
adda.l %a2,%a0
dbf %d3,clr1FR
bra finish
eor1FR:
eor.b %d6,(%a0)+
adda.l %a2,%a0
dbf %d3,eor1FR
bra finish

draw2FR:
cmpi.w #1,%d4
blt.s _clr2FR
bgt.s eor2FR
or2FR:
or.b %d5,(%a0)+
or.b %d7,(%a0)+
adda.l %a2,%a0
dbf %d3,or2FR
bra finish
_clr2FR:
not.b %d5
not.b %d7
clr2FR:
and.b %d5,(%a0)+
and.b %d7,(%a0)+
adda.l %a2,%a0
dbf %d3,clr2FR
bra.s finish
eor2FR:
eor.b %d5,(%a0)+
eor.b %d7,(%a0)+
adda.l %a2,%a0
dbf %d3,eor2FR
bra.s finish

draw3pFR:
cmpi.w #1,%d4
blt.s clr3pFR
bgt.s eor3pFR
or3pFR:
moveq #-1,%d5
_orFR:
or.b %d6,(%a0)+
loop2FR:
move.b %d5,(%a0)+
dbf %d0,loop2FR
or.b %d7,(%a0)+
adda.l %a2,%a0
move.w (%sp),%d0
dbf %d3,_orFR
bra.s finish
clr3pFR:
not.b %d6
not.b %d7
_clr3pFR:
and.b %d6,(%a0)+
loopFR:
clr.b (%a0)+
dbf %d0,loopFR
and.b %d7,(%a0)+
adda.l %a2,%a0
move.w (%sp),%d0
dbf %d3,_clr3pFR
bra.s finish
eor3pFR:
eor.b %d6,(%a0)+
loop3FR:
not.b (%a0)+
dbf %d0,loop3FR
eor.b %d7,(%a0)+
adda.l %a2,%a0
move.w (%sp),%d0
dbf %d3,eor3pFR

finish:
addq.l #2,%sp

end:
movem.l (%sp)+,%a0/%a2-%a3
movem.w (%sp)+,%d0-%d7
rts
.even
")

ah, un autre truc: pourquoi vous tenez ABSOLUMENT à afficher les lignes dans le sens horizontal?
ce serait plus rapide une progression verticale...
vu que tu connais la hauteur, au lieu d'afficher chaque ligne horizontalement, puis passer à la ligne d'après, to détectes si tu peux allumer un.w ou un .l, alors tu l'allumes, et tu boucles pour que ça allume toute la COLONNE en .w ou en .l
ce qui fait que tu ne fais plus ces tests que sur une seule ligne, tout le reste se remplissant automatiquement

ça, ça booste!

au lieu de x*30 (mulu #30,XXX)
fais un x<<5-x<<1

c incompréhensible ac tous c % c tigcc qui met ça???

>XDanger: Et au fait: il semble sur VTI que le movem.w (%sp)+,%d0-%d7 de la fin écrase aussi la partie haute des registres de données. Ne peut-il pas y avoir des problèmes avec d'autres programmes ? (Mais ça, c'est très facile à corriger).

En effet, on ne peut pas utiliser movem.w pour sauvegarder des registres.

>sBibi: c incompréhensible ac tous c % c tigcc qui met ça???

C'est la syntaxe de GNU as, l'assembleur utilisé par TIGCC pour l'assembleur inline (et pour assembler les sources compilées en assembleur).

c vraiment très con, ça !
pourquoi faire simple quand on peux faire compliqué ?

OK, je corrigerai les movem.w en movem.l (ce que j'avais au départ, d'ailleurs).
J'essaierai ta routine, sbibi. C'est sûr que c'est plus rapide. En tout cas merci...

Je repose ma question: quelqu'un a-t-il une routine prête en ASM 68k pour le dessin de ligne ?
Je ne suis pas capable d'en faire une moi-même, même en ayant vu le principe et le pseudo-code qui implémente l'algorithme de Bresenham.

ds Extgraph, y'en a pas ?

Si, FastDrawLine est très rapide, mais je pense qu'une routine en pur ASM est plus rapide encore.

Au fait: 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.
Pour btst, il doit falloir déclarer la routine comme short ...(...) puisqu'elle rend un argument. Dans ce cas-là, faut-il restaurer d0 ?

>move.l 0x78C0,%a1

!!! !!!

C'est la manière la plus sure de faire en sorte que ton programme ne marche qu'avec une seule version d'AMS!

arf...
tant que c la ROM2.05 encore
mais bon, tt le monde ne l'a pas forcément...

Non, non et non. C'est loin d'etre les plus rapides. La veritable question est : as-tu besoin de cette vitesse ? Si oui, cf ......

arf... CF kernel + Genlib, je suppose...



PpHd> ça faisait longtemps que je t'avais pas vu ici...
à peine revenue, c le retour du gd débat (lol)

Non. Cf Extgraph, puisque Genlib ne sera JAMAIS adapte a ces fanatiques extremistes.

lol.

te connaissant, j'osais pas le mettre...
Mais c vrai que moi, qui ne suis pas fanatique extrémiste, j'aimerai bien utiliser Genlib en nostub...

A cause de toi, je l'aurais peut etre fait. A cause d'eux, je ne le ferais jamais.
Et si tu veux, t'utilises preos (Distrib libre).

arf...
Grace à moi, tu veux dire...
Y'a pas moyen que j'ai une version de Genlib en lib statique, rien que pour moi ?
(arf... que d'espoir ds mes propos )

Preos... je peux le dl où ?

Non. C'est impossible. Squale => Je te l'ai envoye.

Preos m'interesse aussi beaucoup

par contre, pour l'anti crash, c chiant qu'il ne te dise pas quelle exception il a récup. paske pr débugger, c pas pratik... mais bon, c le fait de ne pas avoir tous ces messages "inutiles" (je cite ) qui fait que c'est un kernel de 2k

Non, savoir quel type d'erreur n'est pas franchement super mega utile, car en general, l'erreur REELLE arrive bien avant. C'est pour ca. Si tu veux, utilises les possibilites breakpoint de Vti (Break on traps).
>Extended: Je te l'envoies.

PpHd> tu m'as envoyé preOS ?
Arf... merde alors... soit il est pas arrivé.. soit je l'ai raté ds ma boite de réception

Je te l'ai envoye a squale92@wanadoo.fr (Adresse donne dans le forum)

Je reviens au sujet...
"move.l 0x78C0,%a1": je sais que c'est très moche, mais que faire d'autre pour savoir quel est le plane utilisé ?
C'est pas comme ça que fait TIOS pour DrawLine, DrawPix... ?

sbibi: merci pour ton coup de main, je n'ai pas encore bossé à faire une routine améliorée.

Il n'y a vraiment personne qui aurait une routine pur ASM 68000 qui marche super bien pour le dessin de lignes ?

Pour les routines de pixels: j'ai lu l'autre topic dans lequel j'ai posté un message. Je sais très bien que TIGCC optimise complètement si les coordonnées sont fixées à l'avance, mais si elles ne le sont pas, ExtGraph a seulement 2/3 de la vitesse de cette routine ASM: j'ai fait un bench avec des coordonnées random.

Pour savoir quel place utiliser, Intercepte PortSet.