cts
-
Content count
64 -
Joined
-
Last visited
Posts posted by cts
-
-
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 ?
-
JagCD
in Development
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).
-
JagCD
in Development
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é :/
Branche la hifi !!
in Development
Posted · Report reply
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 ?