cts

J'm'autorise quelques remarques. Quand je parle d'emu YM, c'est pas juste par 'nostalgie'...mais plutot parceque ce genre de routine peut tourner ENTIEREMENT dans les 8Ko du DSP. Autrement dit: TOUTE la bande passant du bus est dispo pour l'affichage (3D ou autre). Pas négligeable... Notez que si on realise un emu YM, l'emu SID est pas loin. Et là on commence à avoir du bon son ! Les sources de STonx/Hatari sont des mines pour ce genre de routines...(bon, j'ai aussi fait le mien en C, si ça branche quelqu'un d'y jeter un oeil...) Quelqu'un aurait de l'experience rapport au SID ?

ze veux un emulateur YM2149 !!!

Raz, Un truc simple est suffisant, la partie visible (dans le CMS) doit suffire à faire des checkouts/télécharger des snapshots et à consulter les changelogs des différents sources (genre: pour tel projet, la page d'accueil du projet retourne un résumé des derniers changelogs -> pas besoin de faire d'annonce, c'est automatique). Du reste, le serveur CVS/SVN peut être hébergé n'importe ou. Tout dépend du niveau d'intégration souhaité dans le CMS. Je pourrais faire un truc Apache+CVS+cvsview, mais j'ai vu ce que ça donnait à l'époque...sur une machine perso c'est craignos (crash/offline/sécurité). Je sais pas à quel point on peut integrer un Savane ou Gforge dans le futur CMS ?

GT pas précis, je parle de: - toutes les sources/binaires accessibles en lecture pour tous - MaJ des sources par les membres du projet À l'époque je faisais ça pour mes petits projets. Rien enpêche de faire un CVS/SVN à part remarque...

Heu...petite requete pour le nouvo CMS: - une gestion de CVS (1 admin par projet, avec le droit d'autoriser d'autres personnes à faire des updates) Pas besoin d'un truc à la Sourceforge quoi ! C'est prévu ? kiki l'héberge ?

Bah, c'est le bug connu non ? Et puis Fifo, faut le dire vite hein ! C'est juste un octet d'avance ! Donc, toujours l'histoire du $80 à tester pour voir si décalage en début de trame...

templeton : Les graphs 3d d'un stuntcar (piste et voiture) je les torches en 4 ou 5 jours et encore ! Et un 'racer' + 1 circuit à la Wipeout ? Tu as déjà peut-être un truc dans le genre déjà modelé ? (genre qu'on peut importer dans Blender ?)

Hello, tu parle du modelage ou des graphs ?

J'veux dire que pour faire un CD_stop, il faut qu'il y ait eu un CD_init (et donc, que le CDbios soit inclus lui aussi).

Tu fais bien le CD_init ? Le CDBIOS est bien inclu ?

Hello ! Il me manque pas mal de mes plus vieux programmes (genre la 3D de la JC2K3, le vaisseau qui tourne). Si t'as ce genre de trucs, je suis intéressé ! Merci !

l'avantage du MMULT c'est de pas avoir à charger de trop nombreux registres . Pis un mmult c'est 2 octets, IMULTN+IMACN+IMACN+RESMAC = 8 octets + le chargement des registres :/ 4ko c'est court Pour la racine caréee, je sais plus le nom de l'algo: ;---------------------------------------- ; ; (not so) fast integer squareroot ; - IN: r4 = root^2 ; -OUT: r4 = sqrt(root^2) ;------------------------------------- sqrt: t equr r1 b equr r2 c equr r3 r equr r4 moveq #0,c movei #$10000000,b .sqrt0: move c,t add b,t shrq #1,c cmp t,r jr MI,.sqrt1 nop sub t,r add b,c .sqrt1: shrq #2,b jr NE,.sqrt0 nop move c,r RET nop equrundef t equrundef b equrundef c equrundef r pas rapide ni précis, juste court _32octets_(même raison que + haut)

bon, allez, j'my colle: ; r0=dividende ; r1=diviseur move r0,r2 xor r1,r2 abs r0 abs r1 abs r2 ; bit de poids fort à 1 si une des operande est négative jr CC,.positif div r1,r0 neg r0 .positif: me semble correct...

Bah non, au pire y'a que le dividende négatif, alors je fais ça: MACRO IDIV a,b abs jr CC,.pos~ div a, neg .pos~: ENDM ex pour les polygones pour calcul dx/dy, on s'arrange pour que dy soit positif (cas de l'inversion point haut/point bas du segment) ou pour la normalistation d'un vecteur, vx=vx/||v|| vy=vy/||v|| vz=vz/||v|| , la norme du vecteur v ||v|| est forcement positive. J'suis jamais tombé sur un cas positif/negatif Mais pitet qu'avec un XOR sur le bit de signe, on peut modifier la macros ci-dessus pour changer le signe du quotient seulement si -/+ ou +/- GT va nous arranger ça...

heuuu...on arrete et on réfléchit ? genre (j'le fais en 8 bits) : -20/2=-10 avec ta routine on tombe sur un $8A, négatif certes, mais pas - 10. (#-10 = $f6) Faire mumuse avec le bit de poids fort suffit pas, trop simple A mon avis, y'a pas moyen de s'en sortir sans au moins un JR

Ah ! C'est la méthode GT ? Coder pour que ça plante ! Marrant, perso je fais l'inverse ) !

tant qu'a faire, vu que tu recopie un bloc ecran quasi complet, sépare ton buffer écran de tes données graphiques ? D'une manière générale, c'est pas bon de bosser direct sur l'écran ! (sauf si t'as un fond/objet statique?)

Sans la routine, dur de trouver ton bug... Sinon, le polygone sans table c'est: 10 x_left+=left_inc 20 x_right+=right_inc 30 DRAW (X_left,x_right,y) 40 y++ 50 goto 10 On peut pas faire + simple !

Exactement ça ! Ça donne une référence pour des benchs, Merci Fred !

Une multiplication point*matrice ça donne ça en GPU: store rmat,(rd_mtxa) ; 129 moveta r0,r3 130 moveta r1,r4 131 nop 132 mmult r3,r8 ; (x.Vx+y.Vy+z.Vz+1*Tx)<<14 133 sharq #SCL,r8 134 nop 135 nop 136 mmult r3,r9 ; (x.Ux+y.Uy+z.Uz+1*Ty)<<14 137 sharq #SCL,r9 138 nop 139 ;nop 140 mmult r3,r10 ; (x.Dx+y.Dy+z.Dz+1*Tz)<<14 141 sharq #SCL,r10 142 143 add xcenter,r8 144 add ycenter,r9 Bon, bien sûr faut calculer la matrice caméra avant, mais ç'est pas mal rapide. En gros, trois MMULT pour les 3 colonnes de la matrice (pour la 4ième on s'arrange ) Le calcul de la matrice caméra donne à peu près ça: [code]cam2mat: tx equr r5 ty equr r6 tz equr r7 dx equr r8 dy equr r9 dz equr r10 ux equr r11 uy equr r12 uz equr r13 vx equr r16 vy equr r17 vz equr r18 movei #pos,r14 load (r14),tx ; translation vector load (r14+1),ty load (r14+2),tz neg tx neg ty neg tz movei #look,r14 load (r14),dx load (r14+1),dy load (r14+2),dz add tx,dx add ty,dy add tz,dz ; lookat vector ; normalize imultn dx,dx imacn dy,dy imacn dz,dz resmac r4 ;dx^2+dy^2+dz^2 if DEBUG ;BRKGPU endif CALL sqrt ; lookat vector length shlq #SCL,dx ; before div shlq #SCL,dy shlq #SCL,dz IDIV r4,dx ; lookat (Z) vector normalized (S.15) IDIV r4,dy IDIV r4,dz ; guess an up vector ; (temp hack, no roll ) movei #0,ux ; UP vector movei #1<<14,uy ; movei #0,uz ; guess a RIGHT vector ; cross(d,u) move dy,vx imult uz,vx move dz,r0 imult uy,r0 sub r0,vx sharq #SCL,vx move dz,vy imult ux,vy move dx,r0 imult uz,r0 sub r0,vy sharq #SCL,vy move dx,vz imult uy,vz move dy,r0 imult ux,r0 sub r0,vz sharq #SCL,vz ; re-cross product lookat & right move dy,ux imult vz,ux move dz,r0 imult vy,r0 sub r0,ux sharq #SCL,ux move dz,uy imult vx,uy move dx,r0 imult vz,r0 sub r0,uy sharq #SCL,uy move dx,uz imult vy,uz move dy,r0 imult vx,r0 sub r0,uz sharq #SCL,uz ; store (part of) the matrix ; we store only the 3*3 matrix (normalized(.14 values)) movei #cmat,r14 store vx,(r14) store vy,(r14+1) store vz,(r14+2) store ux,(r14+4) store uy,(r14+5) store uz,(r14+6) store dx,(r14+8) store dy,(r14+9) store dz,(r14+10) ; then we compute the 4th column (not normalized) ; must be added to results of MMULT 'by hand' ; translation values can overflow the 1.14 scheme. ;( T max=+/-32767 ) imultn vx,tx imacn vy,ty imacn vz,tz resmac r0 sharq #SCL,r0 store r0,(r14+3) imultn ux,tx imacn uy,ty imacn uz,tz resmac r0 sharq #SCL,r0 store r0,(r14+7) imultn dx,tx imacn dy,ty imacn dz,tz resmac r0 sharq #SCL,r0 store r0,(r14+11) RET C'est plutôt foireux mathématiquement parlant, mais ça fonctionne à peu près. Juste pour avoir une idée quoi !

Vous utilisez quoi comme polygone de référence ? (taille ?) À l'époque, y'a eu un début de benchmark sur AtariAge mais pas moyen de retrouver le sujet en question (en plus ça à plutôt changé depuis ) C'était un bench avec 3 différentes tailles de poly, puis une distinction flat/gouraud/texturé. Pis la jag remplis plus vite un poly étalé horizontalement qu'un polygone de même surface, mais étalé verticalement...m'enfin, j'me comprends... alors ?

GT, possible de mettre à dispo la routine complète ? Vu qu'y a pleins de bugs possibles (instruction après le JUMP/JR, LOAD et utilisation directe du registre...le MOVEQ à proscrire a moins de coller un "OR rn,rn" apres pour être sûr du contenu du registre) Sinon, sur jaguar, c'est une mauvaise idée d'utiliser des tables xmin/xmax, vaut mieux tracer les horizontales en paralelle du calcul. (ma dernière routine en date doit faire moins de 200 octets et pas besoin de buffer donc )

Perso, j'ai un peu laissé tombé mes projets (m'enfin, depuis le crash disque de mon serveur suivi de 2 crash disque consécutifs sur mon portable de dev :/). J'espère surtout être là pour partager les quelques trucs que je connais.

Salut ! Après quelques temps passés loin de ma jaguar, je reviens. Pas de nouveau projet mais quelques idées (OP poly, ça vous dit ?). Surtout, GT à besoin d'aide. Ne serait-ce que pour lui indiquer les bonnes pages ou regarder dans la doc vala... P.S: Special hi to Sym, Joe, Fredifredo, Pocket, Florian et Rayxamber que j'ai laissé un peu tombé :/