Fredifredo Posted September 17, 2005 Report Share Posted September 17, 2005 Dès que tu as un petit exe qui traine , je suis preneur ... Link to comment Share on other sites More sharing options...
GT Turbo Posted September 17, 2005 Author Report Share Posted September 17, 2005 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 Link to comment Share on other sites More sharing options...
Azrael Posted September 17, 2005 Report Share Posted September 17, 2005 Fredifredo : Des que tu as un petit exe qui traine , je suis preneur ... Les exe c'est sur PC , ici on parle de prg ... tu as vraiment envie de te faire des amis... Link to comment Share on other sites More sharing options...
GT Turbo Posted September 18, 2005 Author Report Share Posted September 18, 2005 Le Gpu est mon ami !! La barre des 200 sprites est atteinte sans broncher, meme un peu plus !! C'est trop simple !! GT Turbo Link to comment Share on other sites More sharing options...
RaZ Posted September 18, 2005 Report Share Posted September 18, 2005 Précise quelle type de sprites et dans quelles conditions histoires que l'on se fasse une idée de la poussée du bousin. Link to comment Share on other sites More sharing options...
GT Turbo Posted September 18, 2005 Author Report Share Posted September 18, 2005 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: Link to comment Share on other sites More sharing options...
RaZ Posted September 18, 2005 Report Share Posted September 18, 2005 Au temps pour moi. Link to comment Share on other sites More sharing options...
SCPCD Posted September 19, 2005 Report Share Posted September 19, 2005 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) Link to comment Share on other sites More sharing options...
GT Turbo Posted September 19, 2005 Author Report Share Posted September 19, 2005 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*30ce qui correspond a charger 640*8*2= 10240octets par lignespour 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 Link to comment Share on other sites More sharing options...
SCPCD Posted September 19, 2005 Report Share Posted September 19, 2005 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 ??? Link to comment Share on other sites More sharing options...
GT Turbo Posted September 19, 2005 Author Report Share Posted September 19, 2005 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) Link to comment Share on other sites More sharing options...
SCPCD Posted September 19, 2005 Report Share Posted September 19, 2005 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. Link to comment Share on other sites More sharing options...
GT Turbo Posted September 19, 2005 Author Report Share Posted September 19, 2005 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 Link to comment Share on other sites More sharing options...
GT Turbo Posted September 19, 2005 Author Report Share Posted September 19, 2005 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 !! Link to comment Share on other sites More sharing options...
Fredifredo Posted September 20, 2005 Report Share Posted September 20, 2005 Alors donc on pourrait théoriquement affiché 1400 sprites en simultané c'est ça ? Link to comment Share on other sites More sharing options...
SCPCD Posted September 20, 2005 Report Share Posted September 20, 2005 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 Link to comment Share on other sites More sharing options...
GT Turbo Posted September 21, 2005 Author Report Share Posted September 21, 2005 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 Link to comment Share on other sites More sharing options...
SCPCD Posted September 22, 2005 Report Share Posted September 22, 2005 Salut ! Je voulais savoir : qu'elles sont les données modifiées par le OP exactement ? Link to comment Share on other sites More sharing options...
GT Turbo Posted September 22, 2005 Author Report Share Posted September 22, 2005 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 Link to comment Share on other sites More sharing options...
SCPCD Posted September 22, 2005 Report Share Posted September 22, 2005 OK Merci. Link to comment Share on other sites More sharing options...
GT Turbo Posted September 22, 2005 Author Report Share Posted September 22, 2005 SCPCD : OKMerci. 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 !! Link to comment Share on other sites More sharing options...
GT Turbo Posted September 30, 2005 Author Report Share Posted September 30, 2005 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é !! Link to comment Share on other sites More sharing options...
GT Turbo Posted January 4, 2006 Author Report Share Posted January 4, 2006 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 !) Link to comment Share on other sites More sharing options...
SebRmv Posted July 28, 2006 Report Share Posted July 28, 2006 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 ? Link to comment Share on other sites More sharing options...
SCPCD Posted July 28, 2006 Report Share Posted July 28, 2006 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 Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now