Reprise du message précédent :

 
sinon c'est sympa qd-même.
ça manque de régulation des animations qd-même...
je m'étais bien amusé avec le bump par emboss.. c marrant comme truc.

 
ben ouais ca speed a mort On voit presque pas que le fond se reflete finement sur la boule a pique (mon superbe envmap a deux franc )
 
le bump stait trop bien, la grand classe cet effet
 
 
J'ai finalement pu dl ton truc, ca marche superbe (sauf parfois le feu qui bricole, mais bon, c t pas le principal, hein ? )
 
Bon, c pas le tout, j'ai un déménagement a préparer, moi, ++
 

bon bah maintenant va falloir je retourne sous dos pour recompiler le truc que j'avais fait en VESA 2.0 avec watcom et voir si ça compile toujours...

 
pas d'ironie siouplait

 
je ne me permettrais pas, surtout face a un type qui a regardé mon basard sans pouffer de rire

moi j'ai un super pong en asm x86, mais j'ai paumé les sources.
y'avait un algo top gainial pour le service (en fait on devait faire 5 dans un sens, 5 dans l'autre, et au final on a un truc aléatoire, même apres avoir essaye plein d'algos basiques différents)

harkonnen, je vois ce qu'est un rotozoom, mais je ne vois pas comment ca peut etre programmé ! tu pourrais pas m'expliquer le principe, et me dire ce que tu veux dire par "table de sinus de 0 a 2*pi en ajoutant pi/4 pour avoir les cosinus" ?
 
tout ceci est vraiment très complexe
je pensais pas que coder une démo était si complexe, je nage vraiment dans tout ce jargon abscons...

 
C'est de operations de trigo de base.
 
sin (x) = cos (x + pi/4);
 
Et puis normalement, il me semble que la table de 0 à PI/2 suffit en jouant avec les autres transfo tigo,nométriques comme :  
cos (x + Pi) = - cos (x)
 
(en fait, c'est un post pour mettre un
 

 
au lieu de calculer les sinus/cosinus directement via les instructions du CPU, tu les precalcule dans une table.
genre :
 

 
comme ca tu as tous les cos de 0..2PI . Donc quand tu a besoin d'un cos au lieu de le calculer tu va le chercher dans cette table
 
Avec les CPU moderne il vaut mieux utiliser les instrs CPU, ce genre de table a de sales effets sur le cache

 
Le principe du rotozoom est diaboliquement simple, mais il fallait y penser. Cet effet a été imaginé par Chaos du groupe Sanity (un dieu du code).
 
Pour faire un rotozoom, il te faut une texture (qui correspondra à l'image que tu zoomeras) et une zone mémoire correspondant à la taille de l'écran (qui sera ensuite copiée dans la mémoire vidéo).
 
Dans un but d'optimisation, il est préférable que la taille de la texture soit un multiple de 2, ça permet de faire des décalages au lieu des multiplications/divisions. Une texture de 256*256 est parfaite, mais ce sont des dimensions arbitraires.
 
Tu vas donc faire une boucle de 0 à 256 dans laquelle tu vas "passer" sur la texture source, pixel par pixel. A chaque passage, tu recopies les pixels pointés par la droite de balayage dans la zone écran.
 
A chaque itération de la boucle, tu fais tourner la droite de balayage et tu l'obliges à lire plusiseurs fois le même pixel en fonction d'une variable (facteur de zoom). Ce qui donnera l'illusion d'une image zoomée. Pour faire tourner la droite, tu utilises une matrice de rotation toute simple.
 
Pour les sinus et cosinus, je te renvoie aux posts de kadreg et chrisbk, leur explication est correcte.
 

bin alors c'est fini ?

laisse lui le temps de tout assimiler
 

Allez UP, c'est intéressant à lire

j'ai rien compris, rien compris du tout !!!      

 
ben pourtant, c'est simple Bon, je résume
 
tu fais un raster, tu le blitte avant la vbl (tips, passe par la 0xa0000 si tu vois ce que je veux dire , si t'as du tps machine de rab tu fais un emboss avec effet de feu, le track en b-spline (ou approxime avec une transfo de fourrier) et voila !
 
Des questions ?

vic > voici un petit source qui pourra t'aider. je t'épargne, il est en C et pas en assembleur
il fonctionne en mode 13h

 
oui mais il faut lui dire que là tu raisonnes en virgule flottane... font donc mettre des floats partout.
 
sinon pour booster sa race, il faut passer un virgule fixe ce qui donne:
 

 
enfin je fais le malin, mais je me suis ptet planté

hé merde, y manque le ET logique pour avoir la répétition
 
ça va sortir de la texture !!!

t'as oublié le ET ! bonjour l'overflow !
 
edit: grilled !

pour vic : le ET (que j'ai aussi oublié d'ailleurs) te permet de répeter la copie de texture une fois arrivé à la fin. si il n'était pas présent, tu arriverais à la fin de la texture sans revenir au début et tu aurais une bouillie infame de pixels.
 
c'est une sorte de modulo

enfin c'est toi qui l'a oublié à la base    

mon source était plus un algo qu'un véritable source pret à l'emploi
c'est pour ça que j'ai pas utilisé de virgule fixe. le pauvre, une chose à la fois

d'ailleurs hark & chris quelles étaient vos pratique pour l'arrondi au plus près ?
 
passke le +0x8000 fait que 0.5 est arrondi vers 1.0, on pourrait considérer +0x7fff pour que 0.5 soit encore arrondi vers 0 (remarque type de sodomite matheux, je plus qui avait sorti ça comme vanne dans un tomic )
 
par contre, fut une époque dans une routine de triangle en ombrage de gouraud, j'avais ajouté un xor/or/and je sais plus histoire d'avoir un bruit dans l'ombrage lorsque il y a des pixels entre deux niveau de dégradé...

 
ouais, maintenant fo mettre du code asm optimisé pentium (1 l'authentique), ou les instructions seront éxécutées par paire dans les deux pipelines   (je proposes, je vous laisse faire   )

 
 
je confesse tout, aucune
 

 
en fait à la base c'était une question à la con histoire de me la péter  

 
 
ban

 
nonnnnnnnnnnnnnnnnnnnnnnn    

 
je plaisante, je pars demain pour 5 mois, c'est super vive la joie, je vous aime, ouais, supair !

ce qui m'éclate avec ce rotozoom, c'est que quand je le regarde maintenant, je trouve ça d'une simplicité.... à la limite charger l'image qui est dans un format à la con est plus compliqué.
 
par contre à l'époque comment ça me faisait mal au cerveau  

pour un rotozoom, +1
 
par contre, pour un phong, j'y allais bourrin : je créais mes tables en double précision et lors du passage en virgule fixe, j'ajoutais à un point une valeur moyenne comprise entre 0 et 0.5 calculée à partir de la valeur des pixels environnants.
avantage : les dégradés étaient plus smooth vers l'intérieur du polygone, mais l'inconvénient saute aux yeux : les bords étaient pourris !
 
mais vu que les rétroprojo des parties étaient pourris aussi, ça se voyait pas

 
mairde du coup le tomic va se retouver "on hold"  

 
ben ouais
 
Le format le plus a la con que j'ai vu, et bien, j'en suis pas peu fier, c'est moi qui l'a fait (mon premier exporteur max). J'avais plus de code pour le loader de fichier que le moteur en lui meme, c'etait grandiose

c'est malin de faire des tomics comme ca quand je pars, aussi
 
 
mais bon, vais bien trouver un acces au net, qqpart, en bon informaticien que je suis je me vois mal vivre sans

t'inquietes pas, s'il le faut je mettrais ce topic en topic annonce

 
ça tombe bien je suis en plein dedans
 
j'ai choisi ça:
 
Format Bml: (BJOne model)
          Offset
          +00: BML_Signature (long) 'BML1',ou plut?t '1LMB'
          +04: Nombre de vertexs (long)
          +08: Nombre de facettes (long)
          +12: Rayon de la sphere d'envellope,?chelle (float)
          +16: Vertexs (6 floats par vertex)
               X,Y,Z: Coordonn?es 3D (3 floats)
               NX,NY,NZ: Vecteurs Normaux pour l'ombrage de Gouraud
               et l'environnement-mapping (3 floats)
       
    +16+vsize*6*sizeof(float):
 
     Format BML3 : (Rendu hw D3D - indexs 16 bits uniquement)
 
   DWORD: Nombre d'indexs
   WORD....  Indexs
 
   DWORD: Nombre de matériaux
 
   Par matériau:
   {
    // propriétées matériau
    DWORD Flags;   // Attributs
       float AMBIENT[3]; // R,V,B
    float DIFFUSE[3];
    float SPECULAR[3];    
    float SpecularPower;
    float Opacity;
 
    DWORD: Nombres de listes de Triangle Strips
 
      Par Strips:
       DWORD: Index de base  
       DWORD: Nombre d'indexs
       
    DWORD: Nombre de listes de Triangles Fans
 
      Par Fans:      
       DWORD: Index de base
       DWORD: Nombre d'indexs
 
    Triangles Indépendants
 
    DWORD: Index de base
    DWORD: Nombre de triangles (indexs/3=>triangles)    
   }
   ////
 
   DWORD Nombres de volumes de collision
 
   Par volume de collision
   {
    float [8][3]; // les vertexs de la bounding box
 
    DWORD Nombres de triangles pour l'enveloppe de collision
 
       Par triangle de collision:  
         WORD [3] Sommets
   }
 
en fait j'ai pas encore implémenté l'export des coodoonée de textures, honte à moi...
 
la présence de fan est là pour des raisons historique (je suis passé d'un moteur dos en rendu software en moteur d3d full-hardware) donc j'avais expérimenté de faire un max de strip puis de fans et ensuite de triangles indépendants séquences pour maximizer l'utilisation du cache post-T&L.
 
mais en fait le fait d'éclater la géomtrie en plusieurs strips/fans + triangles indépendants, ça génére relativment trop d'overhead cpu que de faire une seule liste de triangle indépendants...

 
le miens batterait-il le tiens ?    
 
(désolé de faire dériver le tomic en fait)

ne polluez pas ce merveilleux tomic hein !    
 
prochaine leçon : les shade bobs
 

 
good night
bon voyage chrisbk