Aller au contenu
numero-15

problèmes de programmation

Messages recommandés

J'essai d'apprendre a programmer sur SNES, et j'ai donc plein de questions (bêtes sans doute) à poser.

La première étant au niveau de la gestion des sprites, je suis arrivé à afficher un sprite et à l'animer.

Mais j'ai un problème quand je veux utiliser plusieurs sprites differents en même temps. En effet le registre $2101 permet de désigner l'adresse de la vram à partir de laquelle se situe les données des sprites, si je ne me trompe pas. Cependant il me semble que ce registre ne permet que de gerer une table de sprite (128*128 pixels), est il possible de charger plus de données?

J'éspère que ma question n'est pas trop incompréhensible.

Partager ce message


Lien à poster
Partager sur d’autres sites

Salut

 

Je t'avouerais que j'ai perdu un peu le fil la dessus, j'essaye déjà de confirmer quelques point sur le processeur de la Snes avant de la programmer.

Si mes souvenir sont bon, je crois que tu peut mettre plusieurs sprites à la fois.

En fait tu as des "BG" et "objet", BG pour fond d'écran, au nombre de 4 (BG1 à BG4) et un objet qui sera le personnage principal par exemple.

pour le moment c'est tout ce que je connais, j'ai pas été plus loin.

Mais pourrais tu m'envoyer ton programme afin que je l'inclut dans la partie programmation ? Si possible commenté :mrgreen:

 

Merci

Partager ce message


Lien à poster
Partager sur d’autres sites

test 0.2.rar

 

voila mon programme, partielement annoté, j'ai utilisées certaines routines de nevitski (elles sont très bien faites, alors pourquoi s'en priver!) c'est pourquoi il y a des annotation en anglais par endroits. C'est dans ce programme que j'ai fais des tests sur la gestion des sprites, il y à donc des bugs graphiques! Il y a 2 sprites affichés mais mon problème persiste, en effet pour afficher 2 sprites je les ai fait tenir dans une table de sprite (128*128 pixel au maximum), mais il me semble que dans la plupart des jeux il y a sur l'écran bien plus de sprites qu'il serait possible de faire avec ma méthode. Surtout dans les jeux de combat ou les sprites sont très grands.

Oué tu à raison pour les calques BG et objet, en fait il me semble qu il faut mettre tout les sprites (de personnages) dans le objet, et mon problème est que je n'arrive à en mettre que un.

Je me suis amusé à desactiver les differents calques avec l'émulateur, il se trouve que la pluspart des jeux utilisent 3 BGs (2 pour pour les décors et 1 pour les textes, barre de vie, etc.) et que les sprites sont tous dans le calque objet.

Voila, c'est un peu embêtant de n'arriver à mettre qu'un sprite pour faire des jeux vidéos,hihi!

Si quelqu'un sait s'y prendre avec la gestion des sprites, je suis prenneur.

Partager ce message


Lien à poster
Partager sur d’autres sites

Je ne comprends pas bien ta question, mais la SNES est capable de gérer jusqu'à 128 sprites à la fois donc tu ne devrais pas avoir de problèmes de ce côté là.

Il te faut juste préparer les données à envoyer dans l'OAM (il y a un buffer de 256 bytes (2 par sprites) et un deuxième buffer de 32 bytes (2 bits par sprite)) et l'envoyer par DMA au momment du VBlank dans ta routine de NMI.

 

Je te conseille de faire une routine qui s'appelle un truc du genre "DrawSprite" qui va le rajouter dans la file des objets à envoyer à l'OAM et augmenter l'index pour le prochain sprite. Lors du VBlank tu envoie toutes les donées dans l'OAM par DMA et remet l'index à 0. Le jour ou tu fais un jeu plus compliqué ou la priorité entre les sprites est important il faudra en tenir compte.

 

Ah aussi "sprite" et "objet" c'est exactement là même chose, même si deux termes sont confus et pourraient désigner de nombreuses choses différentes dans le moteur de jeu.

Partager ce message


Lien à poster
Partager sur d’autres sites

Oui oui, tout ça j'ai fais.

L'OAM comprend, pour 128 sprite les données suivantes (sans se perdre dans les details) : position à l'écran, priorité, rotation horizontale, rotation verticale, palette de couleur utilisée, taille du sprite et numero du sprite à afficher dans la table de sprite (au maximum 128*128pixel).

C'est le registre $2101 qui désigne l'endroit ou commence les données graphiques pour les sprites (les images quoi).

Ma question est est il possible d'avoir plusieur tables de sprite?

Sinon la totalité des 128 sprites affichés (potentiellement) doit être inferieure à 128*128 px, pour tenir dans une table de sprite. Et il me semble que, notamment dans les jeux de combat, la taille totale des sprites affichés simultanement est superieure à 128*128px.

 

Voila, j'éspère arriver petit à petit à me faire comprendre, c'est pas facile, je suis encore très débutant avec ce langage, et il m'est difficle d'expliquer clairement des choses que je ne comprend pas bien.

 

En tout cas merci d'essayer de m'aider, c est vraiment sympa!

Partager ce message


Lien à poster
Partager sur d’autres sites

Il est possible d'avoir plusieurs tables de sprites en software, mais dans l'OAM de la SNES il y a de la place pour 128 sprites à la fois, tu ne peux tout simplement pas en avoir plus.

Je ne vois pas le rapport avec 128x128 pixels, en fait la SNES supporte les sprites de plusieurs tailles, les plus gros ayant jusquà 64x64 pixels. Si tu veux afficher un écran complet rien que avec des sprites, il te suffira d'en utiliser 4x4 de cette taille pour couvrir tout l'écran de la SNES ! (Exemple : Chrono Trigger dans un portail temporel)

 

Il y a cependant une limite, la SNES ne peut utiliser que 32 différents sprites sur une même ligne, et les gros sprites sont convertit en petits sprites de 8x8 pixels à l'intérieur : Si la totalité dépasse 34 petits sprites par ligne alors la SNES laisse tomber le reste (faute de temps). Ces limites peuvent amener à des bugs graphiques, visibles dans Secret of Mana et Zelda 3.

 

Je ne sais pas si ça répond à ta question, si non sois plus clair s-il-te plait.

Partager ce message


Lien à poster
Partager sur d’autres sites

Ok merci pour toutes ces précisions.

Le rapport avec les 128x128 pixel c est que, en fait, le registre de l'OAM ou l'on spécifie le tile à partir du quel le sprite va être affiché ( autrement dit le carré de 8*8px en haut a gauche du sprite affiché) est de cette forme: XXXXYYYY X et Y étant les coordonnées du tile de départ du sprite. Donc les coord du tile de départ sont comprisent entre $00 et $FF (donc entre x=0 Y=0 et X=128px Y=128 px). Voila le rapport avec les 128px. Par contre cela fait que la table peut mesurer 128+1sprite de long et de large. Donc je m'excuse pour dire un peu nimporte quoi, mais j'étais pas loin quand même, hihih!

Bon vu que c'est assez incompréhensible, j ai mi un petit schéma d'une table de sprite.

Mon problème est que si je charge plusieurs tables de sprites (dont la taille totale excède 128+1sprite de long et de large) comment dire à l'OAM que mon tile de départ n'est pas dans la 1ere table? Puisque la seule chose que je peut lui dire concernant l'emplacement de mon sprite est la coordonnée DANS la table et non QUELLE table.

Mais je crois avoir trouvé une réponse ici http://www.romhacking.net/docs/%5B196%5Dregs.txt l'explication est bien plus précise que les docs que j'avais trouvé jusqu'a aujourd'hui! Je verrais ca demain.

Partager ce message


Lien à poster
Partager sur d’autres sites

Je n'ai toujours pas compris ton problème, mais je crois avoir un peu plus saisit. Le nombre de sprites adressable dans l'OAM en une fois n'est pas suffisant c'est ça ?

La solution est de changer les graphiques chargés dans la VRAM lorsque l'animation des sprites change durant le VBlank par un DMA. Je ne suis pas sur de combien de données tu peux transférer par VBlank (je crois environ 6ko pour tout ?) mais je suis à peu près sur que la grande majorité des jeux SNES font cela, en tout cas pour le protagoniste principal.

Partager ce message


Lien à poster
Partager sur d’autres sites

Oui, je pense faire ça.

Ca y est je pense avoir compris le fonctionnement des sprites et des backgrounds, une bonne chose de faite!

Merci pour tes conseils, ca aide vraiment de pouvoir discuter plutôt que d'apprendre tout seul.

Bon je vais me lancer dans le code à proprement parler, histroire de rendre tous ca plus interactif.

Je posterai ici mes prochains essais.

 

 

Sinon il faudrai peut être que j'apprenne le fonctionnement du HDMA, ca m'a l'air bien sympathique.

Partager ce message


Lien à poster
Partager sur d’autres sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Invité
Répondre à ce sujet…

×   Collé en tant que texte enrichi.   Restaurer la mise en forme

  Seulement 75 émoticônes maximum sont autorisées.

×   Votre lien a été automatiquement intégré.   Afficher plutôt comme un lien

×   Votre contenu précédent a été rétabli.   Vider l’éditeur

×   Vous ne pouvez pas directement coller des images. Envoyez-les depuis votre ordinateur ou insérez-les depuis une URL.

Chargement

×
×
  • Créer...