Jump to content
Jagware

SCPCD

Level2
  • Content count

    1,134
  • Joined

  • Last visited

Everything posted by SCPCD

  1. Changer de CMS, tôt ou tard.

    Je ne connais pas grand chose sur ce genre de truc mais c'est vrai que le site Cafzone rend vraiment bien. Plein d'options en plus (est-ce que l'on les utiliseras toutes ? : un jours sans doute ...), avec sans doute moins de limites au niveaux possibilités et tout et tout donc pkoi pas ?
  2. Pipe line, cache, ghost in the Gpu ?

    GT Turbo : Si tu essaies ce code la : load (r7),r4 ; Charge le X1 load (r6),r3 ; Pareil mais pour le X2 Boucle : sub r3,r4 puis une dizaine de ligne et : addq #4,r7 addq #4,r6 load (r7),r4 ; recharge X1 Puis vint une boucle de synchro et après on reboucle a 'boucle' Ca donne le meme résultat que celui au dessus (mais la on a une instruction en moins dans la boucle !!) GT Perdu !! Je ne sais pas ce que tu fais dans les lignes non données mais si tu ne modifi pas le r3, alors ca parait logique qu'il n'est pas necessaire de mettre le load (r6),r3. Par contre, je n'ai pas encore trouvé l'explication de l'erreur sur le premier code... A moins qu'il y est un bug dans le GPU sur les sauts qui en fait ce tromperais dans le calcul de la position du PC dans certains cas mais je ne me rappelle pas que ca a été decrit dans la liste des bugs. Une autre possibilité serais qu'il y est un bug dans l'assembleur MADMAC dans le calcul de l'adresse de retour dans certaines combinaisons.....
  3. Une belle bête incomprise : le blitter

    J'ai essayé ton prog Je n'arrivais pas à le lancé mais en fait, c'est moi qui n'envoyé pas le prog avec la bonne commande J'ai remarqué qu'il y avait un(ou 2) pixel(s) qui restait figé au milieu de l'ecran je sais pas si c'est normal ou pas... Sinon, OUAOU !!! la fluidité !!! en 68000 en plus !! Vivement la version face pleine !
  4. Une belle bête incomprise : le blitter

    HHAAA... Les joies du debuggage du GPU !!! Que du bonheur !!
  5. Une belle bête incomprise : le blitter

    En tout cas tu fais un sacret boulot !! J'ai hate d'avoir la demo sur une CF
  6. Une graphiste chez Jagware

    Bienvenue à toi !
  7. Saut conditionnel et code conditon (Gpu / Dsp)

    Pour les codes conditions, madmac ne les possedent pas tous... il faut donc les declarer soit même dans le programme DSP/GPU voila ce qu'il faut écrire par exemple dans la section GPU/DSP: Plus_petit_ou_egal .ccdef %11000 la liste des codes conditions implémenté par MadMac est : CC %00100 CS %01000 EQ %00010 MI %11000 NE %00001 PL %10100 HI %00101 T %00000 et voici tous codes conditions :
  8. Liste de possibilité de jeux :

    Que direz vous d'un Metal Slug !!! (version compilation des 5 episodes )
  9. Une belle bête incomprise : le blitter

    GT Turbo : Hier soir une dizaine d'essais pour commencer a optimiser et apparement cela marche, pendant un moment j'ai pensé a utiliser l'inter, mais cela risque pas d'ètre plus lent ? Un traitement d'interruption par un 68000 c'est pas très rapide et en fin de compte, l'inter elle meme va juste placer le flag donc on fait un traitement pour rien, l'ancienne technique est plus rapide je penses non ? Ben en fait, ca depend. Le system d'interruption sera plus rapide je pense que dans le cas où l'on met en veille le 68000 en attendant une interruption. Parceque dans les autres cas, on spam le bus pour ne rien faire : lorsque l'on accede aux registres, le bus est ralentit par la lecture du 68000 mais dans le cas où l'on veut faire des interruptions sans le mette en veille, c vrai que ca risque même d'être plus lent vu que lorsque le 68000 a une interruption, son niveau de priorité d'execution est plus élevé que normalement donc ralentit tout... (Mais pkoi ils ont mis un 68000 !!! et pas un autre DSP !!!)
  10. Une belle bête incomprise : le blitter

    Citation Un truc pas très loin : lea G_CTRL,a0 move.l #1,(a0) Wait : move.l (a0),d0 bne.s Wait je comprends pourquoi ca ne marche pas !! car lorsque tu lit G_CTRL, tu ne lis pas exactement la valeur de CTRL ecrit par le GPU !!! Car lorsque tu lis, il y a la version du processeur dans les bits le plus haut, et les latchs interruptions qui ne sont egal a 0 que si tu as ecrit un 1 dedans ! il faut donc juste tester le bit 0 de ce registre.
  11. Une belle bête incomprise : le blitter

    Cela viens peut-être du 68000 : Comment tu fais pour tester le GPUGO ? Parcequ'il y a un bug dans la jag pour certaines instructions 68000 lors de l'accés a des registres GPU/Blitter...etc.... c'est indiqué dans la liste des bugs pour l'ecriture mais pour la lecture je sais pas si c pareil (je pense que oui) Ensuite, sinon tu as plusieurs autres possibilité : - générer une interruptions sur le 68000 - utiliser une adresse dans la RAM GPU pour indiquer qu'il a fini et tu lis au 68000 cette adresse en permanance. La premiere est celle qui donnera plus de peche au GPU mais la deuxieme est la plus simple a ecrire. Je me rappelle que j'avais aussi des trucs bizarre avec le GPU lorsque je voulais verifier qu'il etait arreté. Du coup je faisait comme Native c'est a dire la seconde solution ecrite au dessus. wait_for_gpu: move.l All_Done,d0 cmpi.l #$12345678,d0 bne.s wait_for_gpu move.l #0,All_Done un truc de ce genre Et normalement, en faisant : [code] moveq #$12345678,r30 movei #All_Done, r31 store r30, (r31) ; GPU stoppen moveq #0,r30 movei #G_CTRL,r31 store r30,(r31) ca devrais fonctionner puisque je l'ai deja fait et dans Native aussi c pareil... mais peut-être que en ne faisant que [code] wait_for_gpu: move.l G_CTRL,d0 btst.l #0,d0 bne.s wait_for_gpu ca fonctionnerais... (si tu ne fais pas deja ca )
  12. Une belle bête incomprise : le blitter

    A non je me suis trompé J'ai verifié dans un de mes codes et j'ai bien fait comme toi...
  13. Une belle bête incomprise : le blitter

    Pour le GPUGO (Start/Stop du GPU), tu le fais comment ? Parceque, seul le GPU peut le remettre a Zero et il faut le faire en soft : c'est a dire en lisant le G_CTRL et en mettant a 0 le bit 0 puis de reecrire le resultat dans le registre. Mais du fait du pipeline, le GPU ne stop pas immediatement, il peux executer plusieurs instructions après si elles peuvent rentrer dans le pipeline avant la demande d'arret du GPU.
  14. Une belle bête incomprise : le blitter

    Multiplié par au moins 3 !! rien qu'en reecrivant au GPU !! et sans optimisation, je suis sur !! GPU PPPPPPOOOOOOOOOWWWWWEEEERRRRRRR
  15. Débat sur les listes de sprites.

    Salut ! Je voulais savoir : qu'elles sont les données modifiées par le OP exactement ?
  16. Une belle bête incomprise : le blitter

    Je pense qu'ils veulent dire qu'il est possible de faire du remplissage de polygone en un passage.... Mais je ne sais pas comment on fais le remplissage de polygone normalement alors...voila quoi...
  17. Débat sur les listes de sprites.

    Oui, et il serais même possible en theorie d'atteindre 200sprites/lignes*256lignes=51200 sprites par vbl. mais là je pense qu'il n'y aurais pas assez de place mémoire dans la RAM pour stocker la liste
  18. MadMac me les gonfles !!!

    GT Turbo : Par contre question SCPCD, tu trouves pas cela un peu lourd ? Devoir a chaque modif lancé tout cela pour vérifier ton code ? Ben en fait, , j'utilise aussi make.ttp. du coup je fais un 'makefile' qui contient les 2 lignes precedentes et il suffit juste ensuite de lancer make.ttp sans parametre et il fait tout tout seul. (bien sur, il faut que make.ttp soit a coté du makefile) sinon, pour lancer un makefile qui n'est pas dans le dossier ou il y a make.ttp, il faut lui donner comme parametre -f addr/nom_file bien sur, le makefile est structuré d'une certaine facon : ex: (il faut metre une tabulation devant aln et mac)
  19. MadMac me les gonfles !!!

    J'utilise les compilateurs ATARI je sais pas pkoi je n'ai pas indiqué avant la procedure que j'utilise... pour compiler : mac.ttp -fb -u -iincludes/ main.s -s -fb je sais plus il faut que je relise la doc -u permet la globalisation automatique des symboles non definis -s c'est pour qu'il t'indique les branchs 68000 que tu peux optimiser (en faisant bra.s ce genre de truc) -i suivi du nom de dossier a inclure si tu utilise des includes sans l'adresse complet (ex : .include "jaguar.inc" et que 'jaguar.inc' est dans le dossier 'includes') (le nom du dossier doit être collé au '-i') tu dois optenir un 'main.o' pour linker : aln.ttp -o test.bin -n -w -rq -a 4000 x x main.o -n pas de file header -w activation des warnings -rq c pour aligner chaque segment (text, data, bss) sur une quad phrase (32octets) tu peux ou bien metre : -rw -> word -rl -> long -rp -> phrase -rd -> double phrase -a text data bss : c pour choisir l'adresse de l'organisation des différentes sections : ex: 4000 -> adresse de debut du segment TEXT : le code 68000 x -> adresse des datas, si ce n'est pas une valeur mais 'x', c'est automatiquement mis a la suite du segment TEXT x -> adresse de la section BSS idem que precedement sauf que ce sera mis a la suite des DATAS
  20. Débat sur les listes de sprites.

    OK Tu devrais voir aussi pour utiliser les 'Branchs'. Comme ca, tu pourras, par exemple, decouper ton ecran par paquets de 200 sprites toutes les 16 lignes. -> 200sprites/paquets*(256lignes/VBL)/(16lignes/paquets) = 3200 sprites/VBL mais ca complique un peu la creation.
  21. Débat sur les listes de sprites.

    Juste une question : Comment tu fais pour que la liste fonctionne sans devoir remettre a jours la liste a chaque VBL ? vue que le OP, si je ne me trompe pas, modifie des champs dans la liste ???
  22. Débat sur les listes de sprites.

    J'ai dejà eu ce probleme de parasitage voir d'erreur de superposition des sprites : le sprite qui est au dessus ce retrouve a moitié coupé en diagonal par le sprite qui est en dessous.... je pense que ce probleme peut être causé par différents cas : - il y a trop de sprites et le processeur d'objet n'arrive pas a lire suffisament vite dans la RAM pour les gérer. (ca depend aussi de la largeur des sprites) Je pense que c'est ton cas GT : la bande passante de la Jag doit être saturée lors du chargement de la ligne par le OP. ex : j'arrivais a faire 7 plans en 640*250 et 16bits en 1VBL plus 1 en 640*30 ce qui correspond a charger 640*8*2= 10240octets par lignes pour toi GT : 200*37*2 = 14800octets par lignes a charger. Donc a mon avis on touche a la limite de l'OP par ligne. (sauf si on stop le 68000 ) - le code de génération de la liste d'objet prend trop de temps sur le bus et le OP n'a pas assez de temps pour tout lire en 1 VBL Le fais d'utiliser le même sprite, je ne pense pas que ca change quelque chose, vu que l'OP accedera exactement de la même facon a la mémoire independament du sprite suivant. (sinon, il faudrais qu'il precharge les valeurs du sprite suivant et qu'il fasse un pre traitement ce qui n'est pas indiqué dans la doc)
  23. Outils PC

    Je ne sais pas du tout quelle emulateur ATARI peu utiliser les port // Mais sinon, il serait possible de recoder ce qu'a fais GT pour windows. (dès que l'on connait le principe c'est du tout cuit, il reste a faire l'interface windows et recoder en C/C++ pour pas ce faire chier sous win et voila) Dans un premier temps il faut voir ce qui existe : Madmac et ALN linker existe sur PC aussi mais je crois qu'ils bugguent sous XP. Donc il faut Dosbox ou equivalent qui permet d'emuler un PC DOS sous win. donc pour la compilation ca devrais aller. et ensuite, il faut utiliser le loader bjl. Dès que j'ai fini le CF, je pourrais convertir les outils de GT sur Windaube.
×