Reprise du message précédent :
ne polluez pas ce merveilleux tomic hein !    
 
prochaine leçon : les shade bobs
 
http://www.oldskool.org/demos/expl [...] adebob.gif  
 
good night
bon voyage chrisbk

 
oki désolé je suis un nioub en d3d/ogl avec max, donc vu chrisbk a l'air d'avoir pas mal de bouteille  

bon allez @+  

la vache la première démo connue sur http://www.oldskool.org/demos/ !!!
 
trop lol le coup de la composition de musique avec les parasites dans la radio !!!

 
 
impossible, quand je dis que le mien était infernal, c'est qu'il l'etait par exemple pour acceder au vtx fallait deja te taper tous els materiau (impossible de skipper), et tout a fait a coup de flags.Genre si le dword que je viens de lire a son 5eme bit a 1, alors fo que je lise deux strings, sinon juste un et etc etc etc etc
 
infernal

 
Il me semble que les fans soient pas hyperappréciés des cartes 3D (meme ci c parfois hyper pratique, par ex pour faire le dessus d'un dome).
(les strips du peux les liés avec des tris dégénérés, hein ? par contre c'est vrai que tout tracer d'un coup, non seulement c'est plus pratique, mais en plus un peu plus carte 3d friendly )
 
(pas mal de bouteille faut pas exagerer quand meme je joue avec DX depuis le 7, mais la par exemple j'ai passé le moteur au 9 sans avoir jamais vraiment exploité le 8. D'un certain point de vue c'est pas mal, car le 9 décharge de bpc de code, surtout en ce qui concerne les VS)
 
 
harko : thks
 
byeles ptits gars !
 
 
 
 
 
 
 

 
j'avoue c'est violent !!

 
je débutais
 
je connaissais pas la merveilleuse technique des chunks

oh la vache !!!! j'y comprends vraiment strictement rien !!
 
vous trouvez que le rotozoom est simple vous ?  

 
Oui.

tu vas peut etre pouvoir m'expliquer mieux que ne l'a fait harkonnen alors, puisque tu es si malin  

 
attention hein ! pas de dérapage !!
 
vic > si mon explication ne te convient pas, je n'y peux rien ! j'ai essayé d'être le plus clair possible, mais personne n'a jamais dit que coder un effet de démo était simple. ne t'imagine pas que ça viendra de suite !!

 
bon de manière générale:
 
dans une image destination (l'écran), tu vas te balader dans chaque pixel de la destination en déterminant ou est-ce que tu dois prendre le pixel dans l'image source.
 
le rotozoom, ça consiste à recopier une image tournée puis zoomée.
 
pour cela, il faut maintenir un vecteur de déplacement des coodonnées du pixel source à utiliser, et la position courante de ce pixel.
 
cas simple:
 
imagines que tu ne tournes pas, ni ne zoom, copie 1:1 quoi
 
vu que dans la destination tu progresse par pixel de chaque ligne horizontal, il faut donc utiliser un vecteur "horizontal", pour se déplaçer dans la source. ça sera donc un vecteur (1,0):  
 
à chaque déplaçement d'un pixel dans une ligne de la destination, on avance d'un pixel en horizontal dans la source, et rien en vertical.
 
l'astuce lors du changement de ligne, c'est que le vecteur utilisé est alors un vecteur perpendiculaire, afin d'au lieu d'aller vers la droite on va vers le bas.  
 
pour cela le vecteur de déplacement vertical, est construit avec (y,-x) du vecteur de déplacement horizontal. donc ici (1,0) donne (0,-1).
 
dans la destination, la position de la source est déplacée de (1,0) de pixel en pixel de chaque ligne, et de (0,-1) à chaque changement de ligne (attention on repart de la position de début de ligne)
 
donc la boucle ressemble à ça:
 
position_debut_de_ligne = (0,0)  
 
vecteur_de_déplacment = (1,0)
 
pour chaque ligne
 
  position_courante=position_debut_de_ligne
 
  pour chaque pixel de la ligne
       copier dans la destination à la position (pixel,ligne), le pixel de la source à la position "position_courante"
       position_courante += vecteur_de_déplacement
  fin pour
 
  position_debut_de_ligne += vecteur_perpendiculaire_au_vecteur_déplacement
fin pour
 
ensuite:
 
comme on veux faire une rotation d'angle alpha, le vecteur de déplacement va être calculé:
 
donc au début à la place de "vecteur_de_déplacment = (1,0)"
 
on va avoir: vecteur_de_déplacment = ( cos(alpha),sin(alpha) )
 
comme ça le vecteur va dans la direction ou l'on veux.
 
MAIS comme on veux pouvoir zoomer/dézoomer, on va introduire un coeficient.
 
si ton vecteur de déplacement est "réduit": on va zoomer.
 
pourquoi, reprenons le cas initial ou le vecteur de déplacement est (1,0):
 
ce qui veut dire "pour un pixel destination, on avance d'un pixel source".
 
si on utilise ( 0.5 , 0 ), il faut avancer de deux pixels destination pour avancer d'un pixel dans la source.
on a doublé la taille de l'image source, on a donc zoomé.
 
symétriquement si on prends un vecteur (2,0) on avance de deux pixel source pour un pixel destination.
ce qui fait que l'image source est divisée par 2: on dézoomes.
 
DONC:
 
on va introduire un coefficient de zoom (si < 1 on zoomes, si > 1 on dézoomes) de cette manière:
 
vecteur_de_déplacement = ( cos(alpha) * coefficient, sin(alpha) * coefficient ).
 
voilà, je ne vois pas d'autres explications.
 
quand tu auras digéré ça, on passera au pourquoi du comment c'est quoi la virgule flottane et la virgule fixe...

alors vic ?

ben alors, c'est à peine plus clair !
ce qui me gène ce sont les cosinus & sinus ! j'ai toujours été une bille en trigo, et j'ai l'impression que je vais m'en mordre les doigts.
y'a pas un effet 2D qui utilise pas de trigo ?

 
la translation de vecteur nul ?

 
Les bidouillages de palette ?
 
Les copper lists ?

effectivement, cyclage de couleurs et copper-lists n'utilisent pas de trigo.
mais la je suis au boulot, alors la leçon ce sera pour ce soir

ça dépends si tu veux faire des trucs cycliques sur les composants R,V,B ?  

bon vic t'abandonnes ?

on l'a pas vu de la journée
tant mieux, mon tut sur les copper lists n'est pas pret

d'autant plus que je le suivrais avec assiduité...

ne me dis pas que ce topic sombre ??

mais non, il est juste en stand-by le temps que vic ait fini de tracer son cercle trigonométrique
 
il veut des effets sans trigo, il va être servi le bougre ! à la place des sinus & cosinus, il va bouffer du CRTC, du VBlank et HBlank et autres joyeusetés

 
allez vic on se magne, y'a du monde qui attends la suite la

moi par exemple  

 
bin alors ça y est t'es de retour ?

 
c'est quoi les copperlist ?

Et allons y pour les copperlist ! t'es pret vic ? Go !!!
 
Les copper list, appelées aussi rasters, sont des barres de couleur qui défilent sur l'écran. Tu vas me dire que c'est pas bien compliqué à faire, mais quand je t'aurais dit que en fait, ces barres généralement en 256 couleurs n'utilisent qu'une seule couleur, tu penseras le contraire... Ce sont les vraies copper-list ! Celles qu'on voit d'habitude trichent en utilisant tous les registres de couleur
 
En fait, le principe est simple : on utilise un registre de couleur pour en créer d'autres pendant chaque balayage horizontal (le moment ou le faisceau d'éléctrons du moniteur revient à la ligne suivante). Il suffit de remplir l'écran avec une couleur unique (la couleur 0 par exemple), et à chaque retour de balayage, on modifie cette couleur. Ce qui donne virtuellement une infinité de couleurs en n'utilisant qu'un seul index de couleur. Tu peux ainsi utiliser les autres couleurs pour dessiner, etc... De plus, chaque fois que la couleur 0 apparaitra, la copper list sera affichée, laissant ainsi apparaitre un dégradé en transparence
 
Sur Amiga, ce principe se mettait en oeuvre le plus simplement du monde grâce à ce génial copper !!! Il suffisait de charger le registre de couleur 0 avec une couleur (instruction MOVE), d'attendre la fin de la ligne (instruction WAIT), et de recharger une nouvelle couleur, etc... C'est d'ici que vient le nom de copper list !
 
; ligne 1
MOVE $aaa, $dff180 => charge du gris clair dans le registre $dff180 (couleur 0)
WAIT xxx  => attend que le faisceau d'électrons atteigne la position xxx de la ligne
 
; ligne 2
MOVE $bbb, $dff180 => gris encore plus clair dans la couleur 0
WAIT xxx => etc...
 
On obtenait ainsi des barres dégradées affectées à la couleur 0, sans utiliser aucun cycle processeur !!! Ce copper était tout simplement génial !!!
 
Sur PC, c'est largement plus chiant à mettre en oeuvre !!! Le principe est le même, mais pas de copper : il faut tout faire à la main !!
 
Ce qui serait pratique, c'est que la carte vidéo fournisse une interruption lorsque le faisceau atteint la fin de la ligne, mais ça n'est pas le cas : seule l'interruption de fin de balayage vertical existe. Ca ne facilite pas les choses ! La seule méthode consiste donc à surveiller sans cesse l'état de la carte et décompter les lignes pour changer de couleur au bon moment.
 
Il faut donc rechercher une situation de départ en attendant le retour de balayage vertical. Puis une fois un bit précis de la carte vidéo activé (Display Enable du registre Input Status), on saura qu'on est en ligne 0.  Il faut donc surveiller ce bit pour décompter les lignes parcourues, et modifier la couleur en conséquence.
 
Comme tu vois, pas de trigo ! Juste une bonne dose de matériel !! La démo c'est du calcul et du hardware. Et des pizzas, du coca, du café, etc...
 
Je te laisse digérer tout ça !

et des brownies
 
non c'est en LAN ça  

n'empeche, c'était vraiment génial ce copper :'(
sans lui, on n'aurait jamais eu Shadow of The Beast...

 
ça me rappelles frog sur le ST aussi c'était drôle ça (mais rapidement saoulant )

 
tu parles je rentre que fin juillet
Mais figures toi que les allemands ont aussi le net international

encore parmi nous vic ?

oui, mais je ne comprends vraiment pas comment on peut obtenir 256 couleurs sur une seule
et qu'appelles tu "balayage horizontal" et "balayage vertical" ?

 
ah ben forcement
 
bon, tu sais que ton ecran c en fait un faisseau (orthographe vacillante detected) qui balaie l'ecran de gauche a droit - haut bas ?
 
bon balage horizontale c quand le faisceau a fait une ligne, vertical quand il a fini de remplir tout l'ecran (eg de remplir toute les lignes)