Re: developper sur SNES avec pvsneslib !

[Invité]

Sur mon github j'ai mis quelque code source de petit jeux en asm dispo ici :
PC-Engine : https://github.com/Kannagi/PC-Engine-Demo
Video : https://www.youtube.com/watch?v=ES2afCfDro8

Mega Drive : https://github.com/Kannagi/Mega-Mario-TD
Video: https://www.youtube.com/watch?v=o6gYP7F23Zk

(Le code est pas terrible vu que je l'ai fait en 2 jours XD )

Super-Nintendo Mode 7 : https://github.com/Kannagi/SNES-Mode7
Video: https://youtu.be/ik8gEbf3Et4?t=32
J'ai pas encore mis le code source en entier,  mais voilà a quoi ressemble le main :
https://paste.ofcode.org/yTfMKgA7DptEZZ9YdF6MdU

[Invité]

D'ailleurs j'avais adoré tes macros if/then etc ...

[hoit]

Hello,

Avez-vous déjà eu des soucis de compilation dans un projet pvsneslib suite à une réorganisation du code dans plusieurs fichiers ?

Je codais jusqu'à présent tout dans le même fichier (main.c) et comme ca devenait moins clair, j'ai voulu splitter ca dans d'autres fichiers.
Du coup j'ai fait :
- un header dans lequel je déclare toutes les variables et prototypes (avec #ifndef ... #define ... pour empecher l'inclusion multiple)
- un nouveau fichier .c qui fait appel au header déclare toutes les fonctions
- un appel au header dans le main.

A la compilation, j'obtiens :

keyboard.obj:keyboard.asm:2350: FIX_LABELS: Label "keyboardInterfaceCompiled" was defined more than once.
mn keyboardInterfaceCompiled islsl 0 islfl 0
"make": *** [/c/snesdev/snes-examples/.../test.sfc] Error 1

Pourtant, keyboardInterfaceCompiled n'est bien déclaré qu'une fois => dans le header :

unsigned char keyboardInterfaceCompiled[KB_SIZE_Y*2][KB_SIZE_X*2+1] = {};

[Tryphon]

Tu devrais nettoyer complètement tes répertoires de compilation, effacer tous les fichiers produits, et recompiler.

Ça me le fait très souvent quand je modifié un h avec SGDK.

[F.L]

Pour nettoyer tes fichiers, fais "make clean"

[hoit]

malheureusement ca ne vient pas de ça
J'imagine qu'il n'y a rien a toucher au niveau du makefile ?

Pour voir ce qui se passait, j'ai dégagé tout le code qui concernait l'erreur (keyboardInterfaceCompiled) et la compilation échoue sur la déclaration juste en dessous :

keyboard.obj:keyboard.asm:2071: FIX_LABELS: Label "keyboardCurrentSelectionX" was defined more than once.
mn keyboardCurrentSelectionX islsl 0 islfl 0
"make": *** [/c/snesdev/snes-examples/.../test.sfc] Error 1

J'ai poussé un peu plus loin en degagant presque tout le code. Il ne reste que ca :

Le header :

Code:

#ifndef KEYBOARDH
#define KEYBOARDH

 #include <snes.h>

 unsigned char keyboardInterfaceCompiled[1][1] = {};
 void init();

#endif

Le fichier source :

Code:

#include "keyboard.h"

void init()
{
}


Le main :

Code:

#include "keyboard.h"

int main(void)
{
 consoleInit();
 setMode(BG_MODE1,0);
 bgSetDisable(1);
 bgSetDisable(2);
 setScreenOn();
 
 while(true)
 {
 WaitForVBlank();
 }
 
 return 0;
}

Du coup, j'ai essayé avec un pointeur et un nom plus court mais ca persiste toujours.

Si pas d'autre piste, je referai un gros fichier dégueu !

Merci

[Invité]

Le problème c'est qu'AlekMaul ne vient plus sur Gamopat hélas ...
Le mieux serait de le contacter via FB ou sur sa chaine YT :
https://www.youtube.com/user/alekmaul2009

[F.L]

Si alekmaul ne vient plus sur gamopat, il faut remercier metallik qui n'arretait pas de cracher sur son jeu lors de sa sortie..... 
Et personne ne l'a defendu.... c'etait navrant

[Tryphon]

Le header :

Code:

#ifndef KEYBOARDH
#define KEYBOARDH

 #include <snes.h>

 unsigned char keyboardInterfaceCompiled[1][1] = {};
 void init();

#endif

Tu initialise ton tableau dans le header, c'est peut-être ça. Écris plutôt :

Code:

unsigned char keyboardInterfaceCompiled[][];

Puis dans le main :

Code:

unsigned char keyboardInterfaceCompiled[1][1] = {1, 2, 3, 4}; // il faut 4 valeurs pour initialiser ce tableau 2x2

[Invité]

Je déconseille en général les tableaux à 2 dimensions et encore plus sur SNES
De plus pour un tableau  [1][1] , c'est un peu inutile

Et personne ne l'a defendu.... c'etait navrant

Je ne suis pas au courant de cette histoire , néanmoins je pense qu'il est assez grand pour se défendre tout seul comme un grand !

[Tryphon]

Je déconseille en général les tableaux à 2 dimensions et encore plus sur SNES

Pareil (même sur MD).

Mais si tu le fais, prends bien garde que la première coordonnée soit une puissance de 2 si tu veux pas que le compilo génère une multiplication lors d'un accès à un élément !

Quitte à remplir le tableau par des O !

[drludos]

Je déconseille en général les tableaux à 2 dimensions et encore plus sur SNES

Pareil (même sur MD).

Mais si tu le fais, prends bien garde que la première coordonnée soit une puissance de 2 si tu veux pas que le compilo génère une multiplication lors d'un accès à un élément !

Quitte à remplir le tableau par des O !

Utilisant actuellement un gros tableau deux dimensions sur GB (pour gérer un map dynamique), vous m'apprenez quelque chose d'hyper utile !

Pourquoi ne faut-il avoir que des coordonnées en puissance de 2 pour la première dimension ?

(pour info, j'utilise un tableau 2 dimensions de 20x18, pour pouvoir garder en mémoire toutes les tiles/infos de collisions sur un écran de 160*144)

@hoit: comme toi, j'avais essayé sans succès de couper mon code en plusieurs fichiers une fois qu'il était bien "trapu". Je sais plus les erreurs de compilo que j'avais, mais il me semble que c'était les même que toi. Au final, j'ai finit mon projet en un seul fichier. Même si je ne sais pas comment, c'est possible d'avoir plusieurs fichiers C séparés même avec tcc-816 - Alekmaul l'a fait pour Syndey Hunter (cf quelques pages précédentes sur ce topic, à un moment Alekmaul montre son architecture du projet avec pleins de fichiers C). Je crois qu'en fait il faut commencer directement avec un code organisé en plusieurs fichier, car le redécouper par la suite, c'est galère.

[Tryphon]

Quand tu définis un tableau 20x18 :

Code:

int tableau[20][18];

si tu veux accéder à l'élément en (x, y) :

Code:

tableau[x][y];

le compilateur génère le code équivalant à :

Code:

adresse_de_tableau + 20*y + x

Or une multiplication prend beaucoup de temps sur un CPU 8 ou 16 bits. Sauf les multiplications par des puissances de 2, car un elles équivalent à des décalages vers la gauche. Par exemple :

Code:

x << 1; // équivaut à x*2
x << 2; // équivaut à x*4
x << 3; // équivaut à x*8
x << n; // équivaut à x*(2^n)

Bon, c'est pas si horrible, parce que x*20 est compilé sous la forme :

Code:

((x << 2) + x) << 2

mais c'est un poil plus long quand même...

Sinon, t'as essayé de que je t'ai dit ? (ne pas définir le contenu du tableau dans le .h, ni même la dimension)

[drludos]

Merci Tryphon pour ces explications détaillées!

Je vais voir comment prendre cela en compte, d'autant plus que le CPU de la GB ne sais pas multiplier / diviser en hardware, et que les cycles CPU sont encore plus précieux sur GB que sur SNES :)

Après, le fait que le compilo traduise ça en deux bitshift + une addition c'est déjà super. Par contre, ça dépend du compilateur je pense, et dans le cas de tcc-816, je ne suis pas sur qu'il fasse ce genre d'optimisation tout seul (si on pouvait coder sur SNES avec GCC ou même SDCC, on aurait moins de bug et un code plus rapide)

[Hpman]

Une technique consiste à utiliser un tableu à une dimension [20*18] puis stocker l'adresse de début de chaque ligne dans un second tableau.

Ensuite on calcule l'adresse des données à accéder avec l'adresse de la ligne + n° colonne.

[Invité]

Une technique consiste à utiliser un tableu à une dilmension [20*18] puis stocker l'adresse de début de chaque ligne dans un second tableau.

Ensuite on calcule l'adresse des données à accéder avec l'adresse de la ligne + n° colonne.

Merci pour le mal de crâne avant d'aller dormir

[hoit]

"De plus pour un tableau  [1][1] , c'est un peu inutile" 

C'est uniquement pour l'exemple qu'il est initialisé à cette taille, le but était d'avoir un code minimal :)

En réalité, le tableau est déclaré comme ceci : unsigned char keyboardInterfaceCompiled[KB_SIZE_Y*2][KB_SIZE_X*2+1] = {}; car je réutilise les constantes à un tas d'autres endroits dans le code.


Du coup je viens d'apprendre quelque chose avec la taille des tableaux. Je n'ai pas utilisé de pointeur pour éviter de complexifier inutilement le code mais je regarderai pour optimiser tout cela par la suite. Pour le moment je préfère me concentrer sur les autres problèmes que j'ai. 


J'ai essayé de supprimer l'initialisation du header, d'en faire un pointeur, malheureusement ca ne change rien.


Je vais repartir sur la solution du gros fichier ...


merci pour vos conseils :)

[F.L]

Plus je vous lit, et plus j'aime le basic 

[hoit]

Hello,

Pour le problème d'organisation du code en plusieurs fichiers, j'ai posé la question sur nesdev et c'est une erreur de conception :

do not declare global variables in .h files. Declare the variable within your "main" file, then use extern in other places (either .c files, or an .h file that .c files include).

il faut déclarer les variables dans le fichier .c (si elle est globale, main.c par exemple) et utiliser le mot clé "extern" dans les autres endroits où on veut s'en servir.
Voici le lien du topic si ca vous intéresse :

http://forums.nesdev.com/viewtopic.php?f=12&t=18020#p228709

a+

[drludos]

Merci beaucoup Hoit pour cette info !

En relisant ton post et les réponses sur NESdev, j'avais exactement le même problème. Le noeud du problème vient apparemment du fait que le compilateur/linker ne respecte pas les directives #ifndef pour éviter de déclarer deux fois une variable.

Merci pour la solution en tout cas, ça me servira pour mon prochain projet :) !

[hoit]

Hello,

Par curiosité, est-ce qu'il existe une autre solution que d'attribuer a différents sprites la même image (avec oamSet) si je veux afficher exactement le même sprite (même palette) à différentes positions sur l'écran ?

Merci :)

[drludos]

Non, sauf erreur de ma part c'est la seule solution possible.
Mais bon avec 128 sprites maximum dans l'OAM, tu est large normalement :).

Quel effet / problème cherches-tu a résoudre en particulier ?
(des fois que cela inspire une solution alternative).

[hoit]

Je cherche à dessiner un rectangle de taille totalement variable, j'ai donc une image composée de 8 éléments :
- les 4 angles
- les 4 côtés (ou arêtes !)

En fonction de la largeur et la hauteur de rectangle, j'ai besoin de dupliquer les côtés.
On pourrait comparer cela à une boite de dialogue dans laquelle apparait le texte :)

Ce sont des tiles de 8X8 donc ca ira vite prendre pas mal de sprites, je vais peut être faire une plus grosse image qui sera affichée sur un background mais avec une taille fixe.

Au cas où vous avez des remarques, ça m'intéresse !

[hoit]

J'en profite également pour poser quelques questions sur les backgrounds car il y a visiblement d'autres contraintes que je ne maitrise pas.

J'ai besoin d'afficher une image de la taille de mon écran et de la masquer, j'ai voulu gérer ca avec un background.
Je constate que si setMode(BG_MODE1,0); est appelé avant de charger le background, impossible de l'afficher a l'écran.

Je voulais coller le background a la suite de mes images. Du coup je maintiens dans une variable l'adresse du dernier chargement :
u16 spriteAdress = 0x2000;
// .....
spriteAdress+=(&frame_end-&frame)/2;

Si dans bgInitTileSet, le dernier paramètre qui correspond à l'adresse utilise spriteAdress, le résultat chargé a l'écran est "mixé" avec d'autres images. Par contre si je le met en dur à 0x5000, ca passe. Une idée de la raison ?

Merci

[drludos]

Je cherche à dessiner un rectangle de taille totalement variable, j'ai donc une image composée de 8 éléments :
- les 4 angles
- les 4 côtés (ou arêtes !)

En fonction de la largeur et la hauteur de rectangle, j'ai besoin de dupliquer les côtés.
On pourrait comparer cela à une boite de dialogue dans laquelle apparait le texte :)

Ce sont des tiles de 8X8 donc ca ira vite prendre pas mal de sprites, je vais peut être faire une plus grosse image qui sera affichée sur un background mais avec une taille fixe.

Au cas où vous avez des remarques, ça m'intéresse !

Je comprend en effet que tu soit à court de sprite. Pour afficher ce gerne de boite de dialogue, le mieux est d'utiliser un Background et non pas les sprites. Du coup tu va avoir seulement 8 tiles (4 angles / 4 cotés) que tu va répéter à loisir.

A faire en dur (taille fixe), c'est simple, car gfx2snes te génére tes tiles data et ta tilemap.
Pour une taille dynamique, ça sera un peu plus compliqué. Je pense qu'il faut que tu convertisses d'abord tes graphismes en dessinant une petite boite complète (3x3 donc), et les convertisse avec gfx2snes.

Ensuite, dans ton code, il faudra que tu modifie manuellement la mapdata en VRAM pour "dupliquer" ou "supprimer" des "lignes" et "colonnes" de ta boite de dialogue pour lui donner la taille désirée. J'ai jamais tenté de faire cela pour l'instant, mais je pense que l'exemple supermarioland de PVSNESlib devrait pouvoir te servir de base, car je crois qu'Alekmaul manipule directement la tilemap du décor pour gérer le scrolling (il ajoute ou supprime des "colonnes" de BG sur la tilemap en VRAM à partir de la tilemap source en ROM pour qu'elle s'affichent à l'écran).

[drludos]

J'en profite également pour poser quelques questions sur les backgrounds car il y a visiblement d'autres contraintes que je ne maitrise pas.

J'ai besoin d'afficher une image de la taille de mon écran et de la masquer, j'ai voulu gérer ca avec un background.
Je constate que si setMode(BG_MODE1,0); est appelé avant de charger le background, impossible de l'afficher a l'écran.

Je voulais coller le background a la suite de mes images. Du coup je maintiens dans une variable l'adresse du dernier chargement :
u16 spriteAdress = 0x2000;
// .....
spriteAdress+=(&frame_end-&frame)/2;

Si dans bgInitTileSet, le dernier paramètre qui correspond à l'adresse utilise spriteAdress, le résultat chargé a l'écran est "mixé" avec d'autres images. Par contre si je le met en dur à 0x5000, ca passe. Une idée de la raison ?

Merci

Alors là tu me poses une colle.

Est-ce que ce n'est pas tout simplement lié à un dépassement de VBLANK? Pour info, sur une vraie console ou un émulateur fiable (snes9x ou bsnes / higan), tu ne peux envoyer des données dans la VRAM que pendant le VBLANK. De mémoire, cela correspond à environ 6ko de données (en 60hz, le plus contraignant à ce niveau).
Or, si tu charges quelques sprites plus un décor, tu risque d'exploser rapidement ton budget.
Avec une image de fond (tiles + mapdata), tu doit être pas loin de 4-5ko déjà.

Pour éviter ce problème, il faut :
-soit faire un "WaitForVBlank();" entre chaque envoie de 6ko de données dans la VRAM
-soit, si tu veux envoyer beaucoup de données d'un coup (chargement d'un décor, des sprites, etc. d'un nouveau niveau), tu peux faire un "forced blank", qui désactive l'affichage pendant quelque temps pour que tu ais un accès illimité à la VRAM. Pour le faire, c'est simple, tu appelle setBrightness(0); pour mettre l'écran au noir complet, ce qui a pour effet de te laisser un accès libre à la VRAM. Une fois tes données chargées, penses à faire setBrightness(15); pour réactiver l'affichage.

Après, ce n'est peut-être pas la source de ton pb, mais moi je l'ai rencontré très rapidement en envoyant quelques sprites + 1 décor en même temps. Les infos qui n'étaient pas envoyées à la VRAM dans mon cas c'était la palette, ce qui fait que mon décor était tout noir...

------------

Sinon, ça peut aussi être liée à l'adresse que tu utilises dans la VRAM. Coller le décor à la suite des sprites peu poser problème, car il me semble qu'il y a une histoire d'alignement mémoire à respecter pour les tiledata. Si ça marche quand tu forces 0x5000 mais pas quand tu le met à la suite des sprites (ce qui doit donner un adresse "pas ronde" style 0x4482) ça peut être tout simplement ça. Mais je t'avoue pas être sur de moi à 100% sur ce point.

Pour info, dans mon jeu je charge les backgrounds entre 0x0000 et 0x4000 (style 0x2000, 0x1000, etc.), et les sprites à partir de 0x4000 (inclus).

[hoit]

drludos, merci pour toutes ces infos.

Je n'ai plus le temps de faire les tests ce soir mais je regarderai cela plus en détail dans les jours qui suivent et je reviendrai surement en parler :)

[hoit]

Hello,

J’ai une nouvelle question :) ca concerne la gestion de sauvegarde des données avec pvsneslib. 

Je pensais que l’exemple de scoring permettait d’enregistrer des scores dans une sauvegarde mais ca n’a pas l’air d'être le cas.
https://github.com/alekmaul/pvsneslib/tree/master/snes-examples/scoring

Du coup, je me demande quel est le but de cet exemple ?
J’ai l’impression que la sauvegarde n’est pas implémentée, savez vous comment je peux faire pour enregistrer des chaines de caractères en ram et les reutiliser au chargement de la rom?

Merci !

[ichigobankai]

C'est plutot SRAM qu'il faut regarder

[Invité]

Il ya rien de spécial pour lire ou écrire a la SRAM , un pointeur sur l'adresse 0x700000 devrai suffire. (mais je sais pas s'il accepte les adresses de 24 bits le compilo ).

[drludos]

Je confirme les deux réponses au dessus, c'est cet exemple qu'il te faut utiliser comme base :
https://github.com/alekmaul/pvsneslib/tree/master/snes-examples/sram

La SRAM est une section de la RAM qui ne disparait jamais, car elle est alimentée par une pile. C'est comme ça que tous les jeux sur cartouches gèrent les sauvegardes : il suffit d'écrire des valeurs dans la partie SRAM de la RAM, et elle seront encore là même après avoir éteint la console.

Pour l'exemple scoring, je crois qu'il sert avant tout à montrer le module d'affichage de score à l'écran (y compris l'addition de gros nombres). Je savais pas qu'il y avait un tel module dans la lib, ça peut servir :).