GT Turbo

SCPCD : En tout cas tu fais un secret boulot !! J'ai hate d'avoir la demo sur une CF Je t'avoues que cela répresente pas tellement de boulot, je suis parti d'un source 68000, qu'on avait devellopé pour faire des polygones pour nos démos, après un peu d'optim pour s'adaptater au mode vidéo (C'est le pied l'optim en true color, plus de calcul de bit et d'offset en utilisant des techniques plus ou moins exotiques ! ) et après un transcodage pour le Gpu, qui faut le dire est très simple a programmer pour ceux qui s'y connaissent un peu en assembleur !! Pour l'instant le plus gros boulot c'est toi qui l'a fait (Voir CF !), faudrait encore que je fasses pareil pour la routine 3d, car voir un paquet de polygones fixes a l'écran c'est pas très répresentatif !! GT En train remplir et j'ai bientot fini !!

La routine est presque fini, j'ai enfin pu avoir des tests corrects (Voir dans cette meme partie ma petite prise de tete avec les sauts conditionnels), enfin il me reste encore deux bugs, qui font que ma recherche de Y min et Y max du polygone partent en fleurs, mais je penses que ce soir, la routine fonctionnera !! GT En 3D !!

Merci je vais enfin pouvoir finir la routine de polygone. Maintenant je sais aussi pourquoi mon clipping gauche ne marchait pas malgré le meme code qu'a droite !! GT Presque a la fin !!

Comme cela on a une liste de jeux, quand on aura plus d'idées, en plus pour l'instant c'est rien que du bon jeu (Cela n'engage que moi !). Partant aussi pour Meta Slug, j'y ais joué sur PS2, le genre de jeu que j'aime !! J'update la liste au fur et a mesure GT Un bourrin !!

M...... m...... et m...... Il va falloir que refixes mes objectits a la baisse..... Encore trompé a la ..................... hausse !!! J'ai pratiquement fini la routine 100% full Gpu, mais hier soir pour faire une transition dans mes 48 versions de mon code, j'ai fait une version intermédiaire, calcul des points 68000, remplissage au Gpu mais utilisation de la ram Gpu pour rentre les coordonnés X,Y et la je finis avec 39 polygones, si on compare au 7 du tout début au 68000, il y a pas photo, le rapport est de 5 fois plus (Et meme un peus plus !). La routine de calcul des points au 68000 est fini, mais j'ai quelques soucis a faire accepter mes saut conditionnels a Mad Mac. J'espère que ce soir la routine 100% Gpu sera opérationnel. J'avais visé les 40 polygones et bien on se fixe un nouvel objectif 48. GT toujours pas a fond !! Non !! Gpu Power !! P.S : Pour l'instant avec le code de restauration des listes au Gpu plus la routine de remplissage au Gpu (+Blitter) j'en suis meme a 350 octets !! Asm Power !!

Je suis en train de tout mettre dans le Gpu, donc voici en clair pour afficher un polygone comment cela va se passer : vous devrez juste passer : l'adresse de votre tableau de points (X,Y) qui devrait ressembler a ceci : Tab_XY: dc.w 160,100 dc.w 200,40 .... dc.w -1,-1 La dernière ligne indique a la routine la fin des coordonnées. La routine referme toute seule le polygone, puis l'adresse de votre écran et la couleur du polygone, un dernier truc l'offset pour passer a la ligne suivante, dans le cas ou votre écran ferait pas par exemple 320 colonnes voila ca devrait etre tout. si des personnes n'aime pas cette organisation, dite le moi, je veux pas reecrire toute une partie de code alors que j'aurais fini la routine !! GT En train de finaliser la routine Gpu

SCPCD : 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. Un truc comme un : <

Note, rajout a faire dans la routine de gestion : - rajout d'un hot spot (Point d'action du sprite), par exemple pour des tests, c'est peut etre mieux de considérer le centre du sprite et pas un angle. - animation : j'ai de la place dans la structure de ma liste pour rajouter quelques paramètres, donc faut que je rajoutes l'animation (Elle sera géré automatiquement par le gestionnaire), en boucle, en sens unique, en aller retour, exemple : un vaisseau les flammes des propulseurs, on s'occupe de rien, on indique les sprites lors de la création, le sens de l'anim et hop c'est fini. Yété !!

Après cette brève incursion dans la 3d je vais retourner afficher mes sprites (dès que la routine full Gpu fonctionnera), faut que je finisses mon gestionnaire de liste GT Reparti pour le sprites !

Comme cela ca marche mieux : lea G_CTRL,a0 move.l #1,(a0) Wait : move.l (a0),d0 btst #0,d0 bne.s Wait 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 ? Parce que du coté Gpu, a la place de mettre 0 dans G_CTRL il suffit de mettre 2 (%10) pour generer l'inter. J'ai dégagé plusieurs compteur décimales que j'avais (5 au total) j'en ai dégagé 3 et je suis a 32 polygones. Ceci est une broutille. J'ai completement réecrit la routine de calcul des points au Gpu, il me reste juste a voir pour le passage de paramètres et la mon but c'est les 40. J'ai pensé a un super truc mais qui va me couter assez cher en ram 1600 octets. Par la j'ai les 2 routines (remplissage et calcul) a part, ensuite je comptes bien les recoller, mais il me faut les tableaux x min et x max de chaque ligne, au lieu d'utiliser la ram standard, je pourrais utiliser la ram Gpu, j'évites de toucher au bus et je profites de la vitesse d'accès mais la ou ca fait mal c'est cela : J'ai deux tableau de 200 lignes (Pour un écran de 200 lignes of course !), ce qui fait (2+2)*200=800 octets, mais le petit soucis c'est que le Gpu en interne ne fait que des accés 32 bits (4 octets) ce qui fait que mon tableau ferait (4+4)*200=1600 octets, ca fait cher, mais c'est le prix a payer pour que cela pousse. Pour résumé dans la ram Gpu faut que je cases : - le gestionnaire de liste - la routine de polygone - 1600 octets de tableau Un défi bien interressant, par contre après je passerais au Dsp, car la ram va bientot me manquer !! GT P.S. : Je viens de réaliser un truc, hier soir j'ai essayé ca : [code]lea G_CTRL,a0 move.l #1,(a0) Wait : btst #0,3(a0) bne.s Wait Et ca a planté direct, c'est simple 90% des registre de la Jag necessite un accès en long (4 octets) et la je fais un accès octet !! Moi et ma tête !!

SCPCD : 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. Exact, j'avais pas pais gaffe au reste du registre, merci pour le coup de pouce, je modifierais mon code ce soir. Un problème en moins ! GT Débuggué !!

SCPCD : - utiliser une adresse dans la RAM GPU pour indiquer qu'il a fini et tu lis au 68000 cette adresse en permanance. J'ai déjà essayé et ca marche pas SCPCD : mais peut-être que en ne faisant que wait_for_gpu: move.l G_CTRL,d0 btst.l #0,d0 bne.s wait_for_gpu Un truc pas très loin : [code]lea G_CTRL,a0 move.l #1,(a0) Wait : move.l (a0),d0 bne.s Wait J'ai meme essayé un tst.l (a0) mais que nenni !! Je vais essayer la méthode que tu m'as décrite mais c'est bizzare ce truc, tu me diras un de plus !! GT Presque perdu

SCPCD : A non je me suis trompé J'ai verifié dans un de mes codes et j'ai bien fait comme toi... Juste il va falloir que je cherches..... hé m....... J'hallucines !! Car le truc c'est que cela marche pendant une dizaine de fois et après le code 68000 se retrouve bloqué sans raison. Le 68000 ne dispose pas de cache donc rien a voir de ce coté !! Le problème quand on devellope sur la Jag, non ce n'est pas la difficulté de programmmer ou autres, c'est de tout synchroniser !! ARGHHHHHHHHHHHHHHHH GT Asynchrone

Azrael : Citation GT Turbo : il faut savoir une chose ultra importante, le Dsp est libre Et la musique ? c'est le DSP qui s'en charge, non ? Au final ça ne fait plus trop de temps libre... Le mapping sous AVP est fait au GPU ou au Blitter ? Le dsp est effectivement prévu pour la musique mais une routine de zik de 12 Kilos c'est écrit en basic !! Ou elle dispose d'un sacré paquet d'options. Le mapping doit ètre fait au blitter, tu peux recopier une ligne (pas droite) en la zoomant avec le blitter donc cela simplifie beaucoup les routines de mapping !!! Tu peux utiliser le Gpu pour calculer les valeurs a mettre dans le blitter, vu qu'ils sont 'super potes' ca va plus vite !! GT Un copain au Gpu !!

SCPCD : 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. J'ai effacer le registre comme cela : store r20,(r22) avec R22=G_CTRL et bien sur R20=0 a priori donc l'écriture directe pourrait ne pas marcher, il faudrait faire comme tu a écrit. Si l'écriture directe ne marche pas ou pas correctement, mon Gpu execute du code après ma routine !! si c'est vrai la routine est encore plus rapide. Pour le pipe line je sais j'ai un paquet de nop derrière GT Pas effacé !!

Azrael : Joli, mais je dois jouer mon rôle d'emm.... Une question me taraude : y-a-t'il en core du temps machine pour faire d'autres calculs ? Et quelle taille font tes polygones ? Et question subsidiaire : AVP et Iron Soldier tournaient-ils en 1 vbl ? Oui, car il faut savoir une chose ultra importante, le Dsp est libre !!! Et oui l'avantage des procs en parallèle. Pour l'instant il sert juste a lire les Joypads, ce qui fait une routine de 280 octets, alors qu'il y a de la place pour 12 Kilos, le 68000 s'emmerde aussi, mais celui la on le laisse de coté a part me pourrir les codes, c'est tout ce qu'il a réussi a me faire.... Et en plus, une partie de mon code Gpu passe son temps a attendre que le blitter est fini la ligne pour balancer la suivante, si je voulais jouer l'ultra 'chaud', j'insérais carrement des routines de calcul durant ce temps mort, j'ai l'impression d'inséré du code dans une routine d'overscan (Souvenir de démomaker !). Dessin : Mise en place des ------ Temps mort -------------- Boucle, et on recommence. valeurs blitter Les polygones je vous passerais les coordonnées et sinon un exemple pour ceux qui peuvent lancer le code. AVP est assez loin de la Vbl, I.S. est plus proche mais il tourne pas en une Vbl. GT Turbo

Tout est rentré dans l'ordre, je tournes 4 fois plus vite. J'ai réussi a tout débugger, en reprenant le premier polygone (Mon passage de tableau fonctionne !), je suis a 29 Polygones / Vbl. Mes 'ratures' venait du 68000, ma boucle qui attendait que le Gpu ait fini son boulot ne fonctionnait pas, j'ai fait attendre le 68000 comme un ane, et maintenant cela marche. La routine Gpu n'est pas optimisé, par contre il y a déjà le clipping dedans !! Héhé !! Seul la partie remplissage est au Gpu, le reste c'est du 68000, donc faut que je réecrives tout le reste au Gpu, donc préparez vous encore a manger du chiffre qui fait mal !! Par contre si quelqu'un a une idée pour synchroniser le Gpu, dans ma boucle 68000 j'attendais que le registre de control (Start / Stop) du Gpu soit égal a zéro, la routine Gpu effface ce registre toute seule comme une grande, mais cela parfois fonctionne parfois pas du tout, donc ? J'ai essayé en utilisant un autre flag, mais cela fait pareil !! Pour ceux qui veulent faire du code Gpu n'oubliez pas une chose insérez TOUJOURS un Nop après un saut, car il faut le savoir, que le saut soit pris ou pas l'instruction suivante est executé !! Heuresement que c'est inscrit dans les docs, sinon je débugguerais encore maintenant !! GT Turbo qui son Gpu

Azrael : Je pense que tout sera fait en True Color. Exact, true color 16 bits. Le remplissage sans gouraud peut etre ultra rapide, si on fait comme cela, car l'autre technique en calculant la pente, j'ai peur qu'elle soit plus lente. Le calcul de la pente et remplir le paquet de registre pour ceci est très long, la je suis a 4 instruction Gpu pour tracer une ligne et quelque soit sa longueur. Et on peut pas raccourcir sinon le blitter va me taper une crise. Et pour info, la routine de calcul des points est du Bresenham, la routine la plus exacte (Pas de partie décimal dans les calculs) mais la plus lente, on optera pour la version floue si il venait a nous manquer quelque cycles (Non Azrael ne me tapes pas !) GT Turbo

SCPCD : Multiplié par au moins 3 !! rien qu'en reecrivant au GPU !! et sans optimisation, je suis sur !! GPU PPPPPPOOOOOOOOOWWWWWEEEERRRRRRR Beaucoup plus mes premiers polygones étaient plus petits !! Et comme tu dis sans optimisations, toute la routine de calcul de points est a réecrire au gpu !!! GPU PPPPPPOOOOOOOOOWWWWWEEEERRRRRRR <

Vous etes tous assis ? Hier soir après avoir réecrit une partie au Gpu, et suite a des problèmes de transmission de tableau (Coordonnées x gauche et droite) j'ai fourni les coordonnées a la main, ce qui fait que je me retrouves avec des polygones rectangulaires de 278*170. Suite a l'augmentation de la taille je me suis dit que j'allais plombé mes statistiques et bien c'est sans oublié cette machine de guerre baptisé Gpu. De 7 je suis passé a ......................... roulement de tambour : 26, j'ai essayé plus et suivant le code gpu employé je dépasses les 30 !! Ca fait mal !! Très mal !! Par contre encore a prendre avec des pincettes ce résultat, certains de mes polygones on des bavures a gauche et droite, je penses a un petit problème de synchro, le Gpu est ultra rapide, j'ai du rajouter une boucle pour attendre que le blitter est fini pour tracer la prochaine ligne, chose que je n'avais pas a faire avec le 68000. Par contre vu que j'attends un moment je vais utiliser une partie de ce temps d'attente pour clipper les coordonnées en X, comme ca pas de perte de temps !!! Dans tous les cas de figure : GPU POWER !! GT Turbooooooooooooooo

7 Polys / Vbl, normal filling (Without gouraud or mapping) I've got an example, i wanted to give you but the PC doesn't like my Falcon's Disk !! The poly is near the half of a screen. Tonight i will rewrite some parts with Gpu, so i hope the next try i can give an example. GT Turbo

atariowl : Pardonnez mon francais mauvais No problem atariowl : est environ 20-40 % sur la vitesse, selon les circonstances 2 - prévenir la page les coups manqués vous pouvez blit un carré, un rectangle ou paralllelogram dans on va, mais être conscient que gouraud les valeurs ira faire noty être la reconstruction pour chaque scanline, mais se poursuivrait de la valeur à la fin de la ligne précédente AtariOwl Merci pour les infos. Voila je viens de finir des essais, j'ai fait des essais au 68000 seul, j'ai réussi a afficher 1 polygone (Exemples a venir si ce PC de m.... veut bien lire ma disquette Falcon !) en 1 Vbl, j'avais peur et voila que Super Blitter arriva, après deux, trois bricoles, je suis passé a 2, puis 3, et....... j'ai fini a 7 polygones, ceci juste en utilisant le blitter. J'ai 14000 cycles qui servent a rien (bouclage pour les tracés de ligne) le 68000 qui me plombe le bus, donc on se revoit quand j'aurais tout réecrit au Gpu. GT Pas a fond, loin de la !!

A première vue ce n'est pas possible de remplir un polygone en un coup, on peut lire ceci première page du blitter : For example, the GPU might calculates co-ordinates and gradients associated with a polygon, while the Blitter draws strips of pixels. Et encore ceci : [code]Each blit creates one scan line of a polygon, with the graphics processor responsible for re-calculating the start, length and gradient parameters for each scan line. Donc a la main, a la rigueur cela me dérange pas, c'était juste pour ètre sur de pas écrire une routine de remplissage alors que c'était dispo en hard, ca aurait été con !! J'ai commencé a regarder les détails concernant le 'Z-buffering', bien sur l'absence de doc clair est une habitude, les Z de chaque point sont entrelacés avec les pixels sous la forme : pixel : 1 2 3 4 ensuite Z du pixel 1 2 3 4, ceci pour des raisons d'accès mémoire, cela n'est pas un problème, par contre les Z sont codés sur combien ? La les données sont organisés en phrases (8 octets) donc si on divise par 4 cela nous donne 2 octets donc des Z allant de 0 à 65535, mais cela pourrait ètre codé aussi sur 1 octet, quelqu'un a une info dessus ? Faut de toute façon que je fasses des essais, mais toute info est bonne a prendre. GT Plein de pixels !!

Faut que je lises et relise la doc du blitter pour voir si je peux trouver mon bonheur, sinon on calcule les x au Gpu et le Gpu remplit au blitter cela permet d'utiliser la fonction Z-Buffer. Parce que j'avais pensé a un autre truc, on trace virtuellement le polygone, au lieu de réeffacer completement l'écran, on crée un sprite de la taille de l'objet, on dessine l'objet dedans et on place ce sprite a l'écran a la place du polygone. Cela permet si un objet ne bouge pas de ne pas le redessiner ou de faire des redraws qui servent a rien. Mais un soucis apparait pas de Z-Buffer !! Donc si on trouve rien pour remplir completement au blitter, je passe au Gpu / Blitter pour le remplissage de polygones. GT En train de remplir au pinceau !!

SCPCD : OK Merci. Pas de soucis, pour une fois ou je peux t'aider !! Cela colle avec les infos d'Atari (Pour une fois !), pour le 'data' et le 'height', je confirmes l'obligation de les sauver, pour le remainder j'ai un petit soucis car dans tous les cas de figures mes sprite zoomées délirent, le petit bug qui met les nerfs !! GT Plombé de Bug !!