numero-15

Oué, c'est sur que sans des petits programmes comme ça l'apprentissage des bases serais très très dur, surtout pour les gens qui, comme moi, n'on aucune notion en assembleur. Sinon pour les photos, la c'était juste un test, mais je trouve le résultat plutôt encourageant, surtout que j'ai vraiment fait ça vite fait. Je vais essayer d'améliorer tout ça, promis!

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.

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.

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!

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.

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.

Yeah, sympa le mode 7. Mais il me semblais avoir lu quelque part que quand on utilise le mode 7 on ne peut avoir qu'un background, la tu en utilise 3, comment tu fais? En tout cas le rendu du mode 7 est quand même assez cool. Sinon voila un petit test, dérivé aussi du walker! Je voulais juste voir ce que ca donnait d'utiliser des photos pour faire les graphismes.

Bonjour, Je suis étudiant à Strasbourg, et j'ai, avec un ami, décidé d'apprendre à développer sur la Super Nintendo. Après pas mal de recherches, je commence aujourd'hui à comprendre quelques bases de la programmation SNES, grace à la documentation de olorin, de Qwerti (en anglais),etc . Cependant, la documentation sur ce sujet étant très limité, et n'ayant auparavant jamais programmé en assembleur. Je me trouve maintenant bloqué et me tourne vers vous en esperant que vous pourez m'aider dans mes débuts. Numero-15