GT Turbo

Fredifredo : As-tu regardé dans le code source que je t'ai envoyé ? ou bien celui de Pong ? Mon problème est plus un problème de code meme, pas de principe, et le petit truc c'est que beaucoup de personnes reconstruises la liste a chaque Vbl, c'est plus simple mais moins rapide c'est pour cela que d'autres sources ne sont pas trop a meme de m'aider, mais le truc ultra c.. c'est que je fais les essais d'abord au 68000 pour après recoder le tout au Gpu, je ferais mieux d'attaquer au Gpu direct, j'ai l'impression que je me débrouilles mieux avec lui qu'avec le 68000 Ca va se finir comme cela..... GT Un super pote au Gpu

Azrael : Je ne sais pas si Steem gère les entrées-sorties du port parallèle. Pour l'instant si on tient compte que c'est moi qui ait ta Jag !! Et le kit Bjl aussi, on peut regarder la semaine prochaine quand tu débarques. Sinon pour l'instant c'est émulateur, de toute façon sans gestionnaire de liste on affiche rien donc pour l'instant, c'est 'gland power !' Yété

J'ai enfin les explications a mes questions, hier j'ai vite écrit un déssassembleur Dsp / Gpu, et profiter pour regarder la structure du fichier résultant d'un assemblage proc. Le fichier est un fichier au format Gemdos avec entete et tout le toutim. A la base le fichier fait 538 octets, si on garde que le code celui ci ne fait plus que 248 octets (90 lignes de code dsp, routine de lecture des pads). Je penses qu'en utilisant le linker celui ci dégage les infos supplémentaires, vu que je ne l'utilises pas, faut que je coupes les fichiers a la main !! Pour info, j'ai vite fait un essais, ces 90 lignes de code Dsp en équivalance 68000 cela fait 3 instructions, ca calme hein !! Oui vous avez bien lu, le temps que le 68000 execute 3 instructions, le Dsp en a aligné 90 !!! Et encore les instructions 68000 utilisés sont pas des instructions lentes. GT Turbo

Je connais pas les outils PC donc je peux rien dire, les outils Atari codé pour la Jag sont express écrit propre et devrait tourné sous émulateur (Steem, peut etre le noyau Aranym, etc...). Fredifredo ou SCPCD pourront te répondre un peu plus, sinon pour l'instant, je penses que des cross-compiler 68000 existe sur PC, je veux bien recoder les routines pour les procs. Question tu a déjà essayé Aranym ? Tu peux sinon utiliser Devpac sous émulateur, il est compatible Gem donc tu dois pouvoir l'utiliser dans n'importe qu'elle résol. GT Turbo

SCPCD : Je n'arrive même pas a imaginé ce que l'on pourrait réaliser pour la Jag avec tout nos projets.... Plus rien peut nous arreter, le seul truc qui nous arretait c'était l'espace dispo pour les progs mais la CF a abbatu cette limite, maintenant c'est a nous de jouer !! GT En train de tout peter (Surtout mon code !! )

SCPCD : Il y a aussi la possibilité de faire des générateurs de niveaux aléatoires ? Après ca depend du type du jeu.... Ca c'est une bonne idée, c'est vrai que cela s'apllique pas a tous les jeux, mais faut le garder bien au chaud. Ou générer des niveaux d'après des clefs, comme cela tout le monde aura les memes niveaux, et les niveaux seront de petite taille. Faut que je notes tout cela. GT En train de tout noter

Non, le nombre de sprite peut ètre impaire, je vais vérifier certaines choses, car le plus c.... c'est que la liste doit se trouver sur une adresse multiple de 8 (Cela passe encore), un ojet bitmap standard doit ètre aligné sur 16, un objet bitmap zoomé sur 32, donc faut que je vérifies aussi tous les alignements (Cela fait que la 4 fois que je le fais !) GT Pas sur la limite !!

Et maintenant comment conciler cela avec un jeu qui doit avoir un paquet d'heure de jeux, on pourrait faire comment ? - Un maximun de niveau (grace a la place sur la CF (Et ou de la pub meme ici !)) Et après j'ai plus d'idées !!! GT Trop nul au jeu

AAAAAAAAAARRRGGGHHH !! Je vais finir interner !! Mon gestionnaire de sprite ne veut pas m'écrire mon objet de fin de liste (Stop objet) en 3 position quand j'ai deux objets !! Avec un objet cela marche parfait, mais avec 3 il s'amuse a me placer un sprite 'objet bitmap' vide a la place et bonjour le plantage !! Je vais me calmer un peu et reprendre plus fort, c'est pas un bout de code qui aura ma peau !! Parce que GT Trop fort (Et surtout très vantard....) GT En train de me calmer !!

Faut que je me prennes un peu de temps, The Escapist a l'air d'avoir des trucs intérressants. GT

Je trouves cela marrant, on utilise un micro pour debugger du code présent dans la ram de la Jag. Je vais voir pour modifier le Ram-debbuger pour qu'il transmette dès qu'il y a un plantage le contexte de l'erreur au micro en mode tout-automatique. GT Parti chasser le bug !!

Mes snap sont de pire en pire, oui je sais, vu que j'en ai marre de jouer avec les deux moniteurs, de devoir après modifier le fichier de snap a la main, je me suis mis a le faire de façon polonaise, appareil numérique et hop in the pc, le probleme c'est que j'avais pas fait gaffe a la résol, donc j'ai du un petit peu coupé l'image, mais si vous tournez la tete vous réussirez a voir quelque chose : GT De traviol !! Edit : merci a Azrael pour la rotation de l'image Re edit : remplacer l'ancienne image par une photo presque normale !!

Vu que maintenant je peux debugger les listes de sprites, j'ai pu réparer ma routine, et j'ai commencé a écrire les routines pour modifier les coordonnées, en X cela est passé tout seul en Y j'ai un petit soucis suite au fait de la restauration de la liste vu qu'elle n'est pas réconstruite a chaque Vbl (Power !!! ), mais ce soir j'attaques de plein pied !! GT Parti coder !!

C'est incroyable mais voir ce qu'on fait c'est 'beaucoup plus meilleur', on code mieux quand on voit ce qu'on fait !! (Par respect envers les codeurs ne répondez rien d'intelligent a ceci !) Dès que je passes chez RaZ je vous mets une photo d'une 'sprite list' GT En train d'ouvrir les yeux !!

Comme c'est bon, j'ai écrit la routine de 'démontage' de liste d'objet pour le débuggeur, p..... la classe !! (Excusez moi pour l'expression), je sais maintenant pourquoi mes listes d'objets partent en fleur (Hauteur de l'objet : 0 ! Argh et le Pitch : 0, le pitch permet de déplacer la 'téte de lecture des données sources' pour la lecture de sprite, le mettre a 0 fait que le meme morceau sera recopié sur tout le sprite. Avoir des outils rien de tel pour develloper. GT Heureux !! P.S. : Pensée pour SCPCD qui (Je penses !) n'a pas dormi !!

Je vais reprendre le debugger je penses, car ce matin j'ai modifié la routine de gestion de liste et boum plus rien s'affiche et j'ai du mal a trouver, j'aimerais beaucoup affiché les valeurs contenues dans ma liste, mais bien sur, pour afficher quelque chose faut encore qu'on puisse le faire..... Vu qu'en plus Bastian m'a passé les sources, cela va facilité le devellopement. Donc option prévu : - Chargement et lancement de code - Différentes bricoles (Lancement du jeu cartouche, reset soft de la Jag, etc..) - dump de la mémoire a l'adresse voulu - déssassemblage 68000, Gpu, Dsp - tracage des procs - modification des regs procs - affichage des regs bien sur - lecture et écriture de mot en ram - lecture et écriture dans l'eeprom (On va se faire des high scores sans jouer....) - Un nouveau ram debugger Cela est mon premier jet, si quelqu'un voit plus loin ! GT En train de debugger !!

Je reprends un peu le code ce soir, et a partir de demain soir, je me bloques le weekend sur la gestion de liste, je veux voir des sprites, des sprites a la tonne, mon écran plein de petit spritos tout colorés, désolé pour le délire mais j'ai trop hate. GT Amoureux des sprites

RaZ : Sacrifier une partie de son score/argent ou même un crédit pour recommencer à un checkpoint avec un équipement légerement depreciés. Ou même avoir le choix parmis plusieurs options, et donc plutôt que de définir une difficulté avant d'entrer en jeu, moduler soit même son experience in vivo. En plus les mauvais joueurs comme moi (A quelques exceptions pretes: Blood Money, Xenon II) aurait une chance de laisser leur console allumé car ils pourraient avancer, recommencer plus de trois fois un 'truc' me fait monter la tension, et souvent cela se finit par deux fins : destruction de l'appareil qui m'a énervé, ou apprise du vol plané a la susdite console (Remarquez que pour l'instant seule la Jag n'a encore rien pris dans la figure, cela s'explique surement par le fait que le peu de jeu ultra intérressant sur cette console fait que j'y joues pas.... ) GT Plutot un codeur, mais c'est parce qu'il n'y a pas de très très bon jeu (Exception faite pour bubsy...)

Que dire de plus ? je suis pas un grand joueur (Bien loin même !), mais c'est vrai que se taper 2 minutes de balladage dans les menus avant de jouer cela calme un peu. Je raconterais pas beaucoup plus car ce n'est pas trop mon rayon, moi je suis la pour la partie technique, c'est aussi pour cela qu'on aime notre RaZ(mokette !), il cherche plus loin que la relation pad-sprite, auquel je suis si intimement liée !! GT Trop superficiel !!

Azrael : Mouais, si ça continue on va retirer le 68000 car il bouffe du temps d'horloge sur le bus C'est exactement cela, le but du jeu c'est de rentrer le maximun dans le couple Gpu / Dsp et de carrément mettre le 68000 en attente, pour éviter qu'il nous traine ces boulets !! GT En train d'accélerer !

Je fais remonter ce sujet, car j'ai commencé a écrire un gestionnaire de liste, pour l'instant juste au 68000 (Quoique que vu les décalages et les bricolages sur les champs de bits, le Gpu serait plus de mise). Je réécrirais celui ci après au Gpu, cela pour des histoire d'optimisation et de controle. Le but étant bien sur de tout faire au Gpu, mais absolument tout, cela pour éviter de plomber le bus avec notre 'escargot' de 68000, le maillon faible d'une Jaguar. Au départ j'avais prévu une base de 192 sprites, car c'était divisible par 32, mais après calcul et essais, je m'apercois que le procédé que je voulais utiliser est plus lent que l'actuel et mange de la ram en plus pour rien, donc 'au revoir !'. Je vais allez continuer le code, a plus !! TG orbuT

Traduction pour ceux qui ont pas bac+12, l'opération consiste juste a faire une opération logique entre les masques (Sprite en deux couleurs, noir et blanc ou noir et une couleur pour les points), le résultat de cette opération donne 0 si les sprites se touchent pas et 1 si ils se touchent (Voir sur le site de Patrice Mandin), si mes souvenirs sont bons il explique le principe en plus détaillé. L'avantage que cela permet c'est du test de sprite au pixel près, plus de 'P...... de jeu de m...... j'ai explosé et pourtant le tir est passé a coté ' GT Turbo

En train d'écrire la gestion de liste au Gpu, je me suis apercu que je pouvais intégrer la routine de collision directement dedans, vu que pour chaque objet, dans la description on possède sa position et sa taille, après il n'y aurait plus qu'a tester si intersection, si oui 'XOR ER' les masques et voir le résultat, il ne reste plus qu'a generer les masques, la génération doit pouvoir se faire en automatique, histoire de pas se prendre la tete, je recoderais surement les masques true color en bit, cela permet de diviser par 16 la taille par rapport au sprite (1 bit=1 pixel) et pour faire le 'XOR' cela accellera aussi le traitement. GT Turbo

SCPCD : Il faut faire attention, je ne sais plus trop mais je crois qu'il y a des bugs dans le blitter pour le clipping dans certains cas. J'arrete pas d'y penser, mais pour l'instant je cherches surtout la manière la plus rapide de faire du remplissage et pour l'instant je voies que cela. A MORT LES DOOM LENTS OU EN BASSE RESOL !!! GT en train d'optimisé sans écrire de code !!

Azrael : J'avais vu qu'il y a une fonction Zbuffer dans le blitter, mais je ne sais pas trop comment elle fonctionne. Si c'est du tri pour faire un affichage d'objets 2D dans un environnement 3D et s'il est possible de récupérer le liste triée, alors on pourra faire du tri sur les polygones. Apparement cette fonction permet juste en cas de copie de bloc, tracé de lignes, etc.. de comparé ton Z avec celui présent en dessous, d'après ce que j'ai pu comprendre. Mais j'ai l'impression qu'il va falloir utiliser par contre la meme technique que sur micro, balayage des lignes du polygone puis remplissage ligne par ligne, ce qui fait peur avec de genre de technique c'est le calcul des valeurs du blitter mais plus de temps qu'a remplir avec un peu de code, sinon il y a peut etre une autre technique, on remplit entierement chaque ligne, enfin on calcule les valeurs pour remplir a chaque fois la ligne complete et on joue avec les registres de clipping, on clippe a gauche et droite avec les X, X1 de notre polygone , est ce que cela serait assez rapide ? Car on aurait pas beaucoup de registre a modifier d'une ligne a l'autre GT