Jump to content
Jagware
Sign in to follow this  
GT Turbo

Débat sur les listes de sprites.

Recommended Posts

GT Turbo    5

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 ;)

Share this post


Link to post
Share on other sites
Azrael    0
Fredifredo :


Des que tu as un petit exe qui traine , je suis preneur ... ;)





Les exe c'est sur PC :no:, ici on parle de prg :yes:... tu as vraiment envie de te faire des amis...

Share this post


Link to post
Share on other sites
GT Turbo    5

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

 

 

 

C'est trop simple !!

 

 

 

GT Turbo :yes:

Share this post


Link to post
Share on other sites
GT Turbo    5

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::yes::yes:

Share this post


Link to post
Share on other sites
SCPCD    0

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

 

 

 

je pense que ce probleme peut être causé par différents cas :

 

- il y a trop de sprites et le processeur d'objet n'arrive pas a lire suffisament vite dans la RAM pour les gérer. (ca depend aussi de la largeur des sprites)

 

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

 

 

 

- 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

 

 

 

 

 

Le fais d'utiliser le même sprite, je ne pense pas que ca change quelque chose, vu que l'OP accedera exactement de la même facon a la mémoire independament du sprite suivant. (sinon, il faudrais qu'il precharge les valeurs du sprite suivant et qu'il fasse un pre traitement ce qui n'est pas indiqué dans la doc)

Share this post


Link to post
Share on other sites
GT Turbo    5
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 !! :yes:



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 ? !!:wacko: 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 :yes:

Share this post


Link to post
Share on other sites
SCPCD    0

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

Share this post


Link to post
Share on other sites
GT Turbo    5
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



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

Share this post


Link to post
Share on other sites
SCPCD    0

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.

Share this post


Link to post
Share on other sites
GT Turbo    5
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é !! :wacko:



GT Turbo ;)

Share this post


Link to post
Share on other sites
GT Turbo    5

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

 

 

 

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

Share this post


Link to post
Share on other sites
SCPCD    0

Oui, et il serais même possible en theorie d'atteindre 200sprites/lignes*256lignes=51200 sprites par vbl.

 

mais là je pense qu'il n'y aurais pas assez de place mémoire dans la RAM pour stocker la liste ^_^

Share this post


Link to post
Share on other sites
GT Turbo    5
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 !! :wacko:



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 ;)

Share this post


Link to post
Share on other sites
SCPCD    0

Salut !

 

 

 

Je voulais savoir :

 

qu'elles sont les données modifiées par le OP exactement ?

Share this post


Link to post
Share on other sites
GT Turbo    5
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 ;)

Share this post


Link to post
Share on other sites
GT Turbo    5
SCPCD :


OK

Merci. ;)





Pas de soucis, pour une fois ou je peux t'aider !! :blush:



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

Share this post


Link to post
Share on other sites
GT Turbo    5

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é !! ;)

Share this post


Link to post
Share on other sites
GT Turbo    5

J'ai repris mon travail sur mon gestionnaire de liste (de sprites) et certaines questions apparaissent, surtout une. Pour celui ci j'ai donc trois niveaux (le fond meme (Back), les sprites au second niveaux, et les compteurs), quand vous appellez la routine de sprite il faut maintenant lui passer le niveau dans lequel votre sprite doit apparaitre, c'est normal. La ou c'est moins marrant, c'est quand faut le liquider, vous preferez indiquer vous meme dans quel niveau il se trouvait ou on le fait en automatique, cela est plus de question de vitesse qu'autre chose. Car indiquer le niveau cela réprésente une instruction (68000, Gpu ou Dsp), alors qu'en automatique c'est un peu plus long. C'est juste pour avoir un truc qui décoiffe.

 

 

 

Enfin si on analyse, on a plus de chance de 'killer' un sprite qu'un fond ou qu'un compteur. donc je vais le mettre en mode manuel (pour l'automatique je ferais une seconde version), ce qu'on veut c'est que ca tourne en une Vbl après le reste !!!

 

 

 

 

 

GT Rapide (Enfin j'espère !) ;)

Share this post


Link to post
Share on other sites
SebRmv    2
Je vois un trap #13, tu l'as détourné je penses, parce que sauf erreur de ma part, aucun trap n'est dispo a l'origine si ?

 

c'est où l'adresse des vecteurs TRAP ?

Share this post


Link to post
Share on other sites
SCPCD    0
c'est où l'adresse des vecteurs TRAP ?

Les vecteurs des traps commencent a l'adresse : $000080

 

 

[english]

Traps vectors start at the address $80

Share this post


Link to post
Share on other sites
Guest
You are commenting as a guest. If you have an account, please sign in.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoticons maximum are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×