J'y penses depuis un moment mais la on va tous y réfléchir en meme temps pour avoir le meilleur.



Sur la Jag les sprites sont affichés d'après une liste, qui décrit différents parametres pour chaque sprites, et surtout dans les parametres il y a un adresse qui permet de 'linker' le prochain descripteur de sprite.



95% des jeux Jag ou des sources que j'ai pu voir font de la liste statique. On genere la liste chaque Vbl d'après une sorte de pseudo liste.



Mais on pourrait généré une premiere fois la liste en statique et après la géré en dynamique, au lieu de reconstruire la liste, utilisé la possibilité de 'linker' pour effacé ou rajouté un sprite et tout cela pourrait se faire au Gpu, apparement personne ne l'a fait ou y a pensé.



Quelqu'un a une meilleur idée ? Ou une autre technique ?



GT Curieux !! :p

Je viens de me rendre compte avoir créer deux fois le même forum... :wacko:

Bon, ce topic passe en développement, parce que faut pas déconner et je clos un des deux forums...



P.S. : Au fait, c'est pas un débat ça, hein, c'est juste une requète (sur une) technique. Je suis pas Robert (celui qui commence par A, finit par Z et est énorme) mais faut voir à pas prendre les coins pour des coing.

Salut !



En fait, j'y ai déjà pensé ;) !



Pour mon OS, j'ai réservé une zone mémoire suffisante pour faire une liste de 100 sprites et j'ai ensuite fait un system dynamique : je peux rajouter, enlever, activer ou desactiver n'importe quelle objet afficher et tout sa en pouvant changer l'ordre d'affichage très facilement. (j'utilise une liste chainée)



Pour pouvoir trouver l'objet souhaitait, j'ai rajouter un champ 'nom' qui me permet de mettre un nom à un objet et ainsi de le retrouver facilement.



Ceci me permet de faire :

une initialisation de l'affichage au démarrage avec une image de fond et la souris;

et ensuite, je peux rajouter les icones, qui sont donc physiquement après l'objet souris mais avec les liens de la liste modifié tel que la souris reste toujours le dernier objet à afficher.



Ce code a été fait au GPU.

je pourrais te filer le code et une partie des explications supplémentaires ce week-end.



voici un début d'explication :

[pfs]5-jev2_f_objs.pdf[/pfs]



A+

La tu me laisses sur le c..





GT Epaté !! :wub:

Voici comme prevu le code GPU et le code 68000 qui va avec.



Mais ne pouvant pas mêtre tout le code (secret oblige ;)), ce code n'est qu'a titre indicatif.

il n'est pas possible d'utiliser directement le code (utilisation de variable systeme, et de fonctions que je garde pour l'instant)



Néanmoins, les noms des variables systems sont suffisaments clair pour qu'il soit possible de le faire fonctionner et certaines fonctions utilisé non fourni peuvent être zappées sans problem.



Je pense que même si il n'y a pas (du tout) beaucoup de commentaire, le code est suffisament clair pour être compris.



Et de toute facon, je suis là !!!

Alors pas de panique !!

N'hésitez surtout pas à me poser des questions !!;)



SCPCD.





[pfs]5-code_opliste.txt[/pfs]

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 ?



Est ce qu'il reste un domaine ou tu as pas fais des essais ? Que je puisse quand meme faire quelque chose ? lol !!



La compression (D'images et de données) en général, t'y a pas encore mis le nez dedans si ? Sinon j'ouvres un autre sujet pour pouvoir en discuter, et cela me laissera un domaine ou fouiller !!



GT Trop épaté par SCPCD :yes:



P.S. : On a pratiquement tout ce qu'il faut pour dvper des jeux en séries ! lol !

Ben en fait, sur mon OS, j'ai utilisé des traps pour des fonctions spécials comme l'ajout de sprites(voir precedent), j'ai aussi fait des fonctions pour l'allocation mémoire et la pagination (au passage : trop génial la pagination quasi-hard ;)!!), et bien d'autres....



Mais je ne sais pas trop si je vais garder le principe des traps car ce sont des interruptions et sa augmente le niveau de priorité du 68000...(et donc sa ralentit le DSP et GPU)



c'est pratique mais bon.....

j'hésite encore a les garder....



Sinon, pour que GT puisse s'occuper :p :



Je n'ai pas du tout touché a la compression de données ni des images.

Ni a la musique d'ailleurs.(sa serais bien du MP3 non ?)



Au fait, en parlant de compression, il y a une compression video qui semble assez puissante et je voudrais savoir si c'est possible de le faire pour la Jag : c'est la compression XYZ. (elle compresse plus que du MPEG1 et est de meilleur qualité et a besoin que d'un peu plus de puissance)



A+

SCPCD.

Tu as un peu de doc sur ta compression XYZ ?



Je m'occupes de la partie compression, ayant déjà eu l'occasion de faire 2,3 trois essais avec Azrael. Par contre je vais surement voire pour trois compressions différentes :



- graphisme fixe

- graphisme animé

- son



J'ouvre un autre sujet pour eviter de polleur celui la.





GT En train de compressé ! ;)

J'ai pas encore eu le temps de regardé en détail ton code, comme j'ai encore celui de Fredifredo a regarder de près. Apparement le processeur objet détruit des parties de phrases de certain objets, c'est vrai ? Et c'est bien ce indiqué dans la doc ?





GT Turbo :D

D'après mes tests et la doc, il semble bien que le processeur d'objets modifie le DATA pour savoir qu'elle est l'adresse du debut de la prochaine ligne de l'image.



SCPCD :D

C'est ça la cause de mes 2 pixels transparents qui sont noirs ?

Allo ? GT as-tu jeter un oeil à mon code source ?



( surtout la liste des objets ...)

J'ai enfin rallumé mon Falcon, et commence a m'y remettre.





GT Turbo :yes:



Fredi regarde tes messages privés !!

Je fais remonter ce sujet, car j'ai commencé a écrire un gestionnaire de liste, pour l'instant juste au 68000 (Quoique que vu les décalages et les bricolages sur les champs de bits, le Gpu serait plus de mise). Je réécrirais celui ci après au Gpu, cela pour des histoire d'optimisation et de controle.



Le but étant bien sur de tout faire au Gpu, mais absolument tout, cela pour éviter de plomber le bus avec notre 'escargot' de 68000, le maillon faible d'une Jaguar. Au départ j'avais prévu une base de 192 sprites, car c'était divisible par 32, mais après calcul et essais, je m'apercois que le procédé que je voulais utiliser est plus lent que l'actuel et mange de la ram en plus pour rien, donc 'au revoir !'.



Je vais allez continuer le code, a plus !!



TG orbuT :wacko:

Mouais, si ça continue on va retirer le 68000 car il bouffe du temps d'horloge sur le bus :p

C'est exactement cela, le but du jeu c'est de rentrer le maximun dans le couple Gpu / Dsp et de carrément mettre le 68000 en attente, pour éviter qu'il nous traine ces boulets !!



GT En train d'accélerer ! :yes:

Je reprends un peu le code ce soir, et a partir de demain soir, je me bloques le weekend sur la gestion de liste, je veux voir des sprites, des sprites a la tonne, mon écran plein de petit spritos tout colorés, désolé pour le délire mais j'ai trop hate.



GT Amoureux des sprites :yes:

Vu que maintenant je peux debugger les listes de sprites, j'ai pu réparer ma routine, et j'ai commencé a écrire les routines pour modifier les coordonnées, en X cela est passé tout seul en Y j'ai un petit soucis suite au fait de la restauration de la liste vu qu'elle n'est pas réconstruite a chaque Vbl (Power !!! :yes:), mais ce soir j'attaques de plein pied !!



GT Parti coder !! :yes:

AAAAAAAAAARRRGGGHHH !! Je vais finir interner !! Mon gestionnaire de sprite ne veut pas m'écrire mon objet de fin de liste (Stop objet) en 3 position quand j'ai deux objets !! Avec un objet cela marche parfait, mais avec 3 il s'amuse a me placer un sprite 'objet bitmap' vide a la place et bonjour le plantage !! Je vais me calmer un peu et reprendre plus fort, c'est pas un bout de code qui aura ma peau !! Parce que GT Trop fort (Et surtout très vantard....)





GT En train de me calmer !! :wacko:

faut pas une liste paire en nombre de sprites ?

Non, le nombre de sprite peut ètre impaire, je vais vérifier certaines choses, car le plus c.... c'est que la liste doit se trouver sur une adresse multiple de 8 (Cela passe encore), un ojet bitmap standard doit ètre aligné sur 16, un objet bitmap zoomé sur 32, donc faut que je vérifies aussi tous les alignements (Cela fait que la 4 fois que je le fais !)



GT Pas sur la limite !! :wacko:

As-tu regardé dans le code source que je t'ai envoyé ? ou bien celui de Pong ?

Mon problème est plus un problème de code meme, pas de principe, et le petit truc c'est que beaucoup de personnes reconstruises la liste a chaque Vbl, c'est plus simple mais moins rapide c'est pour cela que d'autres sources ne sont pas trop a meme de m'aider, mais le truc ultra c.. c'est que je fais les essais d'abord au 68000 pour après recoder le tout au Gpu, je ferais mieux d'attaquer au Gpu direct, j'ai l'impression que je me débrouilles mieux avec lui qu'avec le 68000 :wacko:



Ca va se finir comme cela.....





GT Un super pote au Gpu :wub:

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

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

Dès que tu as un petit exe qui traine , je suis preneur ... ;)

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

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

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:

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.

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:

Au temps pour moi.

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)

C'est exactement cela !! :yes:







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









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:

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)

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

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

Alors donc on pourrait théoriquement affiché 1400 sprites en simultané c'est ça ?

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 ^_^

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

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

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:

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

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

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