GT Turbo
21 Sep 2005, 09:17
J'ouvre un sujet sur le blitter, c'est un des points très fort de la Jag, aussi bien coté puissance que l'étendu de ces capacités peut rendre beaucoup de service.
Avant certaines questions et réponses techniques, quelqu'un aurait une idée de ce que veut dire ceci (Trouvé dans la doc officielle Atari) :
Single scan of polygon fills
Parce que sauf erreur de ma part on parle bien de remplissage de polygones, mais le single scan me perturbe, ca veut dire quoi ?
GT En train de cherché a comprendre :wacko:
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...:D
GT Turbo
22 Sep 2005, 07:41
SCPCD :
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...:D
La technique dite habituelle, consiste a tracer virtuellement les lignes du polygone et a stocker les points, on les stocke de manière a avoir juste pour chaque ligne les deux x (X gauche et droite of course !) et ensuite on remplit ligne par ligne vu qu'on a les deux cotés du polygone pour chaque ligne, cette technique était surtout pratique sur un Atari a cause des bitmaps, le remplissage en ligne était plus simple et la je m'apercois qu'a cause du true color, en colonne ou en ligne cela revient exactement pareil !! :wacko:
Je suis en train de chercher dans la doc du blitter, mais pas trouver grand chose, je vais regarder dans d'autre code pour voir.
GT En train de remplir !! :yes:
GT Turbo
22 Sep 2005, 10:57
Si on veut remplir une forme la question est y a t'il un mode du blitter qui permet de s'adapter suivant la donnée destination.
Explication :
Imaginons un carré sur l'écran, on peut balayer le carré pour le remplir avec le blitter, celui peut remplir un rectangle tout seul en balayant de gauche a droite, ligne par ligne, ce qui veut dire que de ce coté pas de soucis, la question est donc est ce que si la destination contient un point on peut forcer le blitter a remplir jusqu'a un autre point, là ou ils devraient s'arreter et on recommence l'opération jusqu'a remplissage du carré.
Si on peut faire cela, un petit soucis se posent, faut qu'a chaque polygone, on le dessine dans un écran vierge et après qu'on le recopie sur l'écran finale, car sinon on risque d'avoir de sérieux soucis d'intersection après des polygones déjà remplis.
Puis qu'on efface notre écran de dessin et rebelote, cela risque d'ètre un peu lent.
GT Pas rempli ;)
GT Turbo
22 Sep 2005, 16:40
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 !! :wacko:
GT Turbo
27 Sep 2005, 08:13
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 :
[code]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 !!
GT Turbo
27 Sep 2005, 12:45
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 !! ;)
GT Turbo
27 Sep 2005, 14:30
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 ;)
GT Turbo
28 Sep 2005, 09:17
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 ;)
:o
Multiplié par au moins 3 !! rien qu'en reecrivant au GPU !!
et sans optimisation, je suis sur !!
GPU PPPPPPOOOOOOOOOWWWWWEEEERRRRRRR
Azrael
28 Sep 2005, 10:29
Faudrait aussi voir à pas trop charger le GPU non plus, c'est ça qui m'inquiète. Quelqu'un sait comment sont remplis les polygones dans Cybermorph ?
GT Turbo
28 Sep 2005, 10:48
SCPCD :
:o
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
[code]Faudrait aussi voir à pas trop charger le GPU non plus, c'est ça qui m'inquiète. Quelqu'un sait comment sont remplis les polygones dans Cybermorph ?
Avant il s'embètait et maintenant il a une raison d'ètre !! Je l'ais pas trop chargé encore, c'est le blitter qui a du mal a suivre. Il y a encore le Dsp qui s'ennuie un peu (Il lit déjà les joypads ! :yes: )
Apparement pour cybermorph, ils ont donc utilisé le gouraud hard du blitter, le blitter peut tracer des droites pas droites (:wacko: ) il dispose d'un partie décimale pour les pentes. Je supposes qu'ils ont rempli les polygones en tracant les droites comme cela (Pas a plat), car le blitter de chargeant de modifier les Z et l'intensité de chaque point, il y a des registres pour indiqué la valeur a rajouté a chaque pas.
Mais un truc m'a calmé je crois que le z-buffering en hard est a laissé tombé, car quand on a tracé un polygone faut encore remplir tous les Z des points de ce polygone, donc vitesse presque déjà divisé par deux. Trié l'affichage des polygones d'après les Z est beaucoup plus rapide, donc si il n'y a pas de gouraud,autant le faire a la main.
Faut que je retournes retirer mes imperfections et optimisé le code!! Ahahahah!! :yes:
GT Pas a fond et c'est bon !! ;)
Azrael
28 Sep 2005, 11:12
Et remplir au Blitter sans mettre de Goureaud c'est rapide ou pas ?
Azrael
28 Sep 2005, 12:09
Je pense que tout sera fait en True Color.
GT Turbo
28 Sep 2005, 12:26
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 ;)
Hey, owl, if you're in trouble with your french, we won't mind you writing in english. Especially when it gets technical.
We'll translate it and add the french version to your messages, if it's worth it ;)
And thanks for your help.
Don't be, you did your best and we appreciate it.
GT Turbo
29 Sep 2005, 09:52
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 :wub: son Gpu
Azrael
29 Sep 2005, 09:57
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 ?
GT Turbo
29 Sep 2005, 10:09
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 :wacko:
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.
GT Turbo
29 Sep 2005, 10:29
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 !! :wacko: 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é !! :no:
Azrael
29 Sep 2005, 10:36
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 ?
GT Turbo
29 Sep 2005, 10:39
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 !! ;)
A non je me suis trompé :D
J'ai verifié dans un de mes codes et j'ai bien fait comme toi...
GT Turbo
29 Sep 2005, 10:47
SCPCD :
A non je me suis trompé :D
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 :wacko:
GT Asynchrone :wacko:
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.
[code]
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 ;))
GT Turbo
29 Sep 2005, 13:25
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 :wacko:
SCPCD :
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
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 !! :no:
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 :wacko:
Citation
Un truc pas très loin :
[code]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.
GT Turbo
29 Sep 2005, 13:36
SCPCD :
Citation
Un truc pas très loin :
[code]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 ! :yes:
GT Débuggué !! ;)
GT Turbo
30 Sep 2005, 09:06
Comme cela ca marche mieux :
[code]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 !! :wacko:
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 !! :wacko:
GT Turbo
30 Sep 2005, 10:41
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 :yes:
GT Reparti pour le sprites ! B)
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 !!!:cry: et pas un autre DSP !!!)
GT Turbo
1 Oct 2005, 18:49
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 :
[code]stop #$xxxx
Cela permettrait pas d'attendre sans squatter le bus ? On ne fait aucune lecture ou écriture, le 68000 attend une inter sans rien plus ?
J'ai pas encore regardé mais on peut pas faire un synchro Vbl en 'stoppant' ?
GT En train d'attendre !! :wacko:
GT Turbo
3 Oct 2005, 08:58
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 !! :wacko:
GT En train de finaliser la routine Gpu :yes:
GT Turbo
4 Oct 2005, 12:39
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 !! B)
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 !! :yes:
GT Turbo
6 Oct 2005, 15:42
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 !! ;)
En tout cas tu fais un sacret boulot !!
:)
J'ai hate d'avoir la demo sur une CF ;)
GT Turbo
6 Oct 2005, 16:07
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 ! :wacko: ) 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 !! :no:
GT En train remplir et j'ai bientot fini !! ;)
GT Turbo
7 Oct 2005, 18:24
[code]
lea G_CTRL,a0
move.l #1,(a0)
Wait :
btst #0,3(a0)
bne.s Wait
Ce style de boucle pour atteindre la fin d'un proc, ne marche pas du tout si le proc en question fait le travail trop vite !!
Retour a nos polygones :
La routine est entierement Gpu-isé, mais j'ai un débugguage de fou a faire, mon code a l'air instable comme un pingouin sur une savonnette !! Mon code fonctionne pas tout a faire normalement : l'affichage d'un polygone fait apparaitre un paquet de triangles et de formes plus ou moins bizzare et l'insertion d'un nop a différents endroits du code soit ne fait rien apparaitre, soit plante direct !! Sur ce coup je sens que je vais transpirer !!!!
GT Paniqué !! :wacko:
HHAAA...
Les joies du debuggage du GPU !!!
Que du bonheur !!
:D
GT Turbo
8 Oct 2005, 16:32
SCPCD :
HHAAA...
Les joies du debuggage du GPU !!!
Que du bonheur !!
:D
Boite de gatos :yes: !! Et Coca !! Et une nuit blanche dans la g.... !!
Ce code va tourner très vite, j'ai des sprites a afficher !!
Et c'est dans ce genre de moment, je m'apercois qu'il faudrait que je continues un peu le nouveau debugger !! Avec la possibilité de tracer du Gpu !! :yes:
GT En train de debugger !! :wacko:
GT Turbo
12 Oct 2005, 12:25
Areuhgfsdsfhdgiosf meme après deux boites de gato (Je vais vomir ! :wacko:), ce code ne fonctionne pas, j'ai réussi malgré tout a debugger deux Kdo, il me reste apparement un soucis conernant la routine qui appel la routine de tracé de ligne virtuel. Je me suis remotivé et c'est reparti !! :yes:
GT En train de debugger !! :yes:
GT Turbo
13 Oct 2005, 12:30
J'ai laissé tomber les gatos !! j'attaques au petit suisse !! Etant donné que c'est apparement 'misereland' a debugger, j'ai transformé ma routine de tracé de ligne virtuel en routine de tracé de ligne réel, c'est plus simple a debugger !! :yes:
GT En train de voir mes erreurs !!;)
Fredifredo
13 Oct 2005, 13:05
N'oublie pas d'avoir un oeil sur la doc officielle ou ya tous les bugs de répertorier ;)
Dans la version 8 ( 2000 ) et celle de mars 1995 , j'espère qu'ils parlent des mêmes bugs !
GT Turbo
13 Oct 2005, 17:37
L'affaire est dans le sac, je remplis mes polygones gones gones au Gpu u u u u u u !!!
Je ferais des essais pour voir le gain cette nuit, j'ai un petit soucis de ram gpu, plutot d'organisation, car suite a mes tableaux placés avec un lance pierre je n'arrives plus a mettre ma routine de resturation de liste au Gpu, donc les chiffres serait pas comparables, enfin cela marche et je suis heureux !!!
GT En train de ranger ma Gpu - Ram !! ;)
GT Turbo
14 Oct 2005, 08:59
Tous les chiffres tombent a l'eau !! :cry:
J'ai lancé mon code et le chiffre est tombé 26 polygones !! Quoi ??? J'ai vérifié plusieurs fois et ben non, c'est le bon chiffre.
J'ai repris mon code 68000 et vérifié, dans le code 68000, les points du polygone étaient calculés qu'une fois et pas a chaque polygone, ce que la routine 100% Gpu fait. Le 68000 dans ce cas de figure tourne a un polygone !! :blink:
Donc d'un coté j'ai les boules a moitié (Car la routine Gpu n'est pas encore optimisé ! Ouf !) de l'autre le Gpu est 26 fois plus rapide que le 68000 !! Meme si on divise par deux du fait que le 68000 tourne a la moitié du Gpu, cela fait toujours un rapport de 12 !!
Pour voir reellement ce que cela vaut, faudrait que j'adaptes une routine 3d et faire touner quelques objets car c'est sur que c'est pas visuellement parlant, meme moi je commences a en avoir marre de regarder ces polygones sans vie.
GT Un peu dégouté mais je reparts de plus belle !! :yes:
Azrael
14 Oct 2005, 09:27
26 seulement !?! Glp... pas glop... quelle taille tes polygones ?
GT Turbo
14 Oct 2005, 09:32
Azrael :
26 seulement !?! Glp... pas glop... quelle taille tes polygones ?
Pas Glop comme tu dis, on verra après optimisation. Sinon je suis en train de me demander si j'arriverais pas a utiliser le temps libre d'attente du blitter pour faire certains des calculs. Faut que je regardes tout cela.
GT En train de réfléchir :blink:
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please
click here.