Re: developper sur SNES avec pvsneslib !

[Invité]

c'est en 256. comment fais on pour passer en 512 ?

T'as pas une fonction dédiée ??
remarque alekmaul ne l'a peut être pas encore implémentée vu son utilité .

[F.L]

lincruste, es tu arrivé à faire fonctionner l' exemples simple sprite ?

s'il n'y a pas en 512 je ferais le jeu en 256 mais c'est dommage, il n'y a que la version spectrum qui était en 256

[lincruste]

Oui j'ai obtenu l'affichage d'une SNES sur un fond noir. Grâce à ton package, parce que tout seul je n'y arrivais pas.

[F.L]

oui c'est ça.
c'est cool mon dossier est pret à l'emploi pour windows7
c'est grace à 65c02 sinon moi non plus je n'y serais pas arrivé hélas.
maintenant tu peux afficher des sprites, jouer du son,avoir des entrées pad, bref tout ce qu'il faut pour faire un jeu, mais pas de background pour l'instant.....
si tu y arrive bien pour le reste , on pourrais s'entraider car j'ai du mal quand meme. par exemple je ne sais pas comment apeller une fonction ou un bout de code sur un fichier externe....
j'ai l'impression que le main ne doit pas depasser 8ko comme sur pcengine. j'attends confirmation d'alekmaul

[Invité]

Bien sûr, voilà ce que j'ai fait:
Téléchargement du zip depuis le dépôt GitHub et extraction.
https://github.com/alekmaul/pvsneslib/archive/master.zip
Je suis dirigé vers le wiki via le readme sur GitHub.
Installation de Python 2.7 à la racine de C:\
Installation de MSYS et ajout dans $PATH (lien mort)
http://www.portabledev.com/modules/download_gallery/dlc.php?file=484&id=1333951774
Arrivé à l'étape 2, l'arborescence ne correspond pas.
J'ai fini par comprendre que l'archive la plus récente master.zip contient déjà devkitsnes, ce qui fait qu'elle se retrouve dans le sous-répertoire décompressé alors que la doc précise qu'il doit être dans un répertoire adjacent. Je reprends donc la version sur:
http://www.portabledev.com/download/3/
C'est ce qui m'a amener à penser que la doc datait.
Installation de Programmer's Notepad et configuration des raccourcis sur la base du screenshot.
Je tente un make clean:

Code:

> "make clean"

> Failed to create process: Le fichier spécifié est introuvable.

> Process Exit Code: 0
> Time Taken: 00:00


Je tente Make, là ça fonctionne et commence à compiler ces 4 .obj avec succès
crt0_snes.obj
libc.obj
libm.obj
libtcc.obj
avant de cracher un

Code:

"make": doxygen: Command not found
"make": *** [docs] Error 127

J'ai commencé à regarder dans le makefile pour voir s'il y avait un problème de chemin, ce qui paraît logique avec l'erreur de make clean, mais je n'ai pas vu de chemin en dur. J'ai vérifié que le répertoire bin de devkitsnes était dans $PATH.
Au-delà, c'est trop pointu pour moi.

OK, je note tout cela et je vais essayer de faire en sorte que ce soit plus simple , désolé encore, un peu trop pris par trop de choses ...

[Invité]

s'il n'y a pas en 512 je ferais le jeu en 256 mais c'est dommage, il n'y a que la version spectrum qui était en 256

Sur snes seul le background passe en 512 les sprites eux restent en 256, donc ça risque de faire moche .

[lincruste]

je ne sais pas comment apeller une fonction ou un bout de code sur un fichier externe....

Je suis très loin d'être un gourou du C, mais ça c'est bon je connais: tu dois inclure les fonctions en question dans un fichier header (avec l'extension .h).
Pour pouvoir les utiliser dans ton main.c, tu dois inclure le header en question au début de ton code sous forme

Code:

#include <file.h>

Tu pourras constater que c'est déjà utilisé dans les exemples d'Alekmaul avec

Code:

#include <snes.h>

Quand il écrit ça, il permet justement à son code source d'utiliser les fonctions qu'il a écrites dans snes.h sans avoir besoin de les recopier à chaque fois.
Ça s'appelle une directive de préprocesseur si ma mémoire est bonne.
En gros, ça permet au précompilateur de faire comprendre au compilateur qu'à chaque fois que tu appelleras la fonction -par exemple- FaireUnZoomQuiDechire() tu lui demandes d'aller la chercher dans le fichier snes.h. Évidemment il faudra que la fonction FaireUnZoomQuiDechire() soit bien présente dans snes.h (ça m'étonnerait).

[F.L]

Merci lincruste pour ta reponse, il y a encore ded trucs de base qui m'echappent encore avec le C
Et si parfois je pose des questions bizarre faut pas s'etonner   (demande à TOUKO) 
Je vais essayer d'integrer le moteur que j'avais fait pour la pce sur la snes

[Invité]

En gros, ça permet au précompilateur de faire comprendre au compilateur qu'à chaque fois que tu appelleras la fonction -par exemple- FaireUnZoomQuiDechire() tu lui demandes d'aller la chercher dans le fichier snes.h. Évidemment il faudra que la fonction FaireUnZoomQuiDechire() soit bien présente dans snes.h (ça m'étonnerait).

snes.h est plutôt un fichier qui inclue les autres fichiers .h qui sont dans le sous répertoire snes mais l'idée est effectivement la.

En résumé, ton fichier toto.c veut appeler une fonction mafct d'un fichier titi.c, tu dois :
1) créer un fichier titi.h qui déclare la fonction avec, par exemple extern void mafct(void);
2) dans toto.c, tu fais, en haut, un #include "titi.h"
3) dans titi.c, tu mets ta fonction void mafct(void) {...};

Le principe est d'organiser le code par type de fonction (main qui fait presque rien, intro, ennemis, level, etc ...).
On pourra regarder sur ton code de barbarian version pce si tu veux.

Essayes de regarder par là , y'a des cours sympa :
http://franckh.developpez.com/articles/c-ansi/bien-debuter-en-c/

ou encore http://melem.developpez.com/tutoriels/langage-c/initiation-langage-c/
et https://c.developpez.com/cours/20-heures/?page=page_1

[Invité]

Et si parfois je pose des questions bizarre faut pas s'etonner   (demande à TOUKO) 

Meuh non, franchement on est tous là pour s'entraider non ??, donc y'a pas de questions à la con, mais des questions tout court .   
Y'a des trucs qui te semblent pas clairs de prime abord, et le fait que quelqu'un d'autre t'explique, souvent ça devient très simple finalement(ou pas   ).

[drludos]

Super pour ce sujet, ça me (re)motive pour me lancer dans un jeu SNES avec PVSNESLIB (je m'étais arrêté après l'install + test de compilation des exemples).

Merci F.L. pour ton dossier "tout prêt", ça me permettra d'avoir une lib plus récente que celle que j'avais testé d'installer il y a déjà pas mal de temps.

Alors, tu attaques directement par un portage de Barbarian, ou tu vas essayer de faire une petite démo / autre jeu avant ?

[F.L]

merci drludos !
pour l'instant le projet barbarian sur snes en est au debut du debut, je ne sais meme pas si je vais me lancer vraiment ou pas.
pour l'instant le moteur de jeu ne compile pas completement hélas ,
65c02 et alekmaul m'aident car c'est pas evident du tout !
comme tu le dis, je devrait peut etre me lancer dans un petit projet avant, histoire de domestiquer ce nouvel outil. on verra !
et sinon, il y a t'il du monde qui s'est lancé dans l'aventure depuis ?

[lincruste]

De mon côté je réserve le peu de temps que j'ai au GBDK de la Game Boy. Mais avec l'arrivée de la SNES Mini, cette bibliothèque est la prochaine étape.

[F.L]

Pourquoi? On pourra inserer une carte sd avec des roms dans la snes mini ?

[lincruste]

Non l'injection de rom se fait directement via son port USB.

[F.L]

c'est intéréssant pour le developpement ! car une snes originale+un everdrive, ça douille
par contre, j'espere que ça soit compatible avec les homebrew

[lincruste]

J'en parlais surtout pour l'aspect "visibilité", vu que cette machine a remis la SNES au goût du jour, y compris chez les gens qui n'y pensaient plus depuis 20 ans.
Pour la programmation par contre je ne la recommanderais pas, ça reste dix fois moins pratique qu'un émulateur comme bsnes/higan ou no$sns.

[Invité]

c'est intéréssant pour le developpement ! car une snes originale+un everdrive, ça douille
par contre, j'espere que ça soit compatible avec les homebrew

C'est clair, l'everdrive snes est ultra chère .

[F.L]

J'en parlais surtout pour l'aspect "visibilité", vu que cette machine a remis la SNES au goût du jour, y compris chez les gens qui n'y pensaient plus depuis 20 ans.
Pour la programmation par contre je ne la recommanderais pas, ça reste dix fois moins pratique qu'un émulateur comme bsnes/higan ou no$sns.

je suis d'accord avec toi pour les emulateurs, mais c'est bien de temps en temps de verifier si tout marche bien sur le vrai hardware.

oui TOUKO, quand j'ai vu le prix des everdrives snes

[lincruste]

Ha oui mais là aussi justement c'est trompeur, la boîte reproduit la SNES mais l'intérieur est le même qu'un smartphone avec son émulateur.
Non rien ne remplace un émulateur/debugger sur PC et une vraie SNES avec son everdrive pour voir si ça fonctionne.

[Invité]

Perso, j'ai celui là :http://www.retrousb.com/product_info.php?cPath=24&products_id=84, pas dispo pour le moment et ça coûte une blinde aussi.
Pour le debugging, il faut de toute façon tester sur SNES, aucun émulateur ne permet à l'heure actuelle d'émuler comme la console, même bsnes plus à des lacunes.
Aussi, il faut tester en 50 et 60hz, car cela change aussi sur console (j'ai une SNES switchée pour cela).

[drludos]

Pour le Super Everdrive, il est dans la même gamme tarifaire que les autres Everdrive (entre 80-90€ donc). Celui qui vaut vraiment cher, c'est le SD2SNES, mais il a l'avantage de pouvoir remplacer pas mal de cartouches à puces additionnelles (sauf le Super FX et quelques trucs exotiques), et ce sans avoir à y souder une puce à l'intérieur (pour le Super Everdrive, il n'émule que le DSP1, et encore il faut dessouder une puce d'une cartouche style Mario Kart pour la souder sur la cartouche afin que cela fonctionne).

Personnellement, j'ai craqué pour le SD2SNES il y a déjà un petit moment (vu que je m'en suis servi pour jouer à Demon's Crest, Hagane, Ninja Warriors et Megaman X2 et X3, je le considère bien amorti déjà), mais je reconnais que si on a déjà les cartouches en question, ou uniquement pour faire du dev, mieux vaut se tourner vers le Super Everdrive.

Après, on en a pour son argent : la cartouche fonctionne hyper bien, le chargement des jeux est hyper rapide, les sauvegardes marchent bien, etc. Bref, pour un collectionneur qui veut jouer sans abîmer ses cartouches, ou tester des jeux qu'il n'a pas, ça marche bien.

[Invité]

Bah 86€ pour la version de base, par rapport au 49€ de la version Md, j'appelle ça cher moi,surtout avec de la flash rom au lieu de la RAM contrairement aux versions MD/PCE .

Mais j'ai l'impression que krikzz a un peu abusé sur les prix ces derniers temps, non ??

[drludos]

Ah oui, par rapport aux prix des Everdrive MD, je suis d'accord avec toi, c'est pas donné. Après, moi je le comparais plutôt à l'Everdrive GB, qui m'avait coûté dans ce prix là de mémoire. Mais j'ai vu que maintenant il a fait comme pour la megadrive, avec une variante pas cher / moyenne / haut de gamme, histoire que tout le monde en profite.

Ca pourrait être cool qu'il fasse de même pour son Super Everdrive, afin d'en faire un plus accessible :)
(car le SD2SNES n'est pas de Krikzz, c'est donc pas un "Everdrive" techniquement parlant)

[lincruste]

(car le SD2SNES n'est pas de Krikzz, c'est donc pas un "Everdrive" techniquement parlant)

Ha bon ? J'avais cru lire que c'était de lui, en partenariat avec Byuu. D'ailleurs je crois bien que c'est ce que m'a confirmé FFVIMan en parlant de l'exemplaire dont il se sert pour tester les snes sur lesquelles il intervient. Enfin il me semble bien.

[Invité]

je pense qu'il doit en être,sinon il ne la vendrait pas sur son site je pense .

[drludos]

Alors, effectivement le SD2SNES a été conçu par Ikari, mais elle est bien fabriqué par Krikzz, autant pour moi.

Par contre, c'est bien Ikari qui développe la partie software, en espérant qu'un jour il arrive à implémenter les "save states" ainsi que la prise en charge du Super FX sur la cartouche (enfin bon, comme ça fait 2 ou 3 ans qu'il est dessus, à mon avis ça ne se fera pas). Je pense même qu'Ikari a arrêté de travailler dessus.

Et du coup, je ne suis pas sur qu'on voit une déclinaison X3/X5/X7 du SD2SNES de sitôt...

[lincruste]

Ha oui, d'ailleurs ce n'est pas si grave, les jeux Super FX ne sont pas si nombreux et d'un point de vue programmation on n'est plus dans le même monde. J'ai lu récemment que les programmeurs d'Argonaut avaient pris l'habitude de dire que la SNES entière était un vulgaire bloc d'alimentation pour le Super FX.

[Invité]

Si ça peut intéresser :
https://forums.nesdev.com/viewtopic.php?f=12&t=16625

Hi everyone,

a few days ago I finished some debugging feature plans I had for bsnes-plus in order to debug some games I work on.

As it would be nice to maybe create a pull request to maybe merge it into the original bsnes-plus version I'd like to have some people to test the new feature.

You can download and compile it from this page:
https://github.com/BenjaminSchulte/bsnes-plus

[F.L]

c'est de l'assembleur ?

[Invité]

Non c'est une version de bsnes avec des fonctions avancées pour débugger .
Donc forcement le viewer de code est en asm, mais tu peux visualiser aussi plein de chose comme la vram ou les registres des PPU par exemple .