GT Turbo

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

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

SCPCD : Salut ! Je voulais savoir : qu'elles sont les données modifiées par le OP exactement ? 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

Fredifredo : Alors donc on pourrait théoriquement affiché 1400 sprites en simultané c'est ça ? 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

Avant de me couché, j'avais un doute et j'ai vérifié Madmac a une sale tendance a faire gonflé les codes assemblés avec, j'ai fait un essais, un nop assemblé fait 44 octets !!! Théoriquement il ne devrait prendre que 2 octets ! Apparement des infos de débugguage et d'autres conneries sont sauvés avec (Je crois bien que l'entete du fichier assemblé est au format Gemdos (Taille Data ,Bss, et d'autres trucs)) J'ai essayé les différents formats de fichier de Madmac en sortie, certains codes assemblés sont plus gros que les sources !!! ARGHHH Je vais essayé de comprendre ce qu'il y a en trop et coupé a la serpette dans le code, si encore on avait 20 kilos de ram Gpu d'accord mais on en a que 4, donc si on s'amuse a faire gonflé nos codes avec des trucs souvent superflus, la bataille n'est pas prete d'ètre gagné !!!! J'étudies cela en détails et vait cherché une solution a cet épineux problème... GT En train de cherché

SCPCD : ensuite tu envoi le fichier .bin dans la jag a l'adresse 4000 et tu peux l'executer 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 l'ai eu ce matin j'y croyais plus !! Le pauvre gars de la poste il a rien compris, je suis arrivé en courant et lui ais pris le colis des mains et suis reparti en courant !! Il me manque encore 2 interrupteurs et après je lance la machine, la nuit va etre blanche, je vais enfin pouvoir reprendre certains projets !! Le coding en mode turbo ENFIN !! Ce poste peut presque ètre considéré comme de la polution, mais je suis trop heureux. (Après quelques jours on demandera a RaZ de l'effacer !!) GT Un gamin qui vient de récuperer un jouet !!

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

frost : Waow !! J'suis scié ! GT, je t'aimeuuuu 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

frost : Et Devpac ne va pas bien pour coder sur Jag ?? Je me souviens que ça marchait plutôt bien. 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é !!

SCPCD : 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. 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

SCPCD : 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 ??? 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)

Fredifredo : J'ai découvert parmis tous mes dossiers un nouveau convertisseur qui existe à la fois pour Atari et PC , ça semble être une version amélioré de 3DS2JAG par contre j'ai zappé le nom ( c'est sur l'autre PC ) 3DSCONV ou un truc comme ça ... il date d'avril 1995 , je n'ai pas vu le code spurce avec par contre ... la dernière demo 3D en date qui va avec est à 80% en language C... 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

SCPCD : 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.... C'est exactement cela !! SCPCD : 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 ) 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 !) SCPCD : - 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 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

J'ai commencé a réécrire le code au Gpu, mais le premier essais c'est 140 sprites 32*27 en true color 16 bit (1 Vbl) tout le code au 68000 plus un plus grand (320*50, affichage de valeur binaire et décimale). GT Turbo

Si vous tapez compact flash atari jaguar sur Google, vous risquez de tomber ici : Hop un lien Ne comprenant pas un mot de teuton, j'ai demandé a Arethius de me traduire la fin et voila le résultat : "Depuis peu il existe un nouveau type de support pour le développement de nouveau sur Jaguar : une cartouche compact flash (ou adaptateur compact flash). Cette cartouche rend possible le développement et la distribution à grande échelle de jeux. Cette cartouche offre de nombreux avantages comme des temps de chargement très courts ainsi qu'une capacité de stockage accrue." GT Turbo

Ca y est est !! Cela fonctionne a merveille, j'ai un paquet de sprites bien joyeux sur mon écran, cela marche, encore une modification et je commences a tout réecrire au Gpu. GT Turbo

J'ai règlé mon problème, par contre ce rigolo d'O.P. (Object Pocessor) ne m'affiche pas mon second sprite, faut que je vérifies l'adresse du graffe. Sinon cela a l'air de coller. Merci beaucoup au debugger !!! GT Plus bugger !!

RaZ : Question à cent balles. Si vous regardez bien dans le texte, il y est fait mention d'Eerievale, et en bas de la page, deux des trois liens vont vers le site de Starcat et d'Eerievale, donc la question est, quelle est la probabilité pour que Starcat lui même est pondu cette page ? Je viens d'y voir Clicks, qui sauf erreur de ma part n'est pas sorti non plus.. J'y ai pensé mais j'ai pas osé le dire, j'ai vu les liens et cela a fait tilt. Il est gentil mais son problème est toujours la, il devrait au minimun citer SCPCD qui sans lui rien n'aurait exister. Question j'ai fait un tour sur la partie francaise de 'viki' on peut pas rajouter du texte ? Je voulais voir pour faire pareil sur la version Froggies GT D'accord avec RaZ

Arethius serait ok, la question que changer ? J'y connais rien a ce genre de truc (Comme a beaucoup d'autres diraient certains !) GT

RaZ : Si c'est sur Wikipedia, on peut le modifier nous même. Juste la barrière de la langue à franchir... Je penses que si il n'y a que la barrière de la langue Arethius peut nous passer un coup de main. Je le contactes. GT Turbo