Fade In / Fade Out en E 256 couleurs

15 sujets de 1 à 15 (sur un total de 15)

Baba
1 août 2005 à 23h35 #2248
De facon à faire un effet de fade in / fade out de couleur, j’utilise deux boucles imbriqués :

FOR couleur := 0 TO 255

FOR i := 0 TO 255

SetColour(ecran, i, TabRouge[couleur], TabVert[couleur], TabBleu[couleur])

ENDFOR

Wait_vbl()

ENDFOR

Le résultat est vraiment trés lent.

La variable ecran est un pointeur sur un écran intuition, comment changer ses couleur de facon plus rapide que par le SetColor() ?

Dois-on pré-calculer des copper-list (ou des view port ou autres layers ) ?

Comment contourner la lenteur de SetColour() ?
crisot
2 août 2005 à 1h57 #44574
C’est quoi ton language? Car ce genre de truc meme en AMOS c’était rapide donc là, je suis surpris . ?

EDIT: Ha, c’est du E… heu…
stan
2 août 2005 à 2h27 #44575
J’ai malheureusement oublié son nom, mais il existe une fonction qui permet de changer toute la palette d’un coup et existe depuis l’OS 3.0.

À vrai dire, je n’ai jamais dû utiliser SetColour()… C’est pas un truc qui tape dans le hard ? Vaut mieux éviter, de nos jours.

(désolé, j’ai plus les docs sous la main pour vérifier tout ça)

Sinon, je sais pas ce que tu appelles lent, mais si ça prend 5 secondes c’est normal .
Baba
2 août 2005 à 3h37 #44576
Lent, ca veux dire lent,

Du genre : meme si je met mes couleurs à 0 ( du noir) avec une boucle

FOR i :=0 TO 255

SetColour(ecran,i,0,0,0)

ENDFOR

On peux voir les couleur disparaitre les une apres les autres, ce qui fait un effet, mais pas celui escompté.

D’apres mes souvenir, j’utilise cette procédure, justement parce que décrire une palette AGA dans une copper-list est assez compliqué, et que mettre en place une copper liste personnalisée est assez délicat puisque toutes les actions d’entrées clavier ou souris dans le programme a des répercution invisible mais réelles sur le workbench, sauf si on couppe le multitache.

C’est une fonction de haut niveau, puisque selon la Doc, il faut toujours préciser les valeurs R, V, et B de 0 à 255, meme pour un écran OCS ou ECS. Cela dit, tapper dans les bi-plans à gros coup de blitter gràce à des bout d’assembleur ne m’inquiette pas outre mesure.

Personnellement je trouve le E plutot cool, plus puissant que l’amos puisque c’est un compilateur, pas un interpréteur et plus standard que le C puisque chaque compilateur C a son lot de spécificité.
henes
2 août 2005 à 3h53 #44577
graphics.library/LoadRGB32()
Rafo
2 août 2005 à 7h35 #44578
FOR couleur := 0 TO 255

FOR i := 0 TO 255

SetColour(ecran, i, TabRouge[couleur], TabVert[couleur], TabBleu[couleur])

ENDFOR

Wait_vbl()

ENDFOR

Le résultat est vraiment trés lent.

Ca ne m’étonne pas, si tu mets Wait_vbl() à chaque boucle pour la variable couleur. Ta routine s’exécutera en 255 frames minimum, ce qui fait quand même plus de 5 secondes en PAL. Si tu supprimes ce truc, ça donne quoi ?
Eddy58
2 août 2005 à 13h16 #44579
Personnellement je trouve le E plutot cool, plus puissant que l’amos puisque c’est un compilateur, pas un interpréteur et plus standard que le C puisque chaque compilateur C a son lot de spécificité.

L’Amos aussi est compilable….
krabob
2 août 2005 à 13h49 #44580
graphics.library/LoadRGB32()

et en plus , dans le format de liste de couleur qu’utilise LoadRGB32,

les composante de couleur sont sur 4 octets. un RGB prend donc 12 octets. c’est une précision de 32 bit par composante. De fait, c’est l’octet de poid « fort » qui a la couleur [0,255]. les 24 autres bit faibles peuvent pas etre vue par l’oeil (ni utilisé par le hardware.)

Donc pour faire ton fade: optimisation possible grace a ces 3 octet faibles: les utiliser pour representer des « bit aprés la virgule. »

crééer 3 tables de palette RGB32

table A: la palette de départ

table B: la palette d’arrivée

table C: donc les composante sont: (table B-tableA)/nombre de passe du fade.

puis aprés tu fait ton fade par une boucle du genre:

tant que(nb de passe du fade)

{

table A = table A+table C // par couleur et composante.

LoadRGB32(table A);

}

la ou c’est bon, c’est qu’il n’y a ni décalage, ni test de dépassement de la valeur des composantes, juste des additions.

table A se retrouve toujours avec les bonnes infos.

edit: le format de liste de couleur RGB32 est décrit dans les autodocs du systeme, a la fonction LoadRGB32.

re-edit: tient une petite pensée philosophique:

a l’époque ou ils ont créé ce format RGB32, c’était a celui qui allait le plus dans la « précision ». (4b/composante en ECS (0,15), 8b/composante en AGA (0,255)) ouaaah alors du coup les mecs ont du penser: si le format de couleur évolue, ce sera vers plus de précision, donc hop, on met 32b/composante et c’est bon on est pret pour l’an 2000 !!!

Manque de pot:

1. si devant que tu ailles, l’oeil ne voit pas la différence au dela de 8b/composante.

2. les fomat de shader actuel encode les composante en float ou double. cela permet de donner des valeur négatives et >1.0, qui

n’ont pas de sens en terme de couleur, mais représentent des propriété physique. ( le format d’image HDRI pose que si la composante >1.0, elle produit de la lumiére. En plus les composantes RGB sont des longeurs d’onde , mais on peut imaginer d’autres longueur d’onde ou info a encoder. ) du coup, niqué RGB32 !!!
stan
2 août 2005 à 19h59 #44581
Voilà, c’est LoadRGB32() à laquelle je pensais. Sinon, je sais pas pour ton oeil, mais le mien il voit la différence au delà de 8 bits par composantes… Du moins, il la verrait si j’avais un hard qui supportait ça .
Baba
2 août 2005 à 23h26 #44582
Humm, un poil complique, mais pourvu que ca marche !!

Le LoadRGB32(monecran.viewport, palrgb32) fonctionne trés vitte en fait !

Il marche aussi bien sur le vrai 1200 que sur UAE

Je ne le connaissait pas, merci !

la variable palrgb32 est un pointeur vers un octet ( PTR TO CHAR)

Il faut remplir les 2 1er octets avec le nombre de couleurs, et a partir du 4eme octet, le r,v,b tout les 4 octets

palrgb32 := NewM(((256*12)+16), MEMF_CHIP OR MEMF_CLEAR

palrgb32[0] := $1 -> 256 couleurs a affecter

FOR fade := 0 TO 50

FOR i := 0 TO 255

r,v,b := couleurs_rvb_normales(i) -> renvoie les composantes r,v,b normales

palrgb32[(i*12)+4] := r*fade/50

palrgb32[(i*12)+8] := v*fade/50

palrgb32[(i*12)+12] := b-fade/50

ENDFOR

LoadRGB32(ecran.viewport,palrgb32)

wait_vbl() -> procédure personnelle qui attends que $DFF006 vaille $FF, soit le bas du balayage ecran

ENDFOR

-> Rapide, ca devrai faire un fade sur 1 secondes

-> Pas mal d’octets semblent être innutiles dans le la table de couleur passée en parametre, dommage

Dispose(palrgb32) -> inutiles, mais réutilisables !!

P.S.

Amos c’est pas mal, et il possede des instructions fades, mais je ne sais plus si il gère l’AGA, et on ne peux pas faire de choses dinamiques comme les listes ou les object, il est un peu trop basic pour moi.

L’assembleur, c’est plus puissant, mais c’est quand même laborieux.
henes
2 août 2005 à 23h48 #44583
Si je me souviens bien, LoadRGB32() n’a pas besoin de table en chip ram. Enlève le MEMF_CHIP et tu gagnera encore quelques cycles
Baba
3 août 2005 à 0h10 #44584
Ca marche même presque mieux

Je fais boucler ma boucle que sur 20 itération, ca économise aussi le cycle je m’endormais…
crisot
3 août 2005 à 13h30 #44585
Heu… pour ce qui est de voir ou non les 8 bits par composantes…

Evidement, si tu regardes sur un plasma qui est strictement incapable de rendre les couleurs, oui, tu vas voir les teintes, mais le machin te rendra au maximum 60 ou 80 teintes par couleurs… Donc écran à chier.

Si tu regarde sur une télé dont les couleurs s’entre fondent les unes sur les autres, parceque c’est une limitation pure et simple des écrans cathodique, alors non tu ne verra pas les dégradés, ce sera parfait, mais c’est la encore parceque l’écran est à chier.

Par contre ces derniers temps j’ai remarqués sur certains écrans, des TFT, pourtant des « vrais » écrans (pas des LG quoi …) que des différences de teintes étaient visibles. J’ai supposé que l’écran était à chier et me suis donc amusé à faire un degradé donné sur une zone donnée et à compter les changement de teintes. Tout y était ! L’oeil perçoit donc VISIBLEMENT 8 bits par composante, sur un écran préci, avec une fort luminosité.

Donc, on peut évoluer.

Mais je suis hors sujet.
henes
3 août 2005 à 17h39 #44586
Fais un simple dégradé de gris sur ton CRT et reviens me dire que tu ne vois pas de bande

Sans utiliser de tramage, bien sûr (j’ai peur que tous les outils actuels le fassent).

Autant que je sache, il y a 10 ans, il y avait déjà des chips graphiques pro avec 12 bits par composante et ce n’était pas pour rien.
Baba
3 août 2005 à 20h14 #44587
Bien sur que c’est visible !!!!

Je m’amuse quand même pas a faire des choses invisibles quand même…

Sauf mon programme qui n’est pas encore visible sur le net, puisque je ne le considère encore pas comme pret pout une bétà release.

Ca viendra, patience…

Merci pour vos renseignements, à bientôt !