Monos -
posté le 03/01/2023 à 06:50:42 (57322 messages postés)
❤ 2Nemau Picot
Vive le homebrew
Mes consoles à moi
Introduction La PVSNESlib est une bibliothèque de fonction et d'outil pour créer des jeux sur la fameuse Super Nintendo.
Elle est réalisé par mon ami Alekmaul.
Cette lib permet de coder dans le langage c. (Très utilisé sur les machines retro) et bien sur en Assembleur.
Elle comprend des outils comme un compilateur C, un logiciel de conversion d'image, des outils pour utiliser tiles pour faire ses map.
Cette lib peut être utilisé sur Windows et Linux. (Je pense aussi sur mac en recompilant tout les outils.)
Mes Videos Tuto Je suis en train de faire des vidéos tuto sur la SNES.
Installation de la lib
C'est pas très compliqué mais il y a une paire de dépendance. (Python , MSYS et des variables d'environnement à toucher ce qui peut être compliqué pour les gens qui n'ont pas l'habitude. Souvent l'installation merde à cause de Python)
Le Vram Dans une machine retro le plus important c'est de comprendre comment fonctionne la Vram.
Ou se stock les graphismes, l'organisation de l'écran, les sprites. La snes fait intervenir des "pointeurs" pour cibler des parties de la vram. Au début c'est pas facile à comprendre.
Sprites Et oui, la snes permet d'afficher 128 sprites !
Le pad Petite vidéo sur une utilisation très simple du pad de la snes.
LA snes peut gérer 5 pads. C'est vraiment sympathique.
Convertir les images en data pour la snes !
Utilisation de Vmain pour bien envoyer des datas en Vram !!!
Priorité des tiles/background
* ------------------------------------------------------------------------------------------* Des infos technique de la snes qui va évoluer en fonction de mes connaissances * ------------------------------------------------------------------------------------------*
La Super Nes ou snes ou Super Famicom - La machine débarque fin 1990 au japon, elle remplace la nes.
- Elle possède un processeur 8/16bits (si si) cadancé à 3.58 en mode maximum.
- Elle possède deux puces graphique. Le PPU1 qui gère les tiles et sprites et PPU2 pour la palette de couleur et le signale Video.
La résolution de la console est de 256x224 px à 512*448pixel. (en fonction du mode vidéo)
La machine possède 128 ko de Ram de travaille (contre 64ko pour la Megadrive, 2ko pour la nes et 8ko pour la master system et Pc Engine).
La machine possède 64ko de video Ram. (Identique à la Megadrive). Pour information (encore ?) la master system dispose 16ko en Vram et 2ko est disponible pour la nes(mais la nes n'a pas besoin de mémoriser ses paterne de tiles en VRAM elle sont mémoriser en dur dans une puce(la CHR))
La VRAM permet de mémoriser les tilemaps et les paternes graphiques.
La capacité maximum d'une cartouche est de 4Mo sans bank switching.(c.a.d sans echanger une partie de ram cartouche par une autre.)
La snes permet de gérer 128 sprites à l'écran elle possède sa propre mémoire pour mémoriser les informations du sprite à afficher. (Seul les paterns des sprites sont memoriser dans la Vram les donnés / position d'un sprites à sa propre mémoire pour faire simple).
Les modes Video La Snes possède plusieurs mode d'affichage. La puce graphique est une des plus puissantes de sa génération. (Avis personnelle) Elle surplante celle de la megadrive. (Mais la megadrive à un meilleur CPU !!!)
La SNES possède 8 modes video.
- Le Mode 0 : permet d'avoir 4 background. Chaque background est en mode 4 couleurs.
- Le Mode 1 : Permet d'avoir 3 background. Les 2 premier background est en mode 16 couleurs. Le 3em est en mode 4 couleurs. (Mode la plus utilisé dans la snes ?)
- Le Mode 2 : Permet d'avoir deux background de 16 couleurs.
- Le mode 3 : Permet d'avoir le premier background en 256 couleurs et le 2em background en 16 couleurs.
- Le mode 4 : Permet d'avoir le premier background en 256 couleurs et le 2em background en 4 couleurs.
- Le mode 5 : Permet d'avoir le premier background en 16 couleurs et le 2em background en 4 couleurs.
- Le mode 6 : Permet d'avoir un seul background en 16 couleurs
- Le Mode 7 : Permet d'avoir le premier background en 256 couleurs.
- Le Mode 7extbg permet d'avoir le premier background en 256 couleurs et le 2nd en 128 couleurs
Sans vraiment me mouiller, plouf, Seul deux modes vidéo est vraiment très utilisé. Le mode 1 pour avoir les 2 background en mode 8 palettes de 16 et un troisième plan qui peut aider pour les hud (voir des effets) et le mode 7 ! Les autres mode est plus souvent la pour faire le kikoulou à la megadrive !!!
(ta vu j'ai plus de mode video que toi ! Na !)
Notons que certain mode vidéo se ressemble en apparence mais possède des options différentes sur le scrolling.
Les Palettes La SNES possède un espace ram pour mémoriser la palette de couleurs. Cette espace et de 512 octets.
Le SNES permet de mémoriser 256 couleurs. Chaque couleurs est encodé sur 2 octets et le Format d'encodage d'une couleurs est sur 15 bits.
5 bits pour de Bleu, 5 bits de Vert, et 5 Nuances pour le rouge. Ce qui fait 32 nuances de chaque teintes soit 32768 possibilités.
L'encodage est la suivante :
0BBBBBVV
VVVRRRRR
Le 1er bit n'est pas utilisé.
------------------------
* Mode 16 couleurs *
------------------------
Les 256 couleurs de la palettes de couleurs est en réalité divisiés en 16 palettes de 16 couleurs dont la premier couleurs d'une série est la couleurs transparente.
Les 8 premières palettes sont reservés au tiles des background. Et les 8 dernières palettes de couleurs sont reservés pour les sprites.
-------------------------------------------
* Le Mode 0 et 4 couleurs de la snes *
-------------------------------------------
Le Mode 0 et des background en mode 4 couleurs n'utilisent pas des palettes de 16 couleurs mais de 4 couleurs.
Les 32 premiers couleurs sont découpé en 8 palettes de 4 couleurs. Et la 1er couleurs de chaque série est n'est pas affichés. (Couleurs transparente)
-------------------------
* Mode 256 couleurs *
-------------------------
Ce mode permet d'avoir un tiles qui pioche dans les 256 couleurs de la palette.
Configuration du background Chaque background Peut être configuré de 4 manière. Ce qui corespond à la taille du background en tiles.
(Notons que sur SNES un tile est de 8x8 pixel ou 16x16 pixel, mais encore une fois quand je regarde les jeux en emulation c'est fréquament configuré sur le mode 8x8 pixels)
- 32x32 tiles
- 32x64 tiles
- 64x32 tiles
- 64x64 tiles.
Chaque emplacement dans le background (tilemap), est encodé sur deux octets.
Ce qui fait qu'une tilemap de 32x32 tiles prend 2048 octets dans la VRAM.
Une tilmap de 32x64 (ou 64x32) prend 4096 octets.
Et une tilemap de 64x64 tiles prend 8192 octets dans la Vram.
Chaque double octet permet (un mots) d'afficher un tile à l'écran avec des options.
Une tilemap possède la capacité de piocher dans 1024 tiles. (10 bits), Et choisir entre un panel de 8 palettes de couleurs pour le tiles à afficher, (3 bits), un bit de priorité pour le tile afficher 1 bit pour retourner verticalement le tile à afficher, et un autre pour retourner horizontalement le tile à afficher.
Encodage d'une case de la tilemap sur deux octets.
VHOPPPCC CCCCCCCC
V : Flip Vertical.
H : Flip Horizontal.
O : Tile priorité
PPP : Palette de couleurs
CCCCCCCCCC : Index du tiles à afficher.
Chaque Background possède deux pointeurs dans la VRAM.
Un pointeur pour savoir ou la Tilemap se trouve dans la VRAM.
Et un pointeur pur savoir ou se trouve l'index 0 de son catalogue de tile à afficher.
Ce qui veux dire que chaque background peut posséder son jeu de tile si le pointeur de tiles est différent d'un autre background...
Envoyer des datas au CPU Le pvsnes lib possède des "fonction" pour travailler directement les registres de la snes.
CE registre permet de configurer le mode incrémentation du PPU. Pour faire simple la SNES à un mode automatique quand on envois une data dans la VRAM incrémenté l'adresse Cible automatiquement sans avoir besoin de reconfigurer l'adresse en question. Pratique. MAIS cette incrémentation se fait automatiquement après qu'on à memoriser une valeur dans le 1er octet ou le 2em octet.
J'explique : La vram fonction sur un mots de 16 bits. (deux octets). Le premier octet est le poids faible et le 2em octet est le poid fort.
Si le bit du poids fort du Vmain (registre 8bit) est 0, incrémentation se fait après que l'octet du poid faible est mémorisé en Vram.
Si le bit du poids faible du Vmain est à 1, l'incrémentation se fait après que l'octet du poids fort est mémorisé en Vram.
Permet de mémoriser l'adresse en mots ou va débuter le transfère de data en Vram.
Attention la valeur est en mots est non en octet.
REG_VMADDLH = 0x2 revient à taper à l'adresse 0x4 de la Vram.
C'est ce registre qui est incrémenté automatiquement.
Permet d'envoyer une valeur 16bits directement en Vram. Pratique pour updater la tilemap. Dans cette exemple
REG_VMDATALH = 0b0010000000000100 ;
Permet d'envoyer un tiles dont l'index est 4 avec une priorité de 1.
Attention l'encodage ici est bien dans l'ordre mais une fois en Vram c'est les 8 derniers bit qui est mémorisé dans l'octet 0 et les 8 premier bit dans l'octet 1.
Il faut bien passer le bit 7 à 1 du registre Vmain pour que l’incrémentation se déclenche correctement !
Permet d'envoyer dans la Vram l'octet du poids fort.
Encore une fois faite attention à l'ordre d'écriture des fonctions et la configuration du Vmain.
Notons aussi que se sont des registres CPU. Les datas sont envoyer quand la Vram est "ouverte" en ecriture.
c.a.d quand l'écran est éteint, ou quand le balaye écran est en train de remonter au haut de l'écran. (Après le signale du Vblank !)
BG3 tiles with priority 1if bit 3 of $2105 is set
Sprites with priority 3
BG1 tiles with priority 1
BG2 tiles with priority 1
Sprites with priority 2
BG1 tiles with priority 0
BG2 tiles with priority 0
Sprites with priority 1
BG3 tiles with priority 1if bit 3 of $2105 is clear
Sprites with priority 0
BG3 tiles with priority 0
Taille d'un patern !!! J'ai pas beaucoup parlé de ça mais voyons un peu ce que prend un patern en Vram.
Un patern est un tile de 8x8pixel. (Notre mosaique).
En fonction du mode vidéo il peut être encodé sur 2bits par pixel (4 couleurs), 4 bits par pixel(16 couleurs), ou 8 bits par pixel(256 couleurs, il tape dans tous le nuancier)
Un sprite c'est obligatoirement des paterns sur 16 couleurs.
En mode (nes), soit 4 couleurs un patern de 8x8 prend 16 octets en Vram.
En mode 16 couleurs on est à 32 octets par patern en Vram.
En mode 256 couleurs on est à 64 octets par patern en Vram.
N'oublions pas que dans la Vram il faut aussi placer la tilemap des background.
Chaque background possède 4 tailles
- 32*32 tiles. (2048 octets dans le PPU)
- 64*32 tiles. (4096 octets dans le PPU)
- 32*64 tiles. (4096 octets dans le PPU)
- 64*64 tiles. (8192 octets dans le PPU)
Et que la Vram est limité à 64ko de Ram !
Aller petite calcule voir ce que la Vram peut manger à un instant T !:
- On peux adresse 512 sprites : Ce qui fait déja 16384 octets.
- Chaque background peut adresse 1024 tiles pour l'exo on reste en 8x8.
Ce qui fait : 32,789 ko en mode 16 couleurs pour un jeu de tileset complet.
Il reste en gros 16ko pour les tilemap. Notons qu'en mode 4 couleurs du mode 1 faut des tiles adapté. (16ko pour un jeu de 1024 tuiles). Outch. Tous ne passe pas
Tout ne passe pas !!! Voila c'était un petit exo pour s'en rendre compte.
La création d'un jeu retro est toujours un équilibre de pattern / sprite / background en Vram !
Notons que ce petit exo est calculé sur un instant T. Un jeu sur SNES remplace fréquemment les graphismes. (tileset/spritset) dans la Vram...
Petit travaille sur la Vram *****************************
*** Travaille sur la Vram ***
*****************************
25/01/2023
Notes : Les adresses sont en octets et non en mots...
* ============================== *
* Position du pointeur de sprite *
* ============================== *
4 blocs de $4000 (16384 octets) index de 0 et 511 tiles pour les sprites.
* =============================== *
* Position du pointeur de tilemap *
* =============================== *
4 configurations de tilempap
- 32*32 tiles. (2048 octets dans le PPU)
- 64*32 tiles. (4096 octets dans le PPU)
- 32*64 tiles. (4096 octets dans le PPU)
- 64*64 tiles. (8192 octets dans le PPU)
1 ecran = un bloc de $800
Gari -
posté le 03/01/2023 à 14:59:26 (5901 messages postés)
- -
❤ 0
C'est peut-être que moi, mais j'ai l'impression que la Nes (simple) intéresse beaucoup moins. J'en ai une à la maison et à part le premier Mario et le jeu des canards qu'on shoot, j'ai l'impression que la console a été plus oubliée par la SNES. C'était une machine de transition pas assez évoluée ? (je sais que graphiquement elle était plus limitée que la nes).
Citation:
La résolution de la console est de 256x224 px à 512*448pixel. (en fonction du mode vidéo)
Je comprends mieux pourquoi tu aimes VX et sa résolution bizarre qui ne veut rien dire (544*416).
128 sprites à l'écran c'est pas si mal, il y a déjà largement de quoi faire. Ca va être très RM ma question mais je suppose que pour la prog, doit aussi y avoir des events invisibles en processus parallèle/automatique ? Ou c'est géré totatement différemment (sur OHRRPG, les events/sprites sont gérés à part, et faut les appeler sur la map à l'aide d'une autre commode, c'est assez barbare dans mon souvenir) ?
AzRa -
posté le 03/01/2023 à 15:20:05 (11330 messages postés)
❤ 0
418. I'm a teapot.
Y avait pas que Mario Bros sur la NES, justement ?
-->[]
Agus fagaimid suid mar ata se.
Monos -
posté le 03/01/2023 à 17:31:53 (57322 messages postés)
❤ 0
Vive le homebrew
Citation:
C'est peut-être que moi, mais j'ai l'impression que la Nes (simple) intéresse beaucoup moins. J'en ai une à la maison et à part le premier Mario et le jeu des canards qu'on shoot, j'ai l'impression que la console a été plus oubliée par la SNES.
Oula que non. La nes fonctionne très bien.
J'en vois énormément.
Et des titres il y en a vraiment pas mal de bien.
La série des Ninja Gaiden, duck Tatel, tic et tac, la série des Dragon Quest et FF, et j'en passe...
Citation:
j'ai l'impression que la console a été plus oubliée par la SNES
La Snes est arrivés tard. La nes et resté longtemps...
Citation:
C'était une machine de transition pas assez évoluée ? (je sais que graphiquement elle était plus limitée que la nes).
Je ne sais pas ce que tu as envie de dire la ? Qu'es qui est plus limité que la NES ? A mon avis tu veux dire sur la Nes est plus limité que la SNES. Et c'est normale. On a quand même deux générations de console différente.
Citation:
pourquoi tu aimes VX et sa résolution bizarre qui ne veut rien dire (544*416).
J'ai toujours pas pigé la résolution de VX xd j'ai toujours utilisé un script pour passer en 640*480. Avec la "double résolution" cela fait du 320*240 qui est proche des machines retro.
Citation:
Ca va être très RM ma question mais je suppose que pour la prog, doit aussi y avoir des events invisibles en processus parallèle/automatique ?
Ah non xd
On doit tous gérer dans des boucles et tout ça. Il n'y a pas de notion événement.
- Debut de la Game Loop-- Tester les commandes du joueur
-- Mise à jour logique de la position du joueur avec calcule des collision.-- Mise à jour logique des monstres
-- Attendre le V blank (Le retour du balayage ecran)-- Mise à jour des sprites sur l'écran- Fin de la Game Loop retour au début de la game Loop
Tout se faire en code.
Je n'ai pas "éditeur RM".
Signer du nez ?
Gari -
posté le 03/01/2023 à 22:49:07 (5901 messages postés)
- -
❤ 0
Ah ah oui, j'imagine la douleur que ça doit être de programmer un rpg là-dessus, une grosse boucle avec toute la prog.
Je parlais bien des limitations de la nes par rapport à la snes, l'inverse aurait pas beaucoup de sens.
AzRa -
posté le 03/01/2023 à 23:12:02 (11330 messages postés)
❤ 0
418. I'm a teapot.
Bah c'est un peu la base de la programmation, une grosse boucle avec des plus petites dedans. C'est le même principe dans tous les langages. C'est ni une galère ni une impasse à être organisé. Au contraire. Et ça offre énormément de liberté. La galère de programmer sur la SNES ne se trouve pas là mais dans les limitations techniques de la machine. Quand tu vois que Monos peut pas dépasser les 8 couleurs à l'écran à la fois sinon la machine explose en supernova c'est là qu'elle est la galère.
L'event c'est un concept unique à RM, sinon, ou en tout cas aux logs de création de JV du style s'il y en a d'autres qui utilisent la même formule.
Ce qui se rapproche le plus du concept d'event en "vraie" progra c'est les fonctions et les objets. Je vais étendre un peu là parce que ça vaut pour le C comme ça vaut pour tous les autres langages (je ne connais pas le C en pratique mais c'est toujours un peu la même base dans tous les langages) : les boucles c'est le coeur du moteur : c'est litéralement ce qui tourne, comme dans un moteur (bon c'est pareil dans RM, ça, déjà, d'ailleurs). Ensuite dans tes boucles tu manipules des fonctions et des objets comme tu manipulerais des events communs dans RM. Comme tu peux accéder à n'importe quelle fonction n'importe où dans ton programme pour peu que tu l'aie déclarée au préalable ça se rapproche un peu des évènements communs de RM.
Mais en tout cas non y a pas de trucs invisibles à la mord-moi-le-noeud sur les maps comme dans RM. Une map c'est de nouveau soit une fonction soit un objet (ça dépend de ton langage et de tes préférences). Les autres trucs ne sont pas dessinés "dessus" mais codés à côté et appelés en fonction du besoin. C'est pour ça que si tu veux trouver un parallèle les events communs sont ce qui ressemble le plus aux fonctions et aux objets.
Les concepts sont différents mais ça ne veut pas dire que des parallèles ne sont pas traçables : la progra évènementielle simplifiée de RM trouve son inspiration dans la vraie progra, donc elle y ressemble forcément. C'est différent mais similaire quoi.
Agus fagaimid suid mar ata se.
Monos -
posté le 04/01/2023 à 04:08:38 (57322 messages postés)
❤ 0
Vive le homebrew
Citation:
j'imagine la douleur que ça doit être de programmer un rpg
La gestion des "event" carte oué. Mais bon rien ne m'empèche de créer un éditeur comme RM avec des events dans l'éditeur et de faire interprété ça par la snes !
(C'est ce qu'on appelle créer un moteur, je pense que les FF et DQ sont fait comme ça il doit y avoir des tas d'outils derrière)
Citation:
Je parlais bien des limitations de la nes par rapport à la snes, l'inverse aurait pas beaucoup de sens.
Je m'en douté. Tu as du t'embrouillé à l'écrit xd
Ba oui la nes est une génération 8bits amélioré xd (nes,master system c'est le gros duel) et la snes on est dans la génération 16 bits avec le combat snes/megadrivre.
Entre les deux en à la PC engine.
On passe de 2ko de ram de travaille pour la nes à 128 pour la snes !
Le PPU est beaucoup plus puissant sur la snes.
La nes c'est un nuancier d'une 50en de couleur, et 8 palettes de 3 couleurs pour faire simple. (4 pour les tiles du background, 4 pour les sprites et au background, c'est 1 palettes par zone de 16x16 c'est même pas au tile !!!)
Azra a bien résumé les choses.
Voici ma game loop sur DTL qui sera reprogrammer car ça par en cacahouette.
//+--------------------+//* Boucle de scene game *//+--------------------+while(get_scene()==SCENE_GAME){//--------------------------------------//*Test le bouton start pour la pause *//--------------------------------------if(get_input_input_btn()==PAD_BOUTON_START && down_key==0){
mode_pause =1;
down_key =1;
draw_text(TEXTE_X, TEXTE_Y,TX_PAUSE);}elseif(get_input_input_btn()==0&& down_key==1){
down_key=0;}//------------------------------------//* Compteur d'effacement de message * // ------------------------------------ if (cycle_message > 0) { cycle_message--; } // ----------------------------------------------- // * Compteur de déplacement du projectil joueur * // ----------------------------------------------- if (time_projectil > 0) { time_projectil--; } // -------------------- // * Gestion des test * // -------------------- test_death_player(); test_change_map(); // ------------------------------- // * Test de collision par cycle * // ------------------------------- switch (cycle) { case 1: test_collision_projectil(); break; case 2: test_collision_item(); break; case 3: test_collision_key(); break; case 4: test_collision_monster(); cycle = 0; break; } lunch_projectil(); mouvement_projectil(); mouvement_player(); mouvement_monstre(); cycle++; if (cycle_message == 1) { draw_text(TEXTE_X,TEXTE_Y," "); } // - Update Hud - if (get_update_hud()==1) { draw_info_hud(); } // ------------ // * Wait VBL * // ------------ spcProcess(); WaitForVBlank(); // -------------- // * Update PPU * // -------------- update_video(); update_video_full_B(); update_player_sprite(); update_projectil_sprite(); update_monster(); // -------------- // * Mode Pause * // -------------- while(mode_pause==1) { draw_text(TEXTE_X, TEXTE_Y,TX_PAUSE); // -------------------------------------- // * Test le bouton start pour la pause * // -------------------------------------- if (get_input_input_btn()==PAD_BOUTON_START && down_key==0) { mode_pause = 0; down_key=1; draw_text(TEXTE_X,TEXTE_Y," "); } else if (get_input_input_btn()==0) { down_key=0; } update_video(); WaitForVBlank(); } // End while pause } // end whil scene
Normalement cette boucle est joué entre 50 et 61 fois par seconde. Sauf quand j'ai plus de 2 ennemie à l'écran ou la ba ça ram donc j'ai mis la snes en pls.
Je dois faire de l'optimisation à donc et repreogrammer des tas de choses.
Je suis sur machine rétro et je pense que je dois éviter trop appelle de fonction et j'en fais beaucoup pour modifier / lire des valeurs avec des getter/setter. Je dois passer ça en variable global. En temps normale c'est pas bien !!! mais j'ai pas le choix.
Edit
Ajout d'une video pour l'utilisation du logiciel de conversion d'image de la snes.
Edit
Video sur le Vmain qui permet de configurer comment on envois les datas en Vram !
Signer du nez ?
Gaetz -
posté le 05/01/2023 à 10:47:14 (2396 messages postés)
❤ 0
...passe...
Est-ce qu'on peut faire tourner les programmes sur un emulateur snes ensuite ? Ca pourrait etre un exercice intéressant pour mes étudiants en programmation, de faire un jeu snes.
Monos -
posté le 05/01/2023 à 12:15:20 (57322 messages postés)
❤ 0
Vive le homebrew
Bien sur. Il faut même utiliser des emulateur pour avoir des outils de debug.
Signer du nez ?
Monos -
posté le 06/01/2023 à 06:39:52 (57322 messages postés)
❤ 0
Vive le homebrew
Priorité des tiles ! Parlons un peu de la superposition des tiles sur la snes. !!!
Le mode le plus utilisé sur la snes, c'est le mode video 1 qui permet d'avoir 3 backgrounds.
Un background est tous simplement une zone ou on mémorise les donnés d'un tile à être affiché à l'écran. Le Mode 1 permet donc d'avoir trois zones.
Les deux premiers background pioche dans les 8 palettes de 16 couleurs.
Et le background 3 "transformes" les 2 premiers palettes 16 de 8 palettes de 4.
Les trois backgrounds permettent donc de superposer 3 tiles au même endroit !
Oui mais comment savoir qu'elle tiles et au dessus ou en dessous d'un autre ?
Et c'est la que ça se complique un petit peux. Car sur SNES l'ordre de superposition des tiles est lié à son background combiné à un bit de priorité du tiles qui est posé.
Si on touches à rien, et qu'on joue seulement sur l'index des tiles à poser et sur le numero du background l'ordre de superposition est la suivante :
Le tiles du Background 1 est au dessus du Background 2 et qui est au dessus du background 3.
J'ai dis plus haut que chaque emplacement de t'il, il y a un bit de prorité. Si je place à chaque fois ce bit de priorité à 1 que ce passe t'il ?
Ba rien de change.
Le tiles en priorité 1 sur le Background 1 est au dessus du bit de priorité 1 du background 1 qui est au dessus du tiles avec le bit de priorité à 1 du background 3.
Ok et si je veux que mon tile du background 2 soit au dessus du tile du background 1 ?
Simple, le bit de priorité du tiles du background 1 doit être à 0 et le bit du priorité du background 2 doit être à 1.
Bien sur le jeu de superposition fonctionne au tiles et pour le même emplacement.
Le Background 3 est un peu particulier. Il possède que des palettes de 4 couleurs. Ce plan est souvent utilisé pour faire un Hud. Je peux voir aussi ce plan être utilisé pour des animations dans des RPG.
Mais lui bit de priorité a 1 ou 0 il reste en dessous des deux autres background.
SAUF si un autre bit d'un autre registre est activé pour placer en haute priorité ce background 3 si le bit de priorité des tiles sont posés dessus. (Mal de crane !)
Et les sprites ?
Et oui les sprites ont aussi une priorité avec les tiles <=> background.
Les sprites ont deux bits de priorités ce qui donne 4 facteurs de priorité.
Bon pour bien comprendre voici l'ordre de priorité des tiles/background en mode 1.
Bien plus facile à comprendre que mon charabia.
BG3 tiles with priority 1if bit 3 of $2105 is set
Sprites with priority 3
BG1 tiles with priority 1
BG2 tiles with priority 1
Sprites with priority 2
BG1 tiles with priority 0
BG2 tiles with priority 0
Sprites with priority 1
BG3 tiles with priority 1if bit 3 of $2105 is clear
Sprites with priority 0
BG3 tiles with priority 0
Et une video youtube avec un petit exemple en programmation.
La megadrive à aussi une histoire de priorité des background. Mais je ne sais pas si c'est au plan ou au tiles.
A ma connaissance les machines 8 bits qui fonctionnent en tileset ont qu'un seul plan de background. (Sauf la GameBoy qui intègre aussi un plan Windows).
La Nes et la master system possède un ordre de priorité Tiles <=> Sprites. Pour savoir si un tiles est au dessus d'un sprites ou l'inverse.
Chose rigolo c'est que ce n'est pas gérer pareil !
Sur NES ce bit de priorité se trouve dans les donnés d'un sprites. Chaque sprite à son bit de priorité pour savoir si il est afficher sous un tile ou sur un tile.
Sur Master system ce bit de priorité se retrouve dans l'encodage d'un tile donc un tile est sois en dessous de tous les sprites ou dessus !
Même si l'effet est "pareil" en apparence, la gestion n'est pas la même.
Voila bisous à demain xd.
Signer du nez ?
Créacoda -
posté le 06/01/2023 à 15:27:38 (1748 messages postés)
-
❤ 0
Je t'aurais bien vu en enseignement de la programmation, Monos.
Troma -
posté le 06/01/2023 à 16:08:29 (6431 messages postés)
-
❤ 0
Je procrastine
Ca a l'air cool de crée ses jeux retro mais franchement la programmation ca n'attire pas tout le monde, il y a pas de trucs plus simple ? Nesmaker utilise toolkit je crois mais je sais plus si il y a besoin de coder; c'est une sorte de rm accessible qui convertie le jeu en rom qu'il faudrait pour nuls comme moi.
ꀎꀎꀎꀎꀎꀎꀎ
Gari -
posté le 06/01/2023 à 17:19:03 (5901 messages postés)
- -
❤ 0
Créacoda a dit:
Je t'aurais bien vu en enseignement de la programmation, Monos.
Vu tous les tutos de monos sur le site (et je suis à peu près sûr qu'il en traîne ailleurs), tu pourrais oui.
Monos -
posté le 06/01/2023 à 21:27:51 (57322 messages postés)
❤ 0
Vive le homebrew
Citation:
Je t'aurais bien vu en enseignement de la programmation, Monos.
Houla. Attention quand même. Je programme mais je suis un piètre programmeur. La programmation ce n'est pas seulement aligner des boucles et des conditions. Il y a des concepts derrière ce qui est mille fois plus important que d’aligner une boucle for avec des if !
Citation:
il y a pas de trucs plus simple ?
Non. La SNES commence à peine a avoir son SDK en C !
Citation:
Nesmaker utilise toolkit je crois mais je sais plus si il y a besoin de coder;
J'ai le logiciel mais je ne suis jamais entrée dedans. Je sais que le duo papa fils qui ont crée kubo, le papa crée quand même des "script ASM" pour le log pour certain truc.
Citation:
franchement la programmation ca n'attire pas tout le monde,
Retourne 15/20 ans en arrière quand je suis arrivé ici Il ne fallais pas trop me parler de programmation pour XP/VX/ACE... Et un jour j’achète un atari st xd
Edit Mension
Voici une autre video du createur de la pvsneslib qui parle de la création de son nouveau jeu.
Signer du nez ?
Monos -
posté le 23/01/2023 à 06:32:25 (57322 messages postés)
❤ 0
Vive le homebrew
Taille d'un patern !!! J'ai pas beaucoup parlé de ça mais voyons un peu ce que prend un patern en Vram.
Un patern est un tile de 8x8pixel. (Notre mosaique).
En fonction du mode vidéo il peut être encodé sur 2bits par pixel (4 couleurs), 4 bits par pixel(16 couleurs), ou 8 bits par pixel(256 couleurs, il tape dans tous le nuancier)
Un sprite c'est obligatoirement des paterns sur 16 couleurs.
En mode (nes), soit 4 couleurs un patern de 8x8 prend 16 octets en Vram.
En mode 16 couleurs on est à 32 octets par patern en Vram.
En mode 256 couleurs on est à 64 octets par patern en Vram.
N'oublions pas que dans la Vram il faut aussi placer la tilemap des background.
Chaque background possède 4 tailles
- 32*32 tiles. (2048 octets dans le PPU)
- 64*32 tiles. (4096 octets dans le PPU)
- 32*64 tiles. (4096 octets dans le PPU)
- 64*64 tiles. (8192 octets dans le PPU)
Et que la Vram est limité à 64ko de Ram !
Aller petite calcule voir ce que la Vram peut manger à un instant T !:
- On peux adresse 512 sprites : Ce qui fait déja 16384 octets.
- Chaque background peut adresse 1024 tiles pour l'exo on reste en 8x8.
Ce qui fait : 32,789 ko en mode 16 couleurs pour un jeu de tileset complet.
Il reste en gros 16ko pour les tilemap. Notons qu'en mode 4 couleurs du mode 1 faut des tiles adapté. (16ko pour un jeu de 1024 tuiles). Outch. Tous ne passe pas
Tout ne passe pas !!! Voila c'était un petit exo pour s'en rendre compte.
La création d'un jeu retro est toujours un équilibre de pattern / sprite / background en Vram !
Notons que ce petit exo est calculé sur un instant T. Un jeu sur SNES remplace fréquemment les graphismes. (tileset/spritset) dans la Vram...
Bisous.
Signer du nez ?
Monos -
posté le 25/01/2023 à 06:39:32 (57322 messages postés)
❤ 0
Vive le homebrew
Petit travaille sur la Vram *****************************
*** Travaille sur la Vram ***
*****************************
25/01/2023
Notes : Les adresses sont en octets et non en mots...
* ============================== *
* Position du pointeur de sprite *
* ============================== *
4 blocs de $4000 (16384 octets) index de 0 et 511 tiles pour les sprites.
* =============================== *
* Position du pointeur de tilemap *
* =============================== *
4 configurations de tilempap
- 32*32 tiles. (2048 octets dans le PPU)
- 64*32 tiles. (4096 octets dans le PPU)
- 32*64 tiles. (4096 octets dans le PPU)
- 64*64 tiles. (8192 octets dans le PPU)
1 ecran = un bloc de $800