Monos - posté le 08/01/2023 à 08:20:50. (57322 messages postés)
Joyeux anniversaire à Karasoa. Notre Boulanger qui nous manque aussi.
De son petit nom Vincent. (tim pour son second prénom).
Il aimait beaucoup lire et possède une petite 40en de message sur le forum.
Il développé Survival Island en 2013. Seul tropic de jeu qu'il a présenté.
Lien Je sais pas si il a fini son jeu depuis mais joyeux anniversaire à lui.
Monos - posté le 08/01/2023 à 08:17:39. (57322 messages postés)
Jolie tout ça.
Hate d'intégré les nouveaux perso et reprogrammer les autotiles pour les murs.
Mais avant de faire tout ça faut que je regarde ce qui met en PLS la snes quand il y a plus de deux monstres à l'écran.
Je viens de sortir d'un support avec mbh21 sur le discord snes alek.
C'est moi qui commence à faire du support sur la snes
Monos - posté le 07/01/2023 à 10:17:16. (57322 messages postés)
Citation:
Intel HUD 770
Cela doit être la puce graphique intégré a la carte mère/processeur.
A mon avis au dire de ce que tu dis, la carte graphique est soit morte voir peut être pas correctement branché ? Ouvre le pc et regarde un peu ses entrailles.
Monos - posté le 07/01/2023 à 06:38:35. (57322 messages postés)
Joyeux anniversaire Elder.
Ah ce bon elder. Souvenez vous de son unique message dans le topic Valor Adventures :
Citation:
Exactement le même problème j'ai eu la présentation et paf il y a l'écran de fin
C'était en 2011.
Ah c'était beau. Il me manque celui la. C'était un peu notre messi. Elder avec le sympathique d'oniromancie, on te souhaite un joyeux anniversaire pour tes 111 abs
Monos - posté le 06/01/2023 à 21:27:51. (57322 messages postés)
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.
Monos - posté le 06/01/2023 à 15:45:36. (57322 messages postés)
La snes me plais beaucoup en tant que machine. J'ai vraiment envie de m'y pencher à fond.
Si je veux un bon jeu pour sinon je laisserais comme ça le game play alors que je vais recoder ce qui va pas.
Pour rots on verra. Cela peut être cool oui faut juste aussi de mon coté je me penche sur la question de la musique sur snes . C'est un peu chientos par apport à d'autre console.
Monos - posté le 06/01/2023 à 06:39:52. (57322 messages postés)
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.
Monos - posté le 06/01/2023 à 04:49:44. (57322 messages postés)
Alors si tout rentre j'ai besoin du windowskin en parchemin, sur ce windowskin tu garde les "cadres" les mot HP/ATT mais tu ne place pas les valeurs.
Au niveau des clefs tu retire les clefs mais tu gardes le cadres, et le mot keys.
Comme toujours en BMP. Si tu pouvais aussi indexer le fichier et que la premier couleurs de l'index de couleur soit en "rose" ça peut être cool ça te fera un exercice xd.
Je n'ai pas intégré le press start je vais faire ça ce week end.
Au niveau graphismes, je vais faire une "pause" après reflexion j'ai beaucoup de truc à reprogrammer comme la gestion des monstres et des collisions qui fout en PLS la snes.
(Oué je suis toujours en apprentissage de codage xd)
Tu sais te servir de filzella pour envoyer des fichier sur un serveur net ? SI oui je regarderais pour t'ouvrir un espace ftp pour qu'ont puisse échanger plus facilement les fichiers.
Je suis en train de réfléchir pour un vrais portage sur Megadrive. (Ce n'est pas pour tout de suite, et c'est en fonction de vous deux gros tonton et Coda)
Le code en lui même sera à 80% le même mais au niveau graphismes ça sera un autre challenge pour adapter ou re adapter ce que vous faite pour la Megadrive.
J'annonce la limitation graphique. Nuancier de 512 couleurs. Mais la ou ça risque de puer dans le slip !
On a le droit à 4 palettes de 16 (15 en réalité comme d'habitude car la 1er est toujours une transparente) en même temps qui sont partagées par les sprites et background.(tiles).
A réfléchir si vous voulez aussi d'être de l'aventure peut être pour Septembre si tous va bien...
LA fini ma semaine en réalisant des tutos pour le pvsneslib. Ce week end je reprend la prog du jeu au niveau moteur. ET faut aussi s'occupé des autotiles pour gros tonton et refaire ça correctement. Je n'aime pas jeter du code mais c'est la vie d'un programmeur
Petit coin technique
Faut aussi que je passe beaucoup de mes getter/setter en variable globale.
En gros pour mieux comprendre pourquoi :
En C, une variable à une porté. Quand je déclare une variable dans un fonction, elle vie que dans cette fonction.
Quand je la déclare dans un fichier c au début elle vie dans ce fichier mais elle peut être facilement appeler dans d'autre fichier du programme. C'est ce qu'on appelle une variable global.
En programmation souvent on dit un truc genre (bouh c'est pas bien les variables globales !!!)
Alors pour parer à ça et pour être "propre" dans son code dans les pages ou se trouve ce genre de variable globale on crée deux fonctions.
Une fonction qui permet de modifier la valeur de cette variable et qui peut être utilisé ou on le souhaite. (Exemple je crée ma variable HP dans une fichier, je créer un set_hp(value) pour faire simple)
et un Getter pour récupéré la valeur de la variable ailleur. (un get_hp();) et la fonction me renvois une valeur.
C'est propre, c'est ce qu'il faut faire... sur PC. Car on a la puissance de faire ça.
Sur des systems retro, ba a chaque fois on fait appelle à une fonction on mange des cycles. Donc du temps machine. (Je crois on appelle ça un callback mais je peux me tromper), c'est beaucoup plus rapide d'aller lire dans la Ram ma valeur que de passer par une étape intermédiaire. Surtout que le proco de la snes n'est pas vraiment un foudre de guerre.
Donc j'ai beaucoup de boulot pour réorganiser tout ça. Le pied !!!
Monos - posté le 04/01/2023 à 17:31:07. (57322 messages postés)
Les étoiles c'est cool.
Citation:
Je ne partage pas encore en .bmp parce que je veux savoir si je peux modifier un peu plus les lettres pour les rendres plus lisibles.
Tu peux on peux aussi modifier les couleurs pour avoir plusieurs palettes. J'ai juste les paterne à mémoriser une seul fois dans la cartouche, et justeà changer les palettes de couleurs quand j'ai besoin d'un fond claire ou obscure par exemple. Cela marche aussi.
Monos - posté le 04/01/2023 à 04:08:38. (57322 messages postés)
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 !
Monos - posté le 04/01/2023 à 03:57:28. (57322 messages postés)
Après Fevrier je vrais reprogrammer la routine d'autotile pour que ça marche mieux. On va se calquer sur les autotiles du logiciel rpg maker 2003, cela devrait le faire.
J'ai plein de routine à reprogrammer...
Monos - posté le 03/01/2023 à 17:31:53. (57322 messages postés)
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
Monos - posté le 03/01/2023 à 06:50:42. (57322 messages postés)
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
Monos - posté le 03/01/2023 à 05:52:19. (57322 messages postés)
Citation:
Honnêtement, je pense surtout que ton ami devrait passer sur le sujet de temps en temps. C'est son jeu après tout. Si on ajoute des trucs avec lesquels il est pas d'accord, c'est pas super comme portage. À sa place, j'aimerais avoir le dernier mot sur le résultat final.
J'ai une libre adaptation pour ça que c'est marqué lagacy
Citation:
De un, des icônes chiffrés qui représentent les forces et les faiblesses de chacun des quatre personnages (j'imgaine qu'ils en ont). Un peu comme ça:
Oui, ça c'est sympathique. Je te ferrais ce soir le tableau des carac des 4 persos.
Citation:
De deux, un cours paragraphe qui présente le personnage:
''Raoul le guerrier, bla bla bla''
C'est prévus !
Cool le Game Over
Bon j'intègre ton écran titre.
Edit :
Le press start il est en tiles...
Donc une case de 8x8 par lettre.
La cadre est trop petit en largeur.
J'ai la palette de couleur à changer aussi pour le press start.
Monos - posté le 02/01/2023 à 18:57:44. (57322 messages postés)
Cool Gros Tonton. On attaqueras cette partie bientôt. Je vais reprendre la programmation du game play.
Citation:
Qu'est-ce que tu comptes ajouter à part les portraits? Parce que là, on a encore le problème de vide. Si tu avais une colonne de texte sous chaque portrait pour expliquer ses charactéristiques?
Je te laisse champs libre de réfléchir à la question je vais m'adapter.
Ton ecran titre roxe du rocky ! Je vais intégré ça demain matin.
Citation:
on n'a pas à faire le plus rapidement possible à cause de l'argent.
Nop même si j'ai un petit calendrier, ce n'est pas grave si on le depasse.
Donc voila.
Citation:
L'écran Game Over maintenant. J'ai décidé d'y aller avec le concept du livre (fin de livre). J'ai déjà quelques idées.
Cool a petit truc que j'ai pas encore intégré, prévois une place pour indiquer le nombre de pièce d'or que le joueur à amasser.
Nemau : J'ai pas eu ta blague tout de suite :
Mais elle est jolie.
Monos - posté le 01/01/2023 à 18:39:32. (57322 messages postés)
C'est beau
Cela claque ça maman !
Edit :
Citation:
Important: Je sais que tu je dois respecter le quadrillage 8x8, c'est du WIP
Tu apprends vite.
Le mot HP / ATT /DEF/ AMM / KEY tu n'es pas obligé de respecter le quadrillage vu que ça sera en "image"
J'ai juste besoin des valeur numerique que sa soit dans le quadrillage et le "youwin'
Les Clef ne doivent pas être sur l'image mais respecter les 16x16 quand même à l'affichage.
Bon travaille. J'ai intégré l'écran titre, ça claque sa maman.
Edit:
Rien à voir avec le jeu mais voici une premier video pour installer le pvsneslib (d'autre va arriver ce Lundi xd)
Monos - posté le 01/01/2023 à 04:55:48. (57322 messages postés)
Créacoda => Les icone tu peux les intégré dans le parchemain mais pas les clefs pour info. COmme ça tu peux centrer le truc.
N'oublie pas par contre que les valeurs numeriques sont en tiles de 8x8 donc doit être sur le quadrillage ! Donc arrange toi que ça marche bien et que je me retroupe pas avec un chiffre en deux culs de chaise !
Et oui, faire des graphismes pour des vrais machines retro, c'est beaucoup de contrainte. Et encore les machines laisse un peu de marge.
Sur 8 bits il y a beaucoup de chose qui ne peuvent pas être réalisé à cause du manque de mémoire en VRAM très certainement et en fonction aussi des contraintes de la machine.
Sur un Commodore 64 (peut être que je ferais un portage du jeu sur c64), je ne peux pas utilisé les graphismes de Codation, pour cause ba c'est 1 couleurs par tiles de 8x8. (Plus la couleurs du fond) et j'ai le droit à 256 tiles de 8x8 en même temps. La tilemap n'a 1 seul octet par case pour piocher dans sa bank de tile. (Et un 2em tableau pour la couleur à afficher sur tile (4 bits sur 8, les 4 autres bits ne servent à rien...)
Sur Nes c'est 256 tiles aussi pour le background. Et heum dans les cartouches basic, c'est fixe ! Le paterne sont sur une puce directement relié au PPU. La CHR_Rom. (256 tiles pour les background, 256 tiles pour les sprites).
Bon nintendo à créer d'autre type de cartouche pour échanger les planches dans un jeu. (Les mappeur avec le system de Banck Swithcin) mais on reste quand même limité à 256 tiles de 8x8 à l'instant T ! Au niveau des couleurs, pour faire simple, la nes possède 4 palettes de 4 couleurs pour la background. (3 exploitables car la 1er couleur de chaque palette est une couleur transparente). Et dans chaque zone de 16x16px (en gros par groupe de 2x2 tiles) on associe une palette de couleurs. (Pour faire simple c'est un tile RM 2003 est limité à 3 couleurs. Est on a le droite à 12 couleurs à l'instant T pour le background je fais simple). Si vous regardez un screen nes il n'y pas beaucoup de couleur à l'instant T. Il y a 4 autre palettes de 4couleurs (toujours pareil 3 + transparente) pour les sprites. DOnc hors bidouille, 8*3+couleurs du background 25 couleurs différentes à l'affichage...
La Master system monte vers les 512 tuiles qui peuvent être utilisé par les sprites ET le background. Au niveau des couleurs affichable on est juste un peu plus haut que la nes avec deux palettes de 16 couleurs (1er est toujours transparente donc avec le fond ça fait 31 couleurs.
La SNES explose bien tout ça avec ses 16 palettes de 15 couleurs...
Et le nombre de tiles exploitable ba c'est 1024 par tilemap limité par la VRAM aussi.
Je ne sais pas si on passe en mode "nes" c.a.d en mode 0 avec les background, si on peux caser tout les tiles au maximum. Faut aussi de la place pour les tiles des sprites. (Si on veux pousser à fond), plus des écran.
Enfin voila. Programmer sur machine retro (peux importe) c'est oeuvrer avec des limitations plus ou moins importante et connaitre aussi la machine. A l'heure actuel plus personne ne connais vraiment sa machine ! Quand on programme pour un PC des jeux indé / amateur avec monogame ou chez pas quoi, on se fiche un peu de savoir si le processeur va tenir, si il y a assés de vram, si j'ai du temps dans le Vblanck pour balancer des infos en Vram...
Je crois que c'est pour ça que j'ai vraiment aimé ce Rpg Maker VX ! Cette limitation du tileset changé la donne. (Bon on est d'accord quand même qu'il ya des truc à se tirer la tête sur ce log) mais j'avais prouvé que graphiquement FF4 de la snes pouvais rentrer dans VX !(A le salop ! Bref voila c'est le petit coin technique de 1er janvier...