Day.png);">
Apprendre


Vous êtes
nouveau sur
Oniromancie?

Visite guidée
du site


Découvrir
RPG Maker

RM 95
RM 2000/2003
RM XP
RM VX/VX Ace
RM MV/MZ

Apprendre
RPG Maker

Tutoriels
Guides
Making-of

Dans le
Forum

Section Entraide

Sorties: Star Trek: Glorious Wolf - (...) / Sorties: Dread Mac Farlane - episode 3 / News: Plein d'images cools créées par (...) / Sorties: Star Trek: Glorious Wolf - (...) / Jeux: Final Fantasy 2.0 / Chat

Bienvenue
visiteur !




publicité RPG Maker!

Statistiques

Liste des
membres


Contact

Mentions légales

388 connectés actuellement

29190205 visiteurs
depuis l'ouverture

5256 visiteurs
aujourd'hui



Barre de séparation

Partenaires

Indiexpo

Akademiya RPG Maker

Blog Alioune Fall

Fairy Tail Constellations

Le Comptoir Du clickeur

Tashiroworld

Planète Glutko

New RPG Maker

Leo-Games

Tous nos partenaires

Devenir
partenaire



forums

Index du forum > Généralités > Programmer la snes


Monos - posté le 03/01/2023 à 06:50:42 (57322 messages postés)

❤ 2

Vive le homebrew

image
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.)

Le Github pour récupérer la lib.
La documentation




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.

Portion de code : Tout sélectionner

1
REG_VMAIN = value


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.

Portion de code : Tout sélectionner

1
REG_VMADDLH


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.

Portion de code : Tout sélectionner

1
REG_VMDATALH


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 !

Portion de code : Tout sélectionner

1
   REG_VMDATAL


Permet d'envoyer dans Vram l'octet du poids faible.

Portion de code : Tout sélectionner

1
REG_VMDATAH 


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

Priorité des tiles/background

En Mode video 1 de la snes !

Portion de code : Tout sélectionner

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
  BG3 tiles with priority 1 if 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 1 if 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.

$0000 ($2000)
$4000 ($6000)
$8000 ($A000)
$C000 ($E000)

* =============================== *
* 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

1 à 4 background en fonction du mode vidéo.

$0000
$0800
$1000
$1800
$2000
$2800
$3000
$3800
$4000
$4800
$5000
$5800
$6000
$6800
$7000
$7800
$8000
$8800
$9000
$9800
$A000
$A800
$B000
$B800
$C000
$C800
$D000
$D800
$E000
$E800
$F000
$F800



* =============================== *
* Position du pointeur de tileset *
* =============================== *

en pattern de 8x8

2 bits par pixel = 16 octets (16318 octets le tileset $4000)
4 bits par pixel = 32 octets (32768 octets le tileset $8000)
8 bits par pixel = 64 octets.(65536 octets le tileset $FFFF)

1024 patterns (8*8 ou 16x16) par background.

$0000
$2000
$4000
$6000
$8000
$A000
$C000
$E000

......Mode 4 bpp ... 2bpp

$0000 => $8000 => $4000
$2000 => $A000 => $6000
$4000 => $C000 => $8000
$6000 => $E000 => $A000
$8000 => // => $C000
$A000 => // => $E000
$C000 => // => //
$E000 => // => //

========
* Vram *
========
Screen
------------------------------
$0000 = Sprites
$0800
$1000
$1800
$2000
$2800
$3000
$3800
------------------------------
$4000 = Sprite
$4800
$5000
$5800
$6000
$6800
$7000
$7800
-----------------------------
$8000 = Sprite
$8800
$9000
$9800
$A000
$A800
$B000
$B800
-----------------------------
$C000 = Sprites
$C800
$D000
$D800
$E000
$E800
$F000
$F800

Signer du nez ?


Gari - posté le 03/01/2023 à 14:59:26 (5899 messages postés) - honor

❤ 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). X)

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 (11193 messages postés)

❤ 0

Y avait pas que Mario Bros sur la NES, justement ?

-->[]

Le cyclisme c'est quand tu fais du vélo.


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.

Voici un pseudo code par exemple !

Portion de code : Tout sélectionner

1
2
3
4
5
6
7
8
9
10
11
12
 
- 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 (5899 messages postés) - honor

❤ 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 (11193 messages postés)

❤ 0

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.

Le cyclisme c'est quand tu fais du vélo.


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.

Portion de code : Tout sélectionner

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
 // + -------------------- +
  // * 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);
    }
    else if (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 (2377 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.

Lije : démo 0.5 | Powered by Geex


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.

Portion de code : Tout sélectionner

1
2
3
4
5
6
7
8
9
10
11
12
 BG3 tiles with priority 1 if 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 1 if 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 (1276 messages postés) -

❤ 0

Je t'aurais bien vu en enseignement de la programmation, Monos.


Troma - posté le 06/01/2023 à 16:08:29 (6205 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 (5899 messages postés) - honor

❤ 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 :F 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.

$0000 ($2000)
$4000 ($6000)
$8000 ($A000)
$C000 ($E000)

* =============================== *
* 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

1 à 4 background en fonction du mode vidéo.

$0000
$0800
$1000
$1800
$2000
$2800
$3000
$3800
$4000
$4800
$5000
$5800
$6000
$6800
$7000
$7800
$8000
$8800
$9000
$9800
$A000
$A800
$B000
$B800
$C000
$C800
$D000
$D800
$E000
$E800
$F000
$F800



* =============================== *
* Position du pointeur de tileset *
* =============================== *

en pattern de 8x8

2 bits par pixel = 16 octets (16318 octets le tileset $4000)
4 bits par pixel = 32 octets (32768 octets le tileset $8000)
8 bits par pixel = 64 octets.(65536 octets le tileset $FFFF)

1024 patterns (8*8 ou 16x16) par background.

$0000
$2000
$4000
$6000
$8000
$A000
$C000
$E000

......Mode 4 bpp ... 2bpp

$0000 => $8000 => $4000
$2000 => $A000 => $6000
$4000 => $C000 => $8000
$6000 => $E000 => $A000
$8000 => // => $C000
$A000 => // => $E000
$C000 => // => //
$E000 => // => //

========
* Vram *
========
Screen
------------------------------
$0000 = Sprites
$0800
$1000
$1800
$2000
$2800
$3000
$3800
------------------------------
$4000 = Sprite
$4800
$5000
$5800
$6000
$6800
$7000
$7800
-----------------------------
$8000 = Sprite
$8800
$9000
$9800
$A000
$A800
$B000
$B800
-----------------------------
$C000 = Sprites
$C800
$D000
$D800
$E000
$E800
$F000
$F800

Signer du nez ?

Index du forum > Généralités > Programmer la snes

repondre up

Suite à de nombreux abus, le post en invités a été désactivé. Veuillez vous inscrire si vous souhaitez participer à la conversation.

Haut de page

Merci de ne pas reproduire le contenu de ce site sans autorisation.
Contacter l'équipe - Mentions légales

Plan du site

Communauté: Accueil | Forum | Chat | Commentaires | News | Flash-news | Screen de la semaine | Sorties | Tests | Gaming-Live | Interviews | Galerie | OST | Blogs | Recherche
Apprendre: Visite guidée | RPG Maker 95 | RPG Maker 2003 | RPG Maker XP | RPG Maker VX | RPG Maker MV | Tutoriels | Guides | Making-of
Télécharger: Programmes | Scripts/Plugins | Ressources graphiques / sonores | Packs de ressources | Midis | Eléments séparés | Sprites
Jeux: Au hasard | Notre sélection | Sélection des membres | Tous les jeux | Jeux complets | Le cimetière | RPG Maker 95 | RPG Maker 2000 | RPG Maker 2003 | RPG Maker XP | RPG Maker VX | RPG Maker VX Ace | RPG Maker MV | Autres | Proposer
Ressources RPG Maker 2000/2003: Chipsets | Charsets | Panoramas | Backdrops | Facesets | Battle anims | Battle charsets | Monstres | Systems | Templates
Ressources RPG Maker XP: Tilesets | Autotiles | Characters | Battlers | Window skins | Icônes | Transitions | Fogs | Templates
Ressources RPG Maker VX: Tilesets | Charsets | Facesets | Systèmes
Ressources RPG Maker MV: Tilesets | Characters | Faces | Systèmes | Title | Battlebacks | Animations | SV/Ennemis
Archives: Palmarès | L'Annuaire | Livre d'or | Le Wiki | Divers