Re: developper sur SNES avec pvsneslib !

par Invité Jeu 8 Mar 2018 - 7:14

hoit a écrit:@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

par drludos Ven 9 Mar 2018 - 22:14

alekmaul a écrit: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...

Merci à tous pour vos conseils et infos! Et c'est super Alek de nous indiquer le détail d'un projet aussi ambitieux que Caverns of Death - j'imagine même pas comment tu as du galerer pour faire rentrer tout cela dans la cartouche :)

Par contre, sais-tu quelle est la limite du nombre de constantes maximales du coup ?

Et pour convertir tes maps en data, tu as crée un outil spécial ? (car c'est vrai qu'avoir une sorte de "Tiled" pour faire soi-même ses maps au format SNES serait super utile)

En tout cas, bravo pour la release de Sydney Hunter Caverns of Death - j'imagine que tu dois être fier que la cartouche soit officiellement sortie !

par Invité Sam 10 Mar 2018 - 7:10

drludos a écrit:
Par contre, sais-tu quelle est la limite du nombre de constantes maximales du coup ?

Et pour convertir tes maps en data, tu as crée un outil spécial ? (car c'est vrai qu'avoir une sorte de "Tiled" pour faire soi-même ses maps au format SNES serait super utile)

En tout cas, bravo pour la release de Sydney Hunter Caverns of Death - j'imagine que tu dois être fier que la cartouche soit officiellement sortie !

J'utilise effectivement Tiled pour les maps et des scripts Python pour convertir en fichiers binaires (et en fichier assembleur 68K pour la version Megadrive).
Avec Tiled, je gère les maps + les objets dans la map + les priorités des tiles
Pour l'instant, ces scripts sont trop spécifique à Sydney pour être intégré dans la lib.

Le nombre de constantes, autant que tu veux par banque de 32Ko, y'a pas trop de limite à part la taille de la ROM ...
Avec constify, qui change les var de type const en vrai constante, tu a un paramêtre pour spécifier la banque que tu veux. J'avais du ajouter cela quand j'ai commencé Anguna sur SNES.
Par contre, faudra jongler dans ton makefile pour l'utiliser avec ce paramètre.

Et sinon, oui, fière d'avoir enfin bouclé Sydney, au bout de 3 ans ...

par hoit Dim 11 Mar 2018 - 17:54

Hello,

J'ai essayé de faire un background pour mes tests mais j'obtiens le message d'erreur suivant à la compilation :

Code:: Opening graphics file: [pvsneslib.bmp] ****** O P T I O N S *************** border=OFF highpriority=OFF blanktile=OFF collisionmap=OFF Optimize tilemap=ON LZSS compression=OFF pixel format=bit-plane BMP file: 256x224 pixels Screen mode selected: 32x28 tile map Palette rearrange: ON Total colors = 16 Palette section to convert: Color #0 to 127 ************************************ width=256, height=224, size=8, *xsize=32, *ysize=28, new_width=8, border=0 rows=896 ERROR: Detected more colors in one 8x8 tile than is allowed. "make": *** [pvsneslib.pic] Error 1

Je me sers de l'exemple Mode1 (dispo dans graphics > backgrounds) et je remplace l'image pvsneslib.bmp par la mienne.
L'image est uploadé ici :

https://www.petit-fichier.fr/2018/03/11/bg/

Le format semble bon mais le problème vient du paramètre -pr (rearrange palette and perserve palette numbers in the tile map) passé à gfx2snes (dans snes_rules).

Si a la place j'utilise -pR (palette rounding), la compilation passe bien mais le résultat à l'écran est inexploitable.
Avez-vous une astuce pour que je puisse charger l'image ?

Le logiciel que j'utilise ne permet pas de passer sous 256 couleurs apparemment, je pense que convertir l'image en 16 couleurs puis la remettre en 256 devrait résoudre le problème. Je vais voir si j'en trouve un autre pour faire le test.

Merci

par drludos Dim 11 Mar 2018 - 18:15

alekmaul a écrit:J'utilise effectivement Tiled pour les maps et des scripts Python pour convertir en fichiers binaires (et en fichier assembleur 68K pour la version Megadrive).
Avec Tiled, je gère les maps + les objets dans la map + les priorités des tiles
Pour l'instant, ces scripts sont trop spécifique à Sydney pour être intégré dans la lib.

Le nombre de constantes, autant que tu veux par banque de 32Ko, y'a pas trop de limite à part la taille de la ROM ...
Avec constify, qui change les var de type const en vrai constante, tu a un paramêtre pour spécifier la banque que tu veux. J'avais du ajouter cela quand j'ai commencé Anguna sur SNES.
Par contre, faudra jongler dans ton makefile pour l'utiliser avec ce paramètre.

Et sinon, oui, fière d'avoir enfin bouclé Sydney, au bout de 3 ans ...

Merci Alek pour les infos, et encore bravo pour Sydney! J'espère que le jeu rencontrera le succès qu'il mérite, en tout je le trouve très impressionnant techniquement (l'effet de la torche en particulier, je ne sais pas même pas comment tu as fait ça !) et très joli d'un point de vue artistique :).

J'ai deux questions toutes bêtes par rapport à la PVSNESlib:

- Avec le moteur de texte, comment est-il possible de "vider" tout le BG qui contient les tiles de texte d'un coup (pour effacer l'écran simplement). Actuellement, pour effacer du texte j'affiche des espaces à la place, mais je pense que ce n'est pas l'idéal :).

- Lors de la compilation, où se trouve la ligne qui efface automatiquement le fichier .asm généré à partir du fichier .c. Plus exactement, c'est l'instruction "rm MonJeu.ps MonJeu.asm". J'ai eu beau chercher dans le makefile (celui du projet template comme celui du "snes_rules" de la lib), je ne l'ai trouvé nulle part. Pour l'instant, j'utilise la ligne qui copie tous les fichiers ".asm" en ".savasm" que tu avais incluse dans ton fichier "snes_rules", mais je suis vraiment curieux de savoir d'où vient ce "rm" qui efface des fichiers comme par magie :).

Merci pour ton aide !

par drludos Dim 11 Mar 2018 - 18:24

hoit a écrit:Hello,

J'ai essayé de faire un background pour mes tests mais j'obtiens le message d'erreur suivant à la compilation :

Code:
Opening graphics file: [pvsneslib.bmp] ****** O P T I O N S *************** border=OFF highpriority=OFF blanktile=OFF collisionmap=OFF Optimize tilemap=ON LZSS compression=OFF pixel format=bit-plane BMP file: 256x224 pixels Screen mode selected: 32x28 tile map Palette rearrange: ON Total colors = 16 Palette section to convert: Color #0 to 127 ************************************ width=256, height=224, size=8, *xsize=32, *ysize=28, new_width=8, border=0 rows=896 ERROR: Detected more colors in one 8x8 tile than is allowed. "make": *** [pvsneslib.pic] Error 1

Je me sers de l'exemple Mode1 (dispo dans graphics > backgrounds) et je remplace l'image pvsneslib.bmp par la mienne.
L'image est uploadé ici :

https://www.petit-fichier.fr/2018/03/11/bg/

Le format semble bon mais le problème vient du paramètre -pr (rearrange palette and perserve palette numbers in the tile map) passé à gfx2snes (dans snes_rules).

Si a la place j'utilise -pR (palette rounding), la compilation passe bien mais le résultat à l'écran est inexploitable.
Avez-vous une astuce pour que je puisse charger l'image ?

Le logiciel que j'utilise ne permet pas de passer sous 256 couleurs apparemment, je pense que convertir l'image en 16 couleurs puis la remettre en 256 devrait résoudre le problème. Je vais voir si j'en trouve un autre pour faire le test.

Merci

Mon antivirus bloque le site "petit-fichier", donc j'ai pas pu récupérer ton exemple, mais de toute façon vu le message d'erreur le problème vient du fait que ton image ne respecte pas les limites de la SNES je pense.

Sache que, quel que sois le format de sortie de ton image (4, 16 ou 256 couleurs), en entrée gfx2snes ne peut travailler qu'avec des BMP de 256 couleurs. Il te faut donc absolument un logiciel qui te permette de travailler facilement avec des fichiers BMP et de pouvoir modifier aussi leur palette. Personnellement, j'utilise le freeware GraphicsGale, qui est aussi un super logiciel de dessin et d'animation pour le pixel art (je fait tout mon jeu SNES avec ça) : https://graphicsgale.com/us/

Ah, et n'essaie même pas d'utiliser le Paint de windows : il fait n'importe quoi avec les palettes, et gfx2snes ne peut convertir des fichier issus de Paint (en tout cas sous W7).

L'affichage d'image en 256 couleurs étant un peu "spécifique" sur SNES (en gros, tu n'utilise plus les palettes mais un codage particulier pour les couleurs), pour commencer je te conseille plutot d'essayer d'afficher des images de 16 couleurs en utilisant le mode 1 :). En plus, ce mode propose 3 plans, ce qui permet de faire du parallaxe, d'avoir un GUI à l'écran, etc. La plupart des jeux SNES utilisent le mode 1 durant le jeu (le mode 3 avec ses 256 couleurs est plutôt pour les écrans d'intro, etc.).

par hoit Dim 11 Mar 2018 - 20:39

ok donc ton antivirus bloquera également l'exemple de code de la page précédente avec les 2 effets qui sont (je pense) des bugs (la position qui change quand on masque/affiche une image et le texte qui semble faire plus de 8 px).

Au cas où ca t'intéresse, j'ai réuploadé ici les fichiers en espérant que le lien là ne soit pas bloqué :

Le code minimal pour tester les 2 "bugs" :
https://www.transfernow.net/869bi068nyel

Le background dont je parle :
https://www.transfernow.net/08bjf557oods

Dans mon cas, j'ai essayé de faire l'image avec photoshop pour avoir 256 couleurs, ca avait l'air de bien fonctionner pour les autres exemples.
J'avais banni paint pour faire les retouches et téléchargé Graphicsgale suite à ton conseil sur une des pages précédente et ai finalement essayé photoshop à la place, je vais voir si sur ce cas ci Graphicsgale résoud le problème.

Pour donner un peu plus de précisions, c'est bien le mode 1 que j'utilise et que mon objectif est d'avoir le résultat en 16 couleurs (d'après la commande exécutée, ça devrait être le cas).

par Invité Mar 2 Oct 2018 - 15:17

Petite question, pour travailler sur SNES, cette lib est suffisante ou c'est encore expérimental ?

Avec un CPU aussi peu rapide, ce n'est pas mieux L'ASM ?

par Invité Mar 2 Oct 2018 - 20:08

En fait, il faut utiliser les deux.
Voici un proto de Papi Reload réalisé avec ce SDK :

( Gfx de Grostonton, code d'Alek Maul et moi qui supervisait le tout )

par Invité Mer 3 Oct 2018 - 7:24

C'était volontaire d'y mettre un seul sprite ?

Ce n'est pas plus simple de passer directement par de L'ASM ?

par Stef Mer 3 Oct 2018 - 10:21

Ce n'est jamais plus simple de tout faire en ASM quand tu peux faire une partie en C et mettre de l'ASM où tu en as besoin... Franchement quoiqu'on en dise, coder en assembleur ça prend quand même nettement plus de temps, surtout si tu retouches souvent à ton code, le C te permettra d'être bien plus productif. Ce que je te conseille c'est de commencer tout en C et seulement à la fin, lorsque tu devras optimiser ton code pour être à 60 FPS plutot que 20 FPS par exemple, là tu pourras convertir ton code stable en assembleur et sur les parties critiques uniquement (par la peine de tout convertir).

par **Tryphon** Mer 3 Oct 2018 - 10:58

Je suis d'accord avec Stef. L'asm, c'est localement très simple, mais globalement c'est le bordel. Si tu dois modifier l'architecture de ton code, c'est galère (déjà que ça l'est en C).

Après, si tu as déjà codé plusieurs jeux complets, que tu as une idée précise de comment l'architecturer dès avant de pondre la première ligne, alors oui, c'est jouable de tout faire en asm.

par Invité Mer 3 Oct 2018 - 11:06

Disons que le code C est assemblé par le compilateur, mais pas forcément de manière optimale.
Moins tu tapes des lignes, mieux c'est ! Wink

Le fait de coder en ASM, c'est que gue tu sais que le code compilé sera conforme à ce que tu as écris. Faut il encore savoir optimiser en ASM, connaitre les cycles de chaque operations, les opérations binaires, familiariser avec le binaire, etc ... Ce sont des conventions a apprendre qui ne sont pas compliquées mais assez chiantes en substance.

par **Tryphon** Mer 3 Oct 2018 - 11:10

Je pense qu'on exagère très fortement l'importance de connaître le temps d'exécution d'un code au cycle près sur ce forum.

La plupart des problèmes de lenteur d'un code sont dus à un algorithme ou une structure de donnée mal choisie.

Un jeu n'est jamais au cycle près, du moins sur 16 bits.

par Invité Mer 3 Oct 2018 - 11:53

OKI, donc si un jour je souhaite coder un jeu sur SNES, il faudrait utiliser cette lib puis tout réécrire en ASM.

l'ASM, j'aimerais bien apprendre, mais le C, c'est vraiment plus structuré je trouve.

par Invité Dim 7 Oct 2018 - 23:44

Tout est une question d'organisation , l'asm n'est pas plus bordélique , surtout qu'on a de nos jours de très bon outils pour coder en asm Wink

Sinon je code en C et en assembleur néanmoins sur les consoles 8/16 bits je préfère le faire en full assembleur parce que ça reste justement abordable sur ces machines ! :)

NT: Je devrais mettre ma lib asm pour la SNES sur GiHub un de ces jours ^^

par **Tryphon** Dim 7 Oct 2018 - 23:46

Tu penses à quoi comme très bon outil pour l'ASM (68000 de préférence).

Parce que moi je code avec Notepad++ et une console en ligne de commande, ça fait un peu archaïque je trouve developper sur SNES avec pvsneslib ! - Page 7 435303

developper sur SNES avec pvsneslib ! - Page 7 435303

par Invité Lun 8 Oct 2018 - 7:29

Sur SNES j'utilise wla-dx , pour la MD (donc le M68000) , j'utilise VASM , de plus il permet d'avoir des label temporaire sur ces macro , du coup j'ai recréer les if/else/while/for , ça évite de créer des labels à chaque fois (donc gain de productivité) et le code est un peu plus clair ^^

La combinaisons macro/fonction bien utilisé se trouve relativement efficace , (j'avais fait 2 petit jeux en 2 jours sur NG et MD en full asm).

Niveau IDE , je te conseille Geany , configurable pour avoir la coloration syntaxique du 68000 , et comme code:block un bouton compiler et un bouton pour lancer ton ému+rom Wink

par Invité Lun 8 Oct 2018 - 7:57

Tryphon a écrit:Tu penses à quoi comme très bon outil pour l'ASM (68000 de préférence).

Parce que moi je code avec Notepad++ et une console en ligne de commande, ça fait un peu archaïque je trouve

Je fais pareil, tu sais nos habitudes de vieux sont pas faciles à changer Mr. Green

par **Tryphon** Lun 8 Oct 2018 - 8:10

Kannagi a écrit:Sur SNES j'utilise wla-dx , pour la MD (donc le M68000) , j'utilise VASM , de plus il permet d'avoir des label temporaire sur ces macro , du coup j'ai recréer les if/else/while/for , ça évite de créer des labels à chaque fois (donc gain de productivité) et le code est un peu plus clair ^^

La combinaisons macro/fonction bien utilisé se trouve relativement efficace , (j'avais fait 2 petit jeux en 2 jours sur NG et MD en full asm).

Niveau IDE , je te conseille Geany , configurable pour avoir la coloration syntaxique du 68000 , et comme cod:e:block un bouton compiler et un bouton pour lancer ton ému+rom

Merci :) (et hop, installé geany)

Touko a écrit:
Tryphon a écrit:Tu penses à quoi comme très bon outil pour l'ASM (68000 de préférence).

Parce que moi je code avec Notepad++ et une console en ligne de commande, ça fait un peu archaïque je trouve
Je fais pareil, tu sais nos habitudes de vieux sont pas faciles à changer

Le pire, c'est le débuggage. Je suis incapable d'utiliser un debugger. Pour moi, le debuggage, c'est à coup de printf dans le source Razz

(enfin je fais des macros faciles à désactiver, mais c'est l'idée)

par Invité Lun 8 Oct 2018 - 8:30

Vous auriez un code source d'un petit jeu ASM à partager? Je suis curieux de voir à quoi cela ressemble.

par ichigobankai Lun 8 Oct 2018 - 8:37

tu prends n'importe quel jeux SNES, tu le passes dans Dispel (désassembleur snes), et là tu rigoles un bon coup.
Un jeu dessassemblé (snes) ca fait entre 15 et 25 mo... de fichier texte compact.

Mais en l'état sans doc pour les opcode & registres (doc différente à chaque machine), ca ne sert à rien d'aller y jeter un oeil, autant ouvrir la rom avec un éditeur hexadécimal.

par **Tryphon** Lun 8 Oct 2018 - 8:40

Quelques jeux ont été complètement désassemblés et commentés.

Super Mario Bros doit être un exemple pas trop long ni compliqué.

Sonic l'a été, mais c'est beaucoup plus lourd à lire.

par Invité Lun 8 Oct 2018 - 8:57

J'ai regardé un simple hello world, j'ai failli tomber de la chaise.

par **Tryphon** Lun 8 Oct 2018 - 9:01

Tiens, le source commenté de Sonic, avec des outils pour recompiler si tu veux, plus des éditeurs on dirait : https://github.com/sonicretro/s1disasm

par Invité Lun 8 Oct 2018 - 9:11

J'ai regardé le début, ça allait, mais en descendant ça se complexifie énormément.

par Invité Lun 8 Oct 2018 - 9:14

@Shingo :
Jettes un coup d'oeil sur ce topic :
https://www.gamopat-forum.com/t87575-papi-commando-fait-de-l-assembleur-68000?highlight=Papi+commando+assembleur

par **Tryphon** Lun 8 Oct 2018 - 9:21

+1 Vetea, c'est plus facile de comprendre l'intérêt de l'assembleur sur quelques petites routines que sur un projet complet.

par ichigobankai Lun 8 Oct 2018 - 9:36

Comme on a déjà du le dire avec Stef (entre autre),
tu peux faire cohabiter le meilleur des 2 mondes ;
tu codes tout en C pour avoir quelque chose de fonctionnel "rapidement" et ensuite tu convertis certaines routines en ASM
(enfin si le jeu en a besoin et/ou que l'envie de s'y mettre est "là").

par Invité Lun 8 Oct 2018 - 9:44

C'est ce que je fais. Réaliser un jeu complet de A à Z en ASM comme premier projet, c'est vraiment trop ambitieux.
Commences par faire ton apprentissage sur quelques routines/Algo.
Exemples à faire
* Algo de tri ( croissant/décroissant ) sur un tableau.
* Triangle de pascal à n Hauteur.
* Routine d'affichage de caractère ( avec assimilation du mode d'adressage avec le VDP)
* etc ...

par Invité Lun 8 Oct 2018 - 10:33

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 Mr. Green