Re: developper sur SNES avec pvsneslib !

[Invité]

OK, dispo ici, vous avez aussi le changelog

https://github.com/alekmaul/pvsneslib/wiki/Download

Et j'ai commencé un wiki comme celui de Stef pour SGDK (y'a pas de raison ^^) https://github.com/alekmaul/pvsneslib/wiki

Si quelqu'un veut aider, je suis plus que plus que preneur !

[F.L]

ah, cool, bonne nouvelle! j'espere m'y remettre un de ces quatres !!!!

[Stef]

@alekmaule> J'espère que tu feras mieux que le mien qui ne contient pas grand chose mais qui en plus est complément dépassé (et donc à tendance à induire en erreur plus qu'autre chose ^^)

[Invité]

Il est normalement à jour, car je n'ai pas trop fait d'incompatibilité dans les évolutions de la lib.

[uran]

@alekmaule> J'espère que tu feras mieux que le mien qui ne contient pas grand chose mais qui en plus est complément dépassé (et donc à tendance à induire en erreur plus qu'autre chose ^^)

Ca expliquerait pas mal de chose ...

[Invité]

Comme indiqué, je recherche des personnes pour m'aider à faire évoluer le kit et voir, si on est assez motivé, refaire les outils en JAVA pour permettre une meilleur portabilité, à bon entendeur :) !!
J'ai déjà porté quelques pages de l'ancien WIKI sur github, dispo ici (comme python et msys ) : https://github.com/alekmaul/pvsneslib/wiki

[drludos]

Woaw, super pour la nouvelle version Alekmaul! Merci à toi pour cette MAJ ! :)

Du coup, vu le changelog, tu as aussi fixé les bugs reportés précédemment dans ce fil ?

(le fait qu'il était impossible de donner une position x < 0 et surtout le fait que la dernière version de la lib était non fonctionnelle (examples qui donnent un écran noir), et qu'il fallait repartir sur une version plus ancienne)

Pour le Wiki, je veux bien t'aider dans la limites de mes connaissances de "débutant qui apprend". Par exemple, je veux bien essayer de rédiger une page sur le son, maintenant que je pense avoir bien en tête le fonctionnement de base de SNESMod.

Comment faire pour contribuer au Wiki alors ?

[Invité]

Je pense qu'il faut juste t'inscrire sur github et tu dois avoir les droits (c'est open bar ).
Pour les écrans noir, oui c'est corrigé, le x<0, j'avais zappé, je vais regarder.

[Stef]

@alekmaule> J'espère que tu feras mieux que le mien qui ne contient pas grand chose mais qui en plus est complément dépassé (et donc à tendance à induire en erreur plus qu'autre chose ^^)

Ca expliquerait pas mal de chose ...

Ah ça oui, les tutoriaux wiki sont SGDK sont obsolètes, j'ai pas mis un warning dessus ? ^^

[uran]

Si si, mais tu sais dans le feu de l'action, on oublie de lire certaines lignes ...

[hoit]

Hello,
Je profite que ce topic soit remonté pour reparler de mon problème de chargement de 2 images :
Je n'arrive pas à charger et afficher 2 images différentes à l'écran. A chaque fois, c'est 2 fois la 1ère image qui est visible (celle chargé avec l'appel à oamInitGfxSet)

J'ai préparé un bout de code minimal pour montrer le cas :
https://www.petit-fichier.fr/2018/02/12/minimal-code/

ou voici les quelques lignes concernées :

Code:

oamInitGfxSet(&image1, (&image1_end-&image1), &image1pal, (&image1pal_end-&image1pal), 0, 0x4000, OBJ_SIZE32);
 oamSet(0,  10, 100, 0, 0, 0, 0, 0);
 oamSetEx(0, OBJ_SMALL, OBJ_SHOW);
 oamSetVisible(0, OBJ_SHOW);

 //oamInitGfxSet(&image2, (&image2_end-&image2), &image2pal, (&image2pal_end-&image2pal), 0, 0x6000, OBJ_SIZE32);
 dmaCopyVram(&image2, 0x6000,(&image2_end-&image2));
 dmaCopyCGram(&image2pal, 128+0*16, (&image1pal_end-&image1pal));
 //REG_OBSEL = OBJ_SIZE32 | (0x6000 >> 13);
 oamSet(4,  132, 132, 0, 0, 0, 0, 0);
 oamSetEx(4, OBJ_SMALL, OBJ_SHOW);
 oamSetVisible(4, OBJ_SHOW);

J'ai volontairement mis les images sur 2 adresses éloignées, mon but étant ensuite de les mettre les unes a la suite des autres.

Avez-vous une piste ?

Merci d'avance

[drludos]

Hello Hoit,

Sauf erreur de ma part, ton problème est simplement lié au fait que tu demandes à tes deux sprites d'afficher l'image "0" de la VRAM des sprites, donc effectivement celle que tu as chargée avec oamInitGfxSet()

Dans oamSet(), l'avant-dernier paramètre, "offset", correspond à l'index de l'image (tile de sprite) à afficher sur ce sprite. J'imagine que tu as des sprites de 16x16 en small et de 32x32 en Large, donc essaie de remplacer la ligne suivante:

Code:

 oamSet(4,  132, 132, 0, 0, 0, 0, 0);

Par celle-ci:

Code:

 oamSet(4,  132, 132, 0, 0, 0, 512, 0);

Comme tu charge tes données via oamInitGfxSet() dans la VRAM à l'adresse 0x4000, cela veut dire que les tiles des sprites seront stockés à partir de 0x4000 dans la VRAM. Donc, si tu affiche la tile d'index "0", cela veut dire que la SNES va aller afficher la tile de sprite stocké dans sa VRAM à 0X4000. Pour être plus précis, la tile "0" sera stockée à 0x4000, la tile "1" sera stockée à 0x4010, la tile "2" sera stockée à 0x4020, etc.

Sachant que toi ta seconde tile est stockée en 0x6000, comment trouver son "numéro de tile" correspondant ?

C'est "simple": tu peux virer le dernier "0" car comme tu peux voir il n'entre pas en ligne de compte dans cet adressage. Sachant que la tuile "0" est à 0x400, et que la tuile X est à 0x600, on en déduit que X = 0x600-0x400 = 0x200. Mais, oamSet() n'attend pas une valeur hexadécimale, mais décimale. Il faut donc convertir 0x200 en base 10, ce qui nous fait 512 (merci la calculette windows :p).

J'avoue avoir parfois du mal avec toutes ces conversions d'adresse, et me planter aussi régulièrement dans les numéro de tiles. Donc si tu veux pouvoir trouver cela d'une manière un poil plus "graphique", tu peux aussi lancer ta ROM avec l'émulateur NoSNS, et utiliser le VRAM viewer (onglet "Tiles 4bpp") pour voir le contenu de ta VRAM. Tu trouves visuellement le "Tile No" du graphisme à afficher, tu enlève le "Tile No" de premier Sprite Tile que tu as chargé, et tu converti le tout en décimal.

Mais si mes calculs sont bons, ça devrait résoudre ton problème :)

[hoit]

Hello drludos,

Merci pour ta réponse, l'explication est très clair et effectivement, ça résoud bien le problème :)

Après avoir fait quelques tests, ca ne fonctionnait pas en mettant une image à 0x4000 et la seconde à 0x6000.
J'ai déplacé les images de façon a les avoir collé dans la vram :

Code:

oamInitGfxSet(&image1, (&image1_end-&image1), &image1pal, (&image1pal_end-&image1pal), 0, 0x4000, OBJ_SIZE32);
dmaCopyVram(&image2, 0x4000+(&image1_end-&image1)/2,(&image2_end-&image2));
// ... code ...
oamSet(4,  132, 132, 0, 0, 0, 64, 0);


et dans ce cas ci ça fonctionne bien.
Sans certitude, je dirais qu'il faut que les images soient les unes à la suite des autres en mémoire pour que ca fonctionne.

Je pense que ca vaudra le coup d'ajouter une petite section dans le tuto sur les sprites pour intégrer cela, ca aidera surement plein de monde.

A bientôt !

[Invité]

Sans certitude, je dirais qu'il faut que les images soient les unes à la suite des autres en mémoire pour que ca fonctionne.

Je pense que ca vaudra le coup d'ajouter une petite section dans le tuto sur les sprites pour intégrer cela, ca aidera surement plein de monde.

A bientôt !

Je suppose que c'est toi qui m'a aussi envoyé un mail sur le sujet

Concernant le tuto : https://github.com/alekmaul/pvsneslib/wiki/Sprites, dans la section Sprite in VRAM, on en parle. ET dans le dessin du dessus, on vois bien que les animations de ton sprite sont collées. Que veux tu de plus pour que cela soit plus clair ?

[hoit]

Je confirme, c'est bien moi qui t'ai renvoyé l'email hier soir pour que tu ne perdes pas de temps à me répondre alors que drludos l'avait fait ici.

Pour le tuto, toutes les informations sont dispo mais il m'a fallu l'explication précédente pour comprendre le fonctionnement.
L'affichage des sprites ne me semble pas évident et la rédaction du tuto pour qu'il soit compris de tous ne doit pas l'être non plus.

Peut-être que décomposer cela en plus d'étapes, en alternant par exemple quelque images de la VRAM de no$snes avec quelques lignes de code m'auraient aidé.

Après, ça dépend surtout si tu as rencontré d'autres personnes avec ce problème!

[hoit]

Hello,

Je fais des tests sur les background et j'ai pas mal de points qui restent flou.

Tout d'abord: Je n'ai pas bien saisi le rôle entre les tiles (bgInitTileSet) et les map (bgInitMapSet).
La map est-elle un conteneur de tiles et le tile une série de pixels (morceau de l'image coupé) en carrés de 8*8? Une de ces notions ne devrait-elle pas être interne à la lib ?

Que signifie le dernier paramètre de bgInitTileSet qui doit être aligné 4k?

Pour "économiser" en place, j'aimerais m'assurer d'avoir toujours les images/background les uns à la suite des autres en vram.
Sans me soucier de l'adresse du tileset pour l'instant, je constate que cette instruction fonctionne :

oamInitGfxSet(&image1, (&image1_end-&image1), &image1pal, (&image1pal_end-&image1pal), 0, 0x0000, OBJ_SIZE32);
bgInitMapSet(0, &map, (&map_end - &map),SC_32x32, 0x0000+(&image1_end-&image1)/2);

mais dans l'autre sens non (avec ou sans /2):

bgInitMapSet(0, &map, (&map_end - &map),SC_32x32, 0x0000);
oamInitGfxSet(&image1, (&image1_end-&image1), &image1pal, (&image1pal_end-&image1pal), 0, 0x0000+(&map_end - &map)/2, OBJ_SIZE32);

A quoi est-ce lié ?

Dans la même logique, je souhaite mettre mes images à l'adresse 0x0000 qui est utilisé par la lib pour le système de texte.
Je fais donc :
oamInitGfxSet(&textframe, (&textframe_end-&textframe), &textframepal, (&textframepal_end-&textframepal), 0, 0x0000+(&snesfont_end-&snesfont)/2, OBJ_SIZE8);

mais l'image n'apparait pas.

Merci d'avance pour votre aide

[drludos]

Tout d'abord: Je n'ai pas bien saisi le rôle entre les tiles (bgInitTileSet) et les map (bgInitMapSet).
La map est-elle un conteneur de tiles et le tile une série de pixels (morceau de l'image coupé) en carrés de 8*8? Une de ces notions ne devrait-elle pas être interne à la lib ?

Que signifie le dernier paramètre de bgInitTileSet qui doit être aligné 4k?


Pour "économiser" en place, j'aimerais m'assurer d'avoir toujours les images/background les uns à la suite des autres en vram.
Sans me soucier de l'adresse du tileset pour l'instant, je constate que cette instruction fonctionne :

oamInitGfxSet(&image1, (&image1_end-&image1), &image1pal, (&image1pal_end-&image1pal), 0, 0x0000, OBJ_SIZE32);
bgInitMapSet(0, &map, (&map_end - &map),SC_32x32, 0x0000+(&image1_end-&image1)/2);

mais dans l'autre sens non (avec ou sans /2):

bgInitMapSet(0, &map, (&map_end - &map),SC_32x32, 0x0000);
oamInitGfxSet(&image1, (&image1_end-&image1), &image1pal, (&image1pal_end-&image1pal), 0, 0x0000+(&map_end - &map)/2, OBJ_SIZE32);

A quoi est-ce lié ?

Comme tu le sais sans doute, sur SNES le "background" est composé de plusieurs "plans". Le nombre de plans et le nombre de couleurs de chaque plan varient selon le "mode" graphique de la SNES que tu utilise (le plus courant est le mode 1, avec deux plans de décors pouvant contenir 16 couleurs + un plan pouvant contenir 4 couleurs).

Le premier paramètre de bgInitTileSet() est tout simplement le numéro du "plan" pour lequel charger le tileset.

Ensuite, la différence entre les "tiles" et les "maps":
- Le tiles sont les "ressources graphique" : c'est la banque d'image qui compose ton plan: un ensemble de de donnée graphique de 8*8 pixels chacune. En ensemblant toutes ces "tiles", tu peux composer une image complète.
- Pour savoir où afficher chaque tile, la SNES (et toutes les consoles 8-16 bits d'ailleurs) vont utiliser une "tilemap" : littéralement une "carte", qui fait la taille de ton écran (ou plus si tu veux faire du scrolling) dans laquelle est notée chaque numéro de tile à afficher. Cela permet d'éviter de stocker des données graphiques pour chaque pixel de l'image, mais de gagner de la place (en ROM comme en RAM) et ne stockant qu'une seule fois les données graphiques répétées.

Par exemple. Tu veux faire un fond à moitié bleu et à moitié rouge sur ton écran. Sur un PC moderne, tu stockerai directement une grande image avec la couleur de chaque pixels, même si dans l'absolu tu n'a que deux couleurs différentes à l'écran.

Sur SNES, tu va plutot faire :
- Deux tiles : des "images" de 8x8 pixels. La tile 0 est un carré de 8x8 pixels bleu (■) et la tile 1 est un carré de 8x8 pixels rouge (■).
- Une "tilemap", dans laquelle tu va "placer" l'une ou l'autre de ces tiles sur tout l'écran :
[0][0][0][0][0][0][0][0][0][0][0][1][1][1][1][1][1][1][1][1][1][1]
[0][0][0][0][0][0][0][0][0][0][0][1][1][1][1][1][1][1][1][1][1][1]
[0][0][0][0][0][0][0][0][0][0][0][1][1][1][1][1][1][1][1][1][1][1]
[0][0][0][0][0][0][0][0][0][0][0][1][1][1][1][1][1][1][1][1][1][1]
[0][0][0][0][0][0][0][0][0][0][0][1][1][1][1][1][1][1][1][1][1][1]
[0][0][0][0][0][0][0][0][0][0][0][1][1][1][1][1][1][1][1][1][1][1]
[0][0][0][0][0][0][0][0][0][0][0][1][1][1][1][1][1][1][1][1][1][1]
[0][0][0][0][0][0][0][0][0][0][0][1][1][1][1][1][1][1][1][1][1][1]
[0][0][0][0][0][0][0][0][0][0][0][1][1][1][1][1][1][1][1][1][1][1]
[0][0][0][0][0][0][0][0][0][0][0][1][1][1][1][1][1][1][1][1][1][1]

La snes va lire cette "tilemap", dans l'ordre, et pour chaque "0" va afficher la tile 0 (carré bleu) à l'écran, et pour chaque "1" va afficher la tile 1 (carré rouge) à l'écran. Je schématise, mais voila en gros le principe.
■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■

Grâce à PVSNESLib, toi tu n'as qu'à créer une image bitmap, et la lib va automatiquement te la convertir en "tileset" (banque d'images) + "tilemap" (positionnement des tiles à l'écran). Par contre, dans ton code, il faut charger manuellement, pour chaque plan de background, tout d'abord le tileset, puis ensuite la tilemap.

En effet, pour pouvoir lire la "map", il faut d'abord que la SNES ait le tileset dans sa mémoire. C'est pour ça que ça marche dans un sens (bgInitTileSet puis bgInitMapSet), mais pas dans l'autre.

Dans la même logique, je souhaite mettre mes images à l'adresse 0x0000 qui est utilisé par la lib pour le système de texte.
Je fais donc :
oamInitGfxSet(&textframe, (&textframe_end-&textframe), &textframepal, (&textframepal_end-&textframepal), 0, 0x0000+(&snesfont_end-&snesfont)/2, OBJ_SIZE8);

mais l'image n'apparait pas.

Merci d'avance pour votre aide

Alors là je suis pas sur à 100% de mon info, mais il me semble qu'en fait le système de texte prend plus de place que simplement la FONT. En effet, la font représente uniquement le "tileset". Pour afficher du texte à l'écran, c'est comme le reste, il faut une "tilemap" associée. Et donc PVSNESLib génère dynamiquement une tilemap pour afficher le texte. Il me semble qu'elle est stockée dans la VRAM en 0x800 ou quelque chose du genre, donc tu ne peux pas stocker d'info graphique dans cette zone, car elle sera écrasée par la lib pour afficher du texte.

Pour info, sur mon jeu, qui utilise aussi le module de texte, je charge mon tileset en 0x2000, et ma tilemap en 0x1000. Mes sprites commencent à partir de 0x4000. Et le tout s'affiche bien sans collision ou écrasage de tile ou de tilemap par qui que ce soit :)

[hoit]

Le premier paramètre de bgInitTileSet() est tout simplement le numéro du "plan" pour lequel charger le tileset.

C'était le dernier paramètre qui attirait mon attention à cause du "4k aligned" spécifié dans la doc :
"address address of tile graphics (4K aligned)"

Merci   Les tiles et les map me semblent plus clair mais je vais faire d'autres tests pour être sur de tout comprendre, je n'ai pas encore pris le temps.

En chargeant une image 2 couleurs, je vois dans l'onglet 2bpp de la vram de no$sns qu'il y a un emplacement sur 2 (1 "carré" sur 2) qui n'est pas utilisé, y compris pour le système de texte de PVsneslib.
Connaissez-vous la raison à cela ?

J'ai constaté d'autres comportements bizarres et je pense qu'il s'agit de bugs, j'aimerais votre avis avant de les signaler sur git :

- Celui-ci je crois que vous en aviez parlé quelques pages avant : j'ai besoin de faire une image qui clignote mais en faisant l'appel à oamSetVisible en choisissant de masquer le sprite, il disparait de l'écran, il faut faire un oamSetXY pour le replacer.

- Avec le système de texte, une lettre fait 8x8px pour être affiché à l'écran. J'ai fait un carré aux mêmes dimensions avec un contour blanc. En l'affichant sur certaines lettres, je constate que le caractère est plus grand que le carré, ce qui me laisse penser qu'ils font plus de 8px. S'agit-il d'un bug ou d'une erreur dans mon code ?

Pour vérifier cela rapidement, j'ai fait un code minimal qui montre les 2 "problèmes" :

https://www.petit-fichier.fr/2018/02/28/minimal-code/

Une petite dernière pour la fin mais vraiment par curiosité : que signifie PV dans PVsneslib ?

[Invité]

Le 4K aligned représente le fait que tu peux pas envoyer n'importe où dans la VRAM, que ce soit pour les BGs ou pour les sprites.

Sinon, concernant le PV de PVsneslib, c'est tout simplement que la lib ne se nommait pas comme cela au début mais une autre lib avait le même nom (libsnes). Il y a bien longtemps, je développais sur des agendas de Casio nommés Pocket Viewer, j'ai donc repris le PV en hommage au nom PocketViewer, un scoop pour GamoPat cette info ^^ (https://web.archive.org/web/20020601084835/http://pocketcasio.free.fr:80/accueil.php3)

[drludos]

J'ai encore une question / problème technique avec PVSNESLib : savez-vous s'il y a une limite maximale de taille de code / nombre de "if / else if / else" que peut gérer tcc816?

Car, je rencontre régulièrement l'erreur suivante lors de la compilation:

Code:

game.asm:23: INPUT_NUMBER: Out of 16bit range.
game.asm:23: ERROR: Couldn't parse "sbc".

La ligne de code en question est :

Code:

sbc #__init_locals

Au départ, je pensais que c'était lié à la taille totale du code (cf mon problème précédent avec SNESmod), mais en fait ce n'est pas le nombre d'instructions qui crée le problème, mais le nombre de total de if / else if / else présent dans la totalité du code (même en déplaçant le code dans des fonctions différentes, ça plante encore). Le fait de rajouter un "else if", ou même un "ou" (condition 1 || condition 2) compte dans cette limite totale.

Je précise que pour l'instant mon code C fait dans les 2000 lignes environ, dans un seul fichier (sauf les .asm pour les assets).

Est-ce que l'un d'entre vous à déjà rencontré ce problème ?
(@alekmaul peut-être, vu que je pense que Sydney Hunter doit contenir beaucoup plus de "ifs" que mon jeu)...

Merci pour votre aide !

[Stef]

Question bête mais... pourquoi ne pas découper ton projet en plusieurs fichiers C ?? En plus tu y gagnerai en lisibilité non ?

[F.L]

Question bête mais... pourquoi ne pas découper ton projet en plusieurs fichiers C ?? En plus tu y gagnerai en lisibilité non ?

+1
j'ai rencontré le meme probleme avec mon code car j'ai un if à chaque ligne
j'ai du le decouper en une quinzaine de fichiers, car pvsneslib (ou la snes) sature vite et j'avais le meme code erreur
en général chaque fichier ne depassait pas 80-100 lignes (if)
et aussi dans chaque fichier il ne faut pas trop d'include non plus sinon ça serait trop facile

par contre pour la visibilité du code, ça depend de la manière de programmer de chacun,
moi au contraire si c'est trop decoupé, j'ai un mal de chien à debugger ensuite !

[hoit]

Hello,

De mon côté, jamais rencontré cette erreur mais je suis nettement moins avancé que vous. J'avais rencontré des limites en déclarant des tableaux un peu trop grand mais n'ai finalement pas eu besoin de faire comme cela (c'est peut être un problème qui se serait réglé en faisant du hirom au lieu de lorom?).

J'ai constaté d'autres comportements bizarres et je pense qu'il s'agit de bugs, j'aimerais votre avis avant de les signaler sur git :

- Celui-ci je crois que vous en aviez parlé quelques pages avant : j'ai besoin de faire une image qui clignote mais en faisant l'appel à oamSetVisible en choisissant de masquer le sprite, il disparait de l'écran, il faut faire un oamSetXY pour le replacer.

- Avec le système de texte, une lettre fait 8x8px pour être affiché à l'écran. J'ai fait un carré aux mêmes dimensions avec un contour blanc. En l'affichant sur certaines lettres, je constate que le caractère est plus grand que le carré, ce qui me laisse penser qu'ils font plus de 8px. S'agit-il d'un bug ou d'une erreur dans mon code ?

Pour vérifier cela rapidement, j'ai fait un code minimal qui montre les 2 "problèmes" :

https://www.petit-fichier.fr/2018/02/28/minimal-code/

L'un des vous a-t'il le temps de tester le code (quelques lignes seulement) pour confirmer qu'il s'agit ou non d'un bug ?

Merci :)

[drludos]

Merci pour vos réponses !

Alors il se trouve que c'est Shiru (un dev SNES et NES prolifique) a aussi déjà rencontré ce problème dans le passé, et la solution lui a été donné par Mic_ sur le forum SNESdev:
http://forums.nesdev.com/viewtopic.php?p=93412

En gros, la cause du problème est que TCC816 (qui transforme le code C en ASM donc) génère des "labels locaux" dans son code ASM. Et visiblement, le compilateur a une limite fixée "en dur" de 1000 labels locaux par fichier de code source C.

Je ne sais pas à quoi servent ces labels dans le code ASM, mais effectivement, j'ai dépassé cette limite. La solution consiste donc apparemment à découper son code en plusieurs fichiers pour contourner cette limite, ou plus simplement d’utiliser une version patchée de TCC816 qui permet de gérer jusqu'à 20.000 labels locaux. Cette version créée par Mic_ est téléchargeable ici:
http://jiggawatt.org/notmine/816-tcc-120507.zip

Personnellement j'avoue trouver plus pratique d'avoir tout mon code dans peu de fichier quand ils s'agit de "petits projets". Ca permet d'aller beaucoup plus vite pour débugger et faire des modifs de Game Design, mais après on est dans le domaine des préférences personelles de codeur là :). Par contre, pour des gros projets, style la PVSNESlib ou SGDK, je préfère bien évidemment que tout soit bien structuré en module bien séparé.

En tout merci pour vos conseils et votre aide.
@F.L Elle devient quoi d'ailleurs la version SNES de Barbarian ?

@hoit: j'ai pas encore eu le temps de tester ton code, mais à priori les lettres font bien 8x8 pixels. Pour ton bug de visibilité, tu as testé la dernière version de la lib posté par Alekmaul? Je pense qu'il a corrigé ce bug justement (entre autres :)).

[F.L]

@F.L Elle devient quoi d'ailleurs la version SNES de Barbarian ?

Elle etait en standby le temps que je fasse la version jaguar. Maintenant que cette derniere fonctionne, va falloir que je finisse d'optimiser le code pour snes. J'ai l'impression aussi qu'il faut un code bien structuré et ça j'ai du mal 

[Invité]

En gros, la cause du problème est que TCC816 (qui transforme le code C en ASM donc) génère des "labels locaux" dans son code ASM. Et visiblement, le compilateur a une limite fixée "en dur" de 1000 labels locaux par fichier de code source C.

Je ne sais pas à quoi servent ces labels dans le code ASM, mais effectivement, j'ai dépassé cette limite. La solution consiste donc apparemment à découper son code en plusieurs fichiers pour contourner cette limite, ou plus simplement d’utiliser une version patchée de TCC816 qui permet de gérer jusqu'à 20.000 labels locaux. Cette version créée par Mic_ est téléchargeable ici:
http://jiggawatt.org/notmine/816-tcc-120507.zip

Il faut effectivement bien découper le code, surtout que sur SNES, on fonctionne par bank de 32Ko, tu risque d'être vite dépassé.
J'avais récupéré le code de snessdk, qui contient le compilateur tcc, à voir si je peux recompiler tout cela pour en faire une nouvelle version effectivement, car je n'utilise pas la version de mic.
On a le même soucis avec les constantes, j'ai du, dans certains projets, refaire les constantes en fichier asm, car on dépassait les 32Ko.
CavernsOfDeath, par exemple, c'est 5 fichiers ASM, 25 fichiers C et je ne parle pas de toutes les maps (environ 150) en data directement converties dans des banks de 32 Ko...

[ichigobankai]

la snes c'est des banks de 32ko mais en lorom, nope
(et 64k en hirom)

[Invité]

la snes c'est des banks de 32ko mais en lorom, nope
(et 64k en hirom)

Oui, tout a fait. J'ai abandonné d'essayer de compiler la lib en hirom, pas simple de pouvoir rester compatible avec les 2 (lo/hi).

[hoit]

@alekmaul : Sur git, il y a quelques liens qui ne mènent pas au bon endroit :

- Sur la page d'acceuil git, tu présentes PVSneslib V2.3.2 et le lien juste en dessous redirige vers portabledev.com qui propose en téléchargement le V2.3.0
- Le wiki de portabledev est toujours accessible mais moins à jour que celui de git.

@drludos : je confirme que c'est bien la v 2.3.2 que j'utilise et le bug de visibilité est toujours présent.
Pour le texte, effectivement les lettres font bien 8px mais le cadre qui l'entoure aussi, c'est ce qui me fait dire que ca ne devrait pas "déborder".


Dommage pour le hirom qui ne fonctionne pas, je m'étais justement posé la question il y a pas trop longtemps !

[Invité]

Je pense que pour développer sur SNES, il faut en vouloir beaucoup et se taper de l'assembleur un minimum ( voire un maximum ), c'est la console des Jedis du dev.

[Invité]

@alekmaul : Sur git, il y a quelques liens qui ne mènent pas au bon endroit :

- Sur la page d'acceuil git, tu présentes PVSneslib V2.3.2 et le lien juste en dessous redirige vers portabledev.com qui propose en téléchargement le V2.3.0
- Le wiki de portabledev est toujours accessible mais moins à jour que celui de git.

Ok, c'est mis à jour