SebRmv
-
Posts
1,553 -
Joined
-
Last visited
-
Days Won
1
Posts posted by SebRmv
-
-
d'accord donc c'est le load (r14+rn) que j'avais mal interprété
En fait, c'est la phrase "Otherwise like instructions 43 and 44" qui m'a fait extrapoler un peu
Seb
-
Alors autre question en rapport
(puisque mes index en registre amenaient à cette situation)
Que fait la Jag en cas d'accès non alignés :
1- en mémoire interne
2- en mémoire externe
??
Pour Project Tempest 0.95
les accès mémoire non alignés
1-en mémoire interne : plantent PT
2-en mémoire externe : font quelque chose (ne plantent pas toujours en tout cas)
Pour la 0.5, les deux font quelque chose (ne plantent pas).
Seb
-
Le "load (r14+rn),r5" est différent de "load (r14+n),r5"
dans le premier cas :
le load lit la valeur a l'adresse r14+rn, dans le second cas, le load lit ce qui est a l'adresse r14+4*n.
Car n est un offset en long word et non en byte.
Si tu reprends l'idée de l'adressage de tableau, tes cases de tableau étant en long word tu accedes a la seconde valeur en allant a l'adresse X+4*1.
C'est ecrit dans la doc :
"The offset is in long words, not in bytes, therefore a divide by four should be used on any label arithmetic to give the offset."
d'accord
donc c'est le load (r14+rn) que j'avais mal interprété
merci je comprends mieux alors
(mais c'est quand même un peu bizarre cette histoire, je ne comprends alors pas pourquoi ça se comporte comme je veux avec les load (r14+rn) alors que je divisais par 4 les valeurs dans rn)
Seb
PS: de toute façon, j'ai changé mon fusil d'épaule et réécrit le code autrement du coup!
-
Seb,
C'est pas juste parceque le load (RN+n),RN prend le 'n' comme un index de LONG ?
Me suis déjà fait avoir...
oui, c'est ce qu'il y a écrit dans la doc
moi je comprends donc que si j'ai un tableau de longs mots (tableau aligné évidemment)
et que r14 pointe au début
je peux accéder au i-ème élément avec (r14+i)
mais est-ce que ça ne serait pas plutôt (r14+4*i) ?
Seb
-
Super
D'ou l'imcompatibilité avec certains codes, assemble a la main (dc.w $xxxx) (Heuresement que c'est un Risc) GT Artisanal dans mon code
non, je pense que tu m'as mal compris
je disais juste que pour PT, ma transformation
de code est valide (comme je m'y attend quoi
)Seb
-
A première vue, ton code est tout a fait juste, MadMac aurait peut ètre du mal a assembler le 'load (r14+n),rn' et le 'load (r14+rn),rn' doit fonctionner, tu as essayé de déssassembler ton code pour voir ce que MadMac a gribouillé ?
GT Curieux
oui, ça avait l'air d'être bon de ce coté là
j'ai aussi oublié de dire que Project Tempest émule mal
la Jaguar (on le savait!) puisque ces deux codes sont
équivalents sous PT!
Seb
-
J'avais dit que je ne dirai plus de mal du GPU mais là!!
j'ai litéralement ce bout de code au milieu d'une routine au GPU (devinez laquelle!)
...
moveq #RANDGEN_J,r4
load (r14+r4),r5
...
maintenant, si je remplace donc ces deux lignes par:
...
load (r14+RANDGEN_J),r5
...
alors là, tout foire!
(enfin, ça ne se comporte mais alors plus du tout de la même façon)si quelqu'un a une explication, je prends!
Seb
-
En compilant avec les librairies graphiques sous gcc ça ne fonctionne pas ? avec la libjpeg, la libtiff, libpng, libpng, libtga... je ne m'y suis pas lancé, mais ça devrait fonctionner, non ?
hop là, bon, je viens de voir la réponse d'Azrael...
la librairie camlimages utilise effectivement libjpeg, libtiff, libpng, ...
à noter que je peux aussi fournir (à la demande) un binaire qui marchera (je l'espère) sous linux (mandriva 2006 mais peut être les autres aussi)
je peux aussi compiler une version "bytecode" (plus lente) qui marchera probablement sous cygwin aussi
et puis, en fait, je voulais surtout dire que j'avais fait un update qui permet maintenant de traiter les modes palette
Seb
-
A noter que s'il y a quelqu'un de motivé pour ce projet maintenant, je veux bien l'aider à se familiariser avec les petites bibliothèques que j'ai fait pour Atomic... en parlant de ça, j'ai corrigé un bug dans la création des sprites zoomés et j'ai ajouté quelques macros qui feraient rougir cts
Voili voilà
Seb
-
Bienvenue aussi aux "petits" nouveaux
(comme si j'étais un grand ancien
) Seb
-
Just want to say 'Hi' finally I could register
Welcome, happy that you finally manage to register
Seb
-
Je voulais juste ajouter que les valeurs initiales ne doivent pas être toutes nulles bien sur!!!
-
Salut,
comme moi aussi j'ai eu besoin de faire des nombres aléatoires, je vous propose ce petit algo (ça s'appelle ranrot quelque chose)
Ca donne des résultats pas mal
Pour initialiser, appeler random_init (ou mettre les graines que vous voulez dans le tableau), ensuite random_next calcule un nouvelle valeur sur 32 bits...
Enjoy!
Seb
RANDGEN_J equ 3 RANDGEN_K equ 7 ; k > j RANDGEN_R equ 5 .text .68000 random_init: move.l #random_seeds,a0 move.w VC,d1 swap d1 move.w HC,d1 moveq #RANDGEN_K,d0 .init_seeds: eor.l #$31415926,d1 move.l d1,(a0)+ ror.l #8,d1 ror.l #5,d1 move.w VC,d2 swap d2 move.w HC,d2 add.l d2,d1 dbf d0,.init_seeds rts random_next: move.l #random_seeds,a0 move.l RANDGEN_J*4(a0),d0 add.w #RANDGEN_K*4,a0 move.l (a0),d1 moveq #RANDGEN_K-1,d2 .shift_seeds: move.l -(a0),4(a0) dbf d2,.shift_seeds add.l d1,d0 ror.l #RANDGEN_R,d0 move.l d0,(a0) rts .bss .long random_seeds: ds.l RANDGEN_K+1
-
Salut,
avec GT, on va bientôt rendre disponible la routine de collision "au pixel près" écrite au GPU. Elle marche pour les sprites 16 bits mais ne gère pas les champs PITCH ou REFLECT. La méthode utilisée est inspirée de l'idée de Patrice Mandin sauf qu'elle ne construit pas de masque explicitement
. Cela dit, je suis persuadé qu'on peut faire une routine plus générale au blitter qui marcherait dans tous les cas de figure (1 bit -> 32 bits, avec gestion de PITCH et FIRSTPIX). L'idée serait de faire générer au blitter le masque (avec un des deux modes de comparaison du blitter). Ensuite, on pourrait probablement refaire le même genre de trucs avec le deuxième sprite mais cette fois en utilisant le mode "collision detection" (qui porte surement bien son nom
) Bon, je ne sais pas si on gagnerait en vitesse par contre, et je ne sais pas non plus si ça serait utile en pratique d'avoir la routine "la plus générale" possible.
Et puis bon, 'faut comprendre notre ami le blitter avant ça
.Seb
-
Avoir une personne qui s'occuperait que de ca, ou presque. On peut s'afficher communauté francophone mais cela n'empeche pas d'acceuillir nos collègues.
Perso j'ai vaguement discuté avec un passant sous le pseudo de TXG/MNG, il serait l'auteur du cinepack avec le trailler de nutty (?) et de doom 3, il s'y connait un peu en technique, quelqu'un le connait bien ? Ou quelqu'un a une autre personne a proposer ?
GT
forcément, si t'as pas de JagCD, ça te dit rien
bon, apparemment c'est pas un codeur, mais il est plutôt de bonne volonté
(c'est lui qui est à l'origine de CD encrypté avec Atomic...)
Il a un kit dév CD et sait donc faire du Cinepak...
Je l'ai invité à s'inscire ici vu que ça avait l'air de l'intéresser de faire des trucs sur la Jag'
Seb
PS: http://www.u-235.co.uk/index.php?screen=downloads&part=txgcd
pour le CD en question
-
et voici tous codes conditions :
elle est où la suite?
quelqu'un peut remettre le lien?
-
Félicitations SebRmv, du bon boulot
merci merci
-
Salut,
A tous ceux qui étaient présents hier soir sur la discussion du GPU,
oubliez l'hypothèse de bug qu'on a soulevé, c'est pas du tout ça!!
Pardon GPU, je ne douterais plus jamais de toi
Le problème était que je lisais un mot long à une adresse non alignée
sur 32 bits (mais sur 16 bits)... du coup, en rajoutant un nop, ça corrigeait
ce problème!
Cette macro peut être utile dans MadMac:
.macro align32nop
.if (*-\1)%4 == 0
.print "Adding padding nop"
nop
.endif
.endm
et c'est bizarre, l'* n'a pas l'air d'être l'adresse du nop
mais l'adresse du nop +/- 2
ce qui explique le == 0
Seb
et c'est bizarre, l'* n'a pas l'air d'être l'adresse du nopmais l'adresse du nop +/- 2
ce qui explique le == 0
non, en fait, c'est juste madmac qui est pourri et qui ignore superbement
le == 0
donc la condition est vrai si (*-\1)%4 est non nul
c'est à dire = 2 si on suppose que * et \1 sont toujours pairs!
Seb
la bonne macro est donc
.macro align32nop
.if (*-\1)%4
.print "Adding padding nop"
.print (*-\1)%4
nop
.endif
.endm
-
merci !
je viens de regarder et c'est effectivement le même code que j'utilise, c'est vraiment très étrange !
en fait, la seule différence, c'est le move.l #vbl_flag à la place du lea mais je crois pas du tout à cette hypothèse
-
ouaip, les sources très très bientôt disponibles...
sinon, je compile avec les flags suivant pour MadMac: -fb -u
pour Aln: -n -w -rq -a 4000 x x
Seb
bah voilà, c'est fait... rendez-vous sur le site des Removers pour les sources!
Seb
-
ouai, c bizarre.
car si SebRmv utilise la même routine de vbl, je vois pas ce qui cloche...
L'emulateur ne doit pas aimer quelque chose que tu fais a coté peut être ?
Mais quoi....
Il faudrait voir le code de SebRmv qui fonctionne sur emulateur qui utilise les même routines VBL pour voir la différence
ouaip, les sources très très bientôt disponibles...
sinon, je compile avec les flags suivant pour MadMac: -fb -u
pour Aln: -n -w -rq -a 4000 x x
Seb
-
Salut,
ce qui est marrant, c'est que je n'ai rien fait de spécial pour que ça marche sur Project Tempest.
J'utilise la technique de GT Turbo à l'identique!
Seb
-
... au bon endroit, un jeu, c'est du software.
oops là, désolé, j'ai vraiment pas fait gaffe en créant la news
-
Je viens de passer sur Jaguar Sector II, un sujet a été ouvert pour parler de la version Jag que SebRmv a faite, voila une recopie :
WOW, that's looks better than a Starcat game Who mad the game?
SebRmv si tu connais pas Starcat, c'est un allemand qui en attendant de sortir un grand jeu d'aventure baptisé Eerival il sort plein de bricoles (Mastermind, etc...) et d'un point de vue général, la phrase précédente est un très grand compliment.
J'ai écrit comme toi il venait de toi, histoire de remettre les choses a leur place, si tu est ok fais signe qu'on le place en news car sinon ton jeu aura fait le tour du monde avant meme d'avoir fait un release public ici !!
GT
Sympa le compliment... bon, pour avoir reçu et essayé Bomb Squad hier, je crois que ça mérite la comparaison en tout cas
Pour la news, j'ai ouvert un topic et j'imagine qu'il faut que RaZ le débloque maintenant (ou alors je me suis vautré en créant la news)
Seb
Génération de nombres aléatoires
in Development
Posted
Alors pour renforcer encore un peu mon image de "macro man"
voici le random next au gpu!!
ça complète le code 68000 que j'ai donné au-dessus
un usage typique est
gpu_random_next_init r0
gpu_random_next r0,r1,r2,r3
ici, r3 contient la nouvelle valeur pseudo aléatoire
Seb