GT Turbo

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

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

No problem







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 !!

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 !!

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

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 !!



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 !!

Pour les bitmaps simples, il y a 'data' et 'height', vu qu'ils sont en plein milieu d'un long a chaque fois, j'ai sauver a chaque fois le long (Plus rapide que de découpé !) et en plus vu qu'ils sont consécutifs on fait tout d'un coup (Phrase) et pour les 'scaled bitmaps' il y a le remainder en plus (La encore j'ai sauver un long).



GT Turbo

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

Enfin si il y en a qui se lance la dedans, bon courage, car les 'branchs' a gèrer dans des listes c'est que du bonheur !! Je possèdes deux 'branchs' dans ma liste, les deux recommandés pas Atari au début, cela m'a permis de comprendre un petit bug qui faisait que mes premiers sprites se faisaient manger des lignes au début, depuis que je les ais 'branchés' plus de soucis, par contre reéssais sous un émulateur, j'ai plus rien du tout sur l'écran !! C'est encore pire qu'avant ! Plus on respecte les règles moins ca marche !!



A la rigueur une fois qu'on aura tout mis en place et tout fonctionnera on pourra se faire un sprite record sur la Jag, histoire de s'occuper les weeks ends !!!!



GT Turbo

A chacun sa technique, cela permettra aux futurs devellopeurs (Qui vont devenir nombreux !....) de choisir la leur !!



GT Turbo

C'est bon a savoir, merci pour tout, j'en prends note.

 

 

 

Par contre question SCPCD, tu trouves pas cela un peu lourd ? Devoir a chaque modif lancé tout cela pour vérifier ton code ? J'utiliserais peut ètre les trucs officiels pour les versions finales, si on excepte juste le petit soucis concernant les entetes sur les fichiers Gpu ou Dsp, perso je changes plus rien, excepté peut ètre l'utilisation de MadMac pour le code 68000, pour éviter de devoir aligné certaines adresse a la main

 

 

 

GT Documenté

Je voulais pas ouvrir un poste juste pour une bricole sans intèret donc, je suis heureux, j'ai collé depuis trois jours un second dur dans mon Falcon, pour faire des copies de sauvegarde des sources, cela faisait un moment que j'avais peur d'un crash, le seul truc c'est que mon Falcon ressemble plus a un grille pain qu'autre chose, mon lecteur de disquette est chevauché par les deux durs (Faut que je fasses une photo ce soir, faut que vous vouyez a quoi ressemble nom grille pain (Seb c'est bien !)

 

 

 

GT Brulé !!

Je viens de me relire et comme d'habitude mes explications sont 'très claires !'

 

 

 

Pour les non codeurs, l'O.P. (Le processeur objet, responsable de l'affichage des sprites a l'écran), utilise une liste chainé qui décrit chaque objet (X,Y, taille, etc...) pour chaque sprite, le problème c'est qu'une fois qu'on a transformé notre description de sprite au format compréhensible pour l'O.P. et qu'on lui donne notre super liste, ce rigolo 'bousille' certaines parties, donc pour tourner correctement soit il fallait a chaque Vbl, reconstruire entierement la liste, procédé plus simple mais lent, ou sauver les parties qui sont détruites et a chaque Vbl les réecrire, c'est un peu plus complexe (Enfin perso j'ai pas trouvé !) mais surtout cela va beaucoup plus vite.

 

 

 

En espérant que cela soit plus claire pour tout le monde.

 

 

 

GT Pas très claire !!

C'est pas moi qu'il faut embrasser, mais Fredifredo et notre hardmaster : SCPCD, c'est eux les responsables !! Sisi !!

Perso je n'ai pas grand chose a voir avec cette révolution !!





GT

Devpac cela marche du feu de dieu, et dans le pire des cas, je peux juste utiliser l'éditeur de Devpac et utiliser Mad Mac en tant que Tools, c'est aussi pour cela que je préfères Devpac.



Voila a quoi ressemble mon menu de Devpac :







Le truc ultra top, c'est que je peux écrire le code Gpu par exemple dans la seconde fénètre, je lances Mad Mac depuis le menu tools, je repasses fenetre un et je réassemble mon code qui 'include le fichier résultant' de Mad Mac pour mes codes Gpu / Dsp. Plus de détails ici en rubrique Articles.



Ce que je voulais dire c'est que Mad Mac génère des fichiers au format Gemdos avec un entete dont on se bat les c....., cela fait surtout perdre des octets très cheres quand on a que 4 Kilos (Gpu) ou 12 Kilos (Dsp), pour l'instant j'ai trouvé un truc con, ma routine qui recopie les codes procs, recopie le code a partir du début du fichier plus $1a (Entete de 28)+2 (Taille du bra du début du fichier) et recopie le nombre d'octets inscrit dans l'entete, cela m'évite pour l'instant de devoir couper les fichiers a la main. Je penses que pour ceux qui utilisent le linker (Sur Atari il y a un shell apparement bidon (Gulam) qui a l'air de me hair, donc pour l'instant je connais pas las version Atari du linker et je m'en f... Mon environnement de devellopement est telle qu'a part l'Evo II de SCPCD je ne changerais pour rien au monde !!



GT Bien installé !!

J'y penses, mais c'est vrai que cela complique un peu la chose, on se garde cela en cas extreme !! Je suis pas encore assez chaud pour tater du 'branch !'



On se fera cela une fois pour une démonstration de force, le problème c'est que dejà avec 200 sprites a l'écran tu vois plus rien, avec 3200 cela va ressembler a un tableau de Van Gogh durant sa période déstructuré !!



GT Turbo

Dans la structure de chaque sprite, j'ai garder deux trois longs de libre, quand je crées le sprite, je recopies les longs qui vont ètre modifiés dedans. La routine Gpu a chaque Vbl recopie juste ces longs dans les champs modifiés, ce qui fait si on ne rajoute pas de sprite, il n'y as que de la recopie de long et au Gpu ca pousse, le code principal Gpu doit faire 8 lignes.



C'est pour cela que si je veux modifier les coordonnées d'un sprite je dois appeler une routine spécial qui réinscrit les bonnes valeurs dans la liste et dans les longs de sauvegarde. Dans le cas d'un sprite bitmap non zoomée, c'est deux longs consécutifs donc 'Loadp' et 'Storep' !! Phrase power !!



L'autre avantage, c'est que par exemple si tu dois afficher 40 fois le meme sprite, tu n'est pas obligé d'écrire quarante fois la meme structure pour décrire un sprite, vu que les coordonnée sont dans la liste et pas dans ta structure de définition d'un sprite.



GT Turbo



P.S. : Pour info 'phrase' est du jargon Jaguar désignant 8 octets consécutifs (2 mots longs)

Je crois avoir vu un truc comme cela, mais tant qu'on aura pas de moteur 3d, on pourra rien voir.



De la 3d 100% Dsp et remplissage 100% Gpu, c'est le genre de duo qui fait des étincelles !!



GT Turbo

C'est exactement cela !!







C'est surtout a stopper le 68000 auquel je penses et mettre le maximun dans les procs, mais je ferais rien avant que la routine soit 100% fonctionnel. C'est la limite par ligne, mais pas de la Jag, car j'étais encore dans la Vbl, sinon on se limite a 150 sprites et on colle trois plans de scroll derrière (Vous croyez qu'on arrivera a faire quelque chose de correcte avec cela ? !! lol !)









Vu que je génères pas la liste a chaque Vbl, la génération n'est faite qu'a chaque fois qu'on rajoute un sprite.



GT Assez heureux de ce code

C'est inscrit un peu plus haut : 32*27 en true color (16 bits)

 

 

 

Par contre histoire de voir un peu, j'ai vraiment poussé la routine, les 280 sprites sont affichables en une Vbl !! Non il n'y a pas d'erreur, le chiffre que j'ai donné avant est un chiffre net, ce chiffre la est brut, la différence : un parasitage des sprites apès 200. Pourquoi ? Quand un trop grand nombre de sprites est affiché sur la meme ligne, le processeur objet perd les pédales et commence a s'emballer, celui ci traite ligne par ligne et apparement trop d'objet sur la meme ligne fait des trucs bizzares, je penses que c'est cela, SCPCD pourra peut ètre confirmé, car suivant les positions des sprites, je peux grimper ou chuter avant d'avoir des trucs bizzares dans les sprites, mais il y a encore peut etre une autre hypothèse, j'utilises le meme sprites et ce sont les memes données qui sont utilisés pour chaque sprite, donc est ce que il y a des soucis suite a cela ? Faut que j'essais avec plusieurs sprites différents.

 

 

 

GT Pas encore a fond !! GPU POWA !! :yes:

Le Gpu est mon ami !! La barre des 200 sprites est atteinte sans broncher, meme un peu plus !!

 

 

 

C'est trop simple !!

 

 

 

GT Turbo