Affichage de point ST basse

Quelqu’un connaîtrait il une solution miracle pour afficher un point en gfa, plus vite qu'un pset, lui permettant de choisir la couleur ?

Même en n'utilisant que le 1er plan, même en compilé je n'ai trouvé que :

PROCEDURE fpset(x&,y&)
adrx&=AND(SHR(&%,1),65528)
adry&=tabmul160(y&)
adre%=ADD(xb%,ADD(adrx&,adry&))
dec%=SHR(32768,(x% AND &HF))
CARD{adre%}=CARD{adre%} OR dec%
RETURN

ou encore à la place des 2 dernières lignes
BYTE{adr%}=BSET(BYTE{adre%},x& and 15)

Mais ils restent toujours légèrement plus lent...
Sauf points pré calculés et/ou code généré, là où ces deux derniers deviennent intéressants, pour le temps réel, même sur un plan, je n'arrive pas à faire mieux que pset.

Leglod :
Ya pas plot aussi en GFA me rappel plus ?
si non passer par un routine directement en assembleur !??

Hylst :
lelod a écrit:
Ya pas plot aussi en GFA me rappel plus ?
si non passer par un routine directement en assembleur !??

Oui, mais c'est encore plus lent que pset.
Je me suis fait une routine de point en asm, mais le temps de sauvegarder et restaurer les registres et de passer les infos, ce n'est utile que dans de rares cas.

Leglod :
C'est pas du GFA mais ya quelques trucs super impressionnant à base de points justement mais me rappel plus quelle demo ??

Tomchi :
Vu que je suis pas trop motivé au boulot, j'ai codé une petite routine entre 2 clients.
Affichage et effaçage de points sur 1 plan, chaque point suivant une courbe simple avec un cosinus/sinus.
La loose, en 1 VBL je n'affiche que 26 points , par contre c'est pas énorme mais c'est plus rapide que la même routine avec PSET qui dépasse la VBL.
Évidemment une fois compilé bien sur ^^'

[Vous devez être inscrit et connecté pour voir ce lien]:

Code:

RESERVE 1000                         ! Memoire pour les variables du gfa
CLS                                  ! Beuh?
SETCOLOR 0,0                         ! couleur de fond: noir
SETCOLOR 1,&HFFF                     ! couleur des points: blanc
SETCOLOR 15,&HFFF                    ! couleur 15
OUT 4,18                             ! plus de souris
rez|=XBIOS(4)                        ! sauve resolution
initial%=XBIOS(2)                    ! sauve adresse ecran actuelle
'
' Memoire : 2 ecrans = 64000 plus 256 pour etre compatible ST
'           1 buffer pour stocker les adresses et offset de chaque x
'           => 1 mot adresse  1 mot le point decale
'           1 buffer pour stocker les adresses de chaque y
'           1 buffer pour sauver les points affiches pour l'effacage suivant
' Les buffers sont calcul‚s pour 100 points mais yen a que 26 !!!! :P
'
'
buffer%=MALLOC(64256+1280+400+600)
'
log%=AND(ADD(buffer%,255),&HFFFFFF00)   ! ecran logique sur adresse multiple de 256 pour ST
phy%=ADD(log%,32000)                    ! ecran physique
x_precalc%=ADD(phy%,32000)              ! buffer d'adresses et offsets pour x
y_precalc%=ADD(x_precalc%,1280)         ! buffer d'adresses pour y
pos_buf%=ADD(y_precalc%,400)            ! buffer pour effacage
pos_old_buf%=ADD(pos_buf%,200)          ! pareil
'
FOR i&=0 TO 319                         ! precalcs
 dec&=SHL(i&,2)                        ! adresses multiples de 4
 xbuff%=ADD(x_precalc%,dec&)
 ybuff%=ADD(y_precalc%,SHL(i&,1))      ! adresse y codee sur un mot
 CARD{xbuff%}=SHL(SHR(i&,4),3)         ! pour chaque x son adresse ecran
 CARD{ADD(xbuff%,2)}=SHR(32768,(i& AND &HF))  ! motif du point decale
 IF i&<200                             ! y<200
   CARD{ybuff%}=MUL(i&,160)
 ENDIF
NEXT i&
BMOVE XBIOS(2),log%,32000               ! efface ecran
BMOVE log%,phy%,32000                   ! pareil
~XBIOS(5,L:log%,L:phy%,0)               ! mise en place des ecrans et ST basse
REPEAT                                  ! boucle principale
 SWAP log%,phy%                        ! echange les adresses ecran
 SWAP pos_buf%,pos_old_buf%            ! echange les adresses buffer des points
 ~XBIOS(5,L:phy%,L:log%,-1)            ! mise en place des ecrans
 SETCOLOR 0,15                         ! avant la VBL cpu restant en bleu
 VSYNC                                 ! VBL
 SETCOLOR 0,0                          ! coul fond: noir
 ADD ang0&,2
 ADD ang1&,4
 IF ang0&>360
   SUB ang0&,360
 ENDIF
 IF ang1&>360
   SUB ang1&,360
 ENDIF
 point&=0                              ! en trop mais bon ...
 adr%=pos_buf%
 REPEAT                                ! effacage des points
   dest%=ADD(phy%,CARD{adr%})          ! adresse de destination
   CARD{dest%}=0                       ! 0 efface
   INC point&                          ! prochain point
   ADD adr%,4                          ! prochaine adresse
 UNTIL point&=26                       ! ouah ... tant que ca !!! ^^'
 adr%=pos_buf%
 point&=0
 REPEAT                                ! calcul des coordonnes et des adresses/offset
   x&=160+INT((50+point&)*COSQ(ang0&))
   y&=100+INT((49+point&)*SINQ(ang1&))
   xpos%=ADD(x_precalc%,SHL(x&,2))                             ! adresse en x
   CARD{adr%}=ADD(CARD{xpos%},CARD{ADD(y_precalc%,SHL(y&,1))}) ! on ajoute l'adresse en y
   CARD{ADD(adr%,2)}=CARD{ADD(xpos%,2)}                        ! valeur correspondant au point decale
   dest%=ADD(phy%,CARD{adr%})                                  ! adresse a l'ecran
   CARD{dest%}=CARD{dest%} OR CARD{ADD(adr%,2)}                ! affichage
  INC point&
   ADD adr%,4
 UNTIL point&=26
UNTIL PEEK(&HFFFFFC02)=57                                       ! espace pour quitter
OUT 4,8                                  ! souris
~XBIOS(5,L:initial%,L:initial%,rez|)     ! comme on l'a pris
~MFREE(buffer%)                          ! libere mémoire
EDIT                                     ! et tout le reste


Leglod :
Faudrait voir si l'Omikron est plus rapide ou pas pour les point je suis curieux !

Hylst :
C'est tout à fait dans l'esprit de mes routines actuelles et me semble optimisé quasi au mieux pour du temps réel.
Certes, il y a le calcul des positions de point qui mange du temps machine, mais quand même...
Quand on voit dans certaines demo en asm le nombre de points affichés en 1 vbl...
Optimisation possible au niveau d'une version du compilateur ?

Tomchi :
A mon avis la meilleure optimisation, c'est un bon vieux INLINE avec une chtite routine assembleur.
J'y connais rien en asm, mais j'ai commencé à m'y mettre, justement en créant des routines d'affichage/effaçage de points, et même si ce n'est pas aussi rapide qu'un prog fait entierement en asm, la vitesse par rapport à du GfA est au moins 4-5 fois plus rapide ^^' .

Appliqué à la routine plus haut, il n'y aurait à sauvegarder les registres qu'une fois et avoir une routine en code déroulé.

[Vous devez être inscrit et connecté pour voir ce lien]:

Code:


movem.L   D0-D2/A0-A3,-(sp)   ;4*4+4*3=28
  move.l   32(sp),a0          ; adresse buffer ecran
  move.l   36(sp),a1          ; pointeur pour effaçage
  move.l   40(sp),a2          ; pointeur pour affichage
;
; effaçage
  repT   160                         ; pour les 160 points
  move.w   (a1)+,d0          ; CARD{ADD(o%,0)}
  lea   (a0,d0.w),a3
  move.w   (a3),d2
  and.w   (a1)+,d2          ; CARD{ADD(e%,CARD{ADD(o%,0)})}=AND CARD{ADD(o%,2)}
  move.w   d2,(a3)
  addq.l   #2,a1              ; prochaine adresse d'effaçage
  endr
; affichage
  repT   160
  move.w   (a2)+,d0          ; CARD{add(a%,0)}
  lea   (a0,d0.w),a3           ; ADD(e%,CARD{ADD(a%,0)})
  move.w   (a3),d2            ;
  and.w   (a2)+,d2          ; CARD{ADD(e%,CARD{ADD(a%,0)})}=AND CARD{ADD(a%,2)}
  or.w   (a2)+,d2                  ; =OR cARD{add(a%,4)}
  move.w   d2,(a3)           ;CARD{ADD(e%,CARD{ADD(a%,0)})}
  endr
  movem.L   (sp)+,D0-D2/A0-A3
  rts
  END


Mon premier essai en asm, conversion d'une routine de Jedi ou Deneb d'un ST mag, évidemment je m'étais fait aider pour optimiser le code
L'effaçage se fait avec un AND car c'est pour plusieurs plans et un fond à ne pas effacer ( genre vous verrez quand j'aurais fini mon jeu quoi :p )

Après, il faut optimiser la partie calcul de coords, avec des tables de sinus tout ça. Au final, héhé, ben yaura plus beaucoup de GfA dans le prog mais beaucoup plus de points en 1 VBL à l'écran

Leglod :
Tu nous refais un H2O

Tomchi :
Nan c'est juste pour un starfield dans l'ecran de menu, je fais un shoot'em up si tu te souviens

Hylst :
Vivement que je finisse de debugger les écrans de la japemo voulue 100% GFA (sauf rout chip), que je fasse un peu plus de technique, voire à quel point je peux optimiser certains effets.
Tu as en tous cas l'air de te débrouiller déjà en asm.

Tomchi :
haha !!! A cause de toi (ou grâce plutôt hein ?!) je suis sur une routine de rotozoomer 1 plan.
100% gfa temps réel pour le moment, j'en suis à 3 vbls pour un affichage de 160*100 avec des quadruples pixels.
pas terrible, il va etre temps de passer aux precalcs pour booster tout ça

HAHAA !!! 9 vbls en plein ecran pffffffffffffff .....

Leglod :
tomchi a écrit:
haha !!! A cause de toi (ou grace plutot hein ?!) je suis sur une routine de rotozoomer 1 plan.
100% gfa temps reel pour le moment, j'en suis à 3 vbls pour un affichage de 160*100 avec des quadruples pixels.
pas terrible, il va etre temps de passer aux precalcs pour booster tout ça
HAHAA !!! 9 vbls en plein ecran pffffffffffffff .....
avant ou apres compilation ?

devine ^^'

Hylst :
En 3 vbls seulement ?! Le rotozoom... je m'y suis cassé les dents, comme l'effet blob, lenteur inimaginable, en grande partie à cause de la lenteur de l'affichage.
En 1 plan... du code généré en card avec adresse relative et masque pour le or precalculé pour chaque point et chaque étape ?
Dommage que l'on ne puisse gérer des rasters horizontaux ... en gfa... sans quoi ce serait un carnage... =D
rrraaa... le copper amiga.... =D
En tous cas, j'ai hâte de voir ça !

Leglod ;
Il est capable de quoi ce cooper amiga et le blitter de l'amiga il est vraiment beaucoup plus puissant que celui d'Atari ?

Hylst :
si ça t'intéresse, tu trouveras pas mal d'infos ici [Vous devez être inscrit et connecté pour voir ce lien]

Leglod :
J'avais déjà lu un peut tout ca, je sais tres bien que l'Amiga n'a rien a prouver de ces capacite sur le ST, ce que je voulais savoir c'est surtout les performance du Blitter de l'Amiga par rapport a celui du STe , a l’époque beaucoup disaient que celui du STe ne valait rien, pas plus rapide qu'une bonne routine en assembleur ect.. Mais qu'en est il renflement ?

Tomchi :
pff, dérouler le code n’accélère pas grand chose, et le peu d'idees d'optimisation que j'avais ne font rien gagner ^^'
toujours 3vbls pour un pauvre 1/2 écran en 1 plan.
ça me botte pas bien de faire 360 kos de precalcs juste pour voir si ça va plus vite

:'(

Hylst :
360ko ? ça passe encore j'aurais tendance à dire. Si ta mémoire n'est pas trop mangée par de gros inline, ou autres precalcs. Après... tout dépend de ton code…


Tomchi :
\o/ Apres 360 kos de precalcs et une chtite optimisation sur l’incrémentation des pointeurs ça tourne en 1 vbl !!
Bon, sauf que yaurait pas de temps pour autre chose même pas un petit soundchip :'(
Pis .. ben euh ... en fait 160*100 ça fait pas un demi écran, ça fait le quart d'un écran, alors c'est tout petit ... re :'(
dérouler tout le code ne ferait pas gagner beaucoup en temps machine mais résulterait en un source de plus de 7000 lignes ...
Hmmmm chais pas quoi faire avec ça, soit je m'en sert si j'arrive a gagner un peu de cpu pour remplir un peu plus l’écran, soit j'essaye une routine assembleur, mais du coup ça serait plus du GfA et rotozoomer 1 plan en asm c'est la loose.
Enfin, maintenant je sais à quoi m'en tenir

Leglod :
Tu y colle une photo de Lynx autour et ca fait simulation

Tomchi :
lol

Hylst :
Alors ce rotozoom ?

Tomchi :
J'étais à la VIP ce week end, j'ai pu le finir plus ou moins.
Résultat 40*25 points de 4 pixels, soit un affichage de 160*100 à l'ecran, grace au blitter je recopie le coin supérieur gauche en bas à droite, histoire que ça ne fasse pas trop vide. Ca tourne en 1 vbl pour une texture en 1 plan, et en 2 vbls si la texture à été dessinée au stylo bic 4 couleurs. Eh oui 4 couleurs et non pas 4 plan (16 couleurs).
Toujours mes 360 kos de precalc pour les offset de rotozooming, pis déplacement en x et y dans la texture grâce au blitter.
C'est pas des masses, mais bon, 1000 points en gfa c'est déjà pas si mal

Hylst :
à la VIP ? ça me rappelle de bien vieux souvenirs... comment était l'ambiance ?
40*25 pixels en 1 vbl et en GFA, c'est un peu plus que pas si mal ! un rotozoom avec un precalc de 360ko encore raisonnable, c'est particulièrement impressionnant, avoir tenté de m'y attaquer, m'étant alors vite découragé, interrompu par je ne sais quoi, je te tire mon chapeau J'ai hâte de voir ça. Et en 2 plans en 2 vbl, ça restera tout à fait fluide je pense. Moi qui me coltine parfois du 5-6 vbls.... Même si en utilisant le blitter, et en passant davatage par la line a, en préférant du bitblt au put... je pourrais vite /4 le nbre de vbls de pas mal d'effets, manque juste encore du temps... plutôt que de rereprendre mes anciens écrans, j'essaierai de pondre une démo 'best of' avec de nouveaux gfx et design pour l'occasion.
Pourquoi pas une prod en commun d'ici là ? Bon... je suis encore loin d'avoir ton aisance en GFA, mais si ça te botte...

Au plaisir

Leglod a écrit:Faudrait voir si l'Omikron est plus rapide ou pas pour les point je suis curieux !

En OmiKron, cette fonction est aussi très lente que ce soit en basic ou en assembleur
En moyenne résolution, Couleur%= Point(x,y) , les couleur 2 est 3 sont inversées après compilation

Dans MI-9.prg, j'ai tenter d'utiliser ces fonctions pour l'échange de deux index de couleurs dans une image , mais compte tenu de la lenteur j'ai fait une routine en assembleur pour la basse et la moyenne résolution  [Vous devez être inscrit et connecté pour voir ce lien], et une réduite à la moyenne résolution dans MI-3.prg (je n'en sait plus l'utilité)

Si vous avez une routine ou une idée pour optimiser la vitesse