Fan made project : NEO SUPER MARIO BROS

Chipsonsteroids a écrit:

OzzyOuzo a écrit:Coté programmation je commence à me sentir à l'étroit dans la rom p1 si qqu'un peut me donner des détails sur le bank switching sur le discord NeoSMB ca serait cool :)

Salut.

J'ai du mal à voir ce qui nécessite un bankswitching sur la P1. Si c'est le level description qui prend trop de place, ça doit pas être compliqué à compresser car à vue de nez les 3/4 des tiles sont vides.

Par ailleurs, utiliser du bankswitching rendra très compliqué une future release sur support physique (et c'est déjà assez compliqué même sans ça). L'utilisation des linker pour tester des démos, alors faudra pas non plus compter dessus.

Par ailleurs as-tu testé ton projet sur le hardware original via un NeoSD par exemple ? Si ce n'est pas fait, je te conseille de le faire urgemment car il peut y avoir des bugs surprises entre une version MAME et une version cartouche.

Sinon bravo pour le projet, même si je pense que ça mériterait que quelqu'un s'investisse pour avoir une DA originale. Il y a sûrement des artistes dans la communauté.

Salut,

Bah si je ne dis pas de conneries il faut compter 1MB par rom P et bien il faut croire que je suis pas loin de remplir la mémoire et même si ce n'est pas le cas , via compression ou autres pirouettes avec le nombre de niveaux et d'assets global ca ne rentrera pas à terme.  D'après les docs le bank switch donne accès à au moins 4MB voir 8MB possibles.

Pour les histoires de release physique et linker c'est vrai que je ne suis pas trop au fait de ce genre de trucs.. j'imagine qd meme que ce sera possible d'en faire une version cartouche et pour le linker c'est pas un truc que j'utilise, je ne bosse qu'avec Mame ^^.  Une version NeoSD est disponible sur itch.io et on m'a rapporté que ca fonctionnait bien. ;-)

Pour tout ce qui est retouches graphiques, réglages de gameplay ou autre c'est encore un peu trop tot dans le dev.
Les ressources sont encore amenées à être modifiées tant que l'ensemble n'est pas en place.
En d'autres mots, finaliser des trucs maintenant ce serait une complète perte de temps, donc autant ne pas faire bosser des artistes pour rien...
Et comme je l'ai déja dit, je compte ouvrir progressivement le projet justement pour que des retouches et réglages soit possibles par les personnes intéressées.

Par contre, si des rippeurs veulent aider à extraire des sprites de la version NDS pourquoi pas, contactez moi sur discord.

OzzyOuzo a écrit:Pour les histoires de release physique et linker c'est vrai que je ne suis pas trop au fait de ce genre de trucs..

Moi non plus, mais quand je lis "bankswitching", ça fait retentir une alarme dans ma tête et j'me dis que ce serait dommage de prendre un parti technique qui te bloque dans le futur. Renseigne-toi bien sur ce point.

Yep
Vous intégrez les descrip de maps dans P ?
Ce n'est pas prévu quelque part dans une bank ?
J'ai jamais regarder ça, votre point de vue m’intéresse

chuckdun a écrit:Yep
Vous intégrez les descrip de maps dans P ?
Ce n'est pas prévu quelque part dans une bank ?
J'ai jamais regarder ça, votre point de vue m’intéresse

Il y a 2 gros défauts à la Neo Geo:
- le stockage des palettes
- le stockage du level design

T'as pas le choix tu dois les mettre dans ton programme P. Pas moyen de bricoler en encodant ça dans des tiles, puisque le proc n'a pas accès à leur contenu, le GPU allant taper directement dedans comme un grand.

Ou bien j'ai raté une grosse astuce de programmation

Cedric
Les map levels complet de Metal Slug, par exemple, rentrent avec le code dans les 64 ko ?
Tu connais bien la Néo maintenant, tu la pratiques depuis un bout
Il y a bien un truc là qui te chiffonnes comme moi ... ?
L'encodage bits à bits permet d'agrandir le stockage mais quand même ...

64ko c'est la taille de la User RAM, c'est la RAM de travail utilisée à l'exécution pour gérer les variables liée au fonctionnement de ton moteur.

https://wiki.neogeodev.org/index.php?title=68k_user_RAM

Le programme P stocké en ROM monte en revanche à 1Mo (sans bank switching), ça permet de stocker en cartouche le programme, les palettes, le séquençage des animations et le level design.

https://wiki.neogeodev.org/index.php?title=P_ROM

Le truc quand on programme en C, c'est de stocker proprement en ROM sans surcharger inutilement la RAM.

Exemple. Tu veux configurer une map de jeu, pour ça tu créés un Array, genre:

Code:

level1 u8[] = {4, 1, 4, 6, 4....}

Cet Array sera alors forcément stocké dans la ROM P après compilation, pas moyen de faire autrement. Par contre ce qui est très con, c'est que cet array, à l'exécution, sera copié en RAM, ce qui est du gâchis de ressources. Et comme la RAM fait seulement 64ko, on arrive vite au bout. Ca c'est parce que le compilo ne peut pas deviner que cet array sert juste de stockage en ROM et qu'on ne souhaite pas modifier ce qu'il y a dedans, et qu'on souhaite juste récupérer/copier ses valeurs de temps en temps.

Il faut donc déclarer cet array en CONST pour qu'il soit laissé tranquille dans la ROM en lecture seule.

Après on peut librement se créer des variables et des array de travail en RAM (sans CONST) pour copier les valeurs du level courant et exécuter le moteur dessus.

chuckdun a écrit:Cedric
Les map levels complet de Metal Slug, par exemple, rentrent avec le code dans les 64 ko ?

Donc non, les levels de MSlug n'ont pas besoin de rentrer dans 64ko, il suffit qu'ils rentrent dans 1Mo. Par contre chaque level pris 1 à 1 rentre sûrement dans 64ko, ainsi le moteur peut le gérer en RAM, et il ne gère qu'un level à la fois.

Et encore il peut y avoir des astuces pour splitter un level en sous-level. Genre si au milieu d'un level tu as un fondu au noir, c'est peut-être pour switcher propement les array en RAM (les palettes aussi).

Oui complétement d'accord pour la diff 1 meg et 64 ko et sur le partage de ressources
Tu penses qu'une map complete de level ca prend quoi ?
OzzyOuzo, sur le mario la map du level 1 ca te fait combien au fait ?

A vue de pif, si un level fait 30 tiles de haut sur 1000 tiles de long, et qu'une tile est encodée sur 1 octet, ça donne un level stocké sur 30000 octets, soit 30ko, on touche déjà presque 50% de la RAM à 64ko.

Par contre 30ko c'est à peine 3% de la ROM à 1Mo. Donc possibilité de stocker une 30aine de levels sans bankswitching.

Evidemment ce ne sont que des estimations et je prends pas en compte la taille du programme pour le moteur, mais en général le premier plafond qui fait mal c'est celui de la RAM, pas celui de la ROM.

Avec l'encodage bit à bit on peut encore descendre avec une bonne table de correspondance et en restant sur des opés logiques
Quoi qu'il en soit en soit quand je vois que sur gameboy on a la notion de maps et que c'est cablé ... je pleure sur la Neo ...

OzzyOuzo,
Si tu passes par là, tu pourrais nous dire ce qui te coutes cher dans la P que ce soit en Rom ou Ram ?

En ROM le stockage peut se faire simplement en notant les répétions de tiles, ça permet de diviser facilement par 5 la taille d'une map.

Au lieu d'avoir 5, 5, 5, 5, 5, 5, 5, 5, 1, 1, 1, 1, on stocke 8, 5, 4, 1. Et ça se décompresse facilement en RAM pour le travail du moteur

Compresser RAM c'est plus subtil, ça dépend comment fonctionne le moteur de collisions.

Les levels de mario ca prend qques Ko, comparativement le sprite de mario c'est deja plus costaud avec ses anims à 60fps et les 700+ frames a se trimballer ^^  mais bon, quoiqu'il en soit pour la prochaine version je vais certainement dépasser le meg de data..

Pis plutot que de bouffer des cycles pour accèder à du data via bitfields ou tailles customs , si je suis à l'aise en mémoire je préférerais en gagner avec des tailles ^2 par ex ;-)

Donc, l'idée c'est que des données soient stockées dans != roms p1 -> p(n)

j'ai pas encore regardé en détail le bazar mais le bank switch te permet de mapper une rom p(n) à l'adresse : $200000~$2FFFFF

la sélection de l'index de la rom se faisant à priori comme indiqué dans la doc , en écrivant un index n'importe ou dans le range mémoire précédent. ex pour la bank 3 : move.b #3,#$200000  

et après il doit falloir ajouter un offset aux adresses des élements/tables en rom pour y accéder correctement.

coté makefile c'est cette commande qui balance les data dans une rom P:

objcopy --gap-fill=0x00 --pad-to=0x100000 -R .data -O binary test.o dev_p1.rom

+ de news sur le sujet dès que j'ai le temps me pencher dessus plus en détail

J'arrive plus vraiment à suivre, ça me plaît
J'ai hâte d'avoir une nouvelle alim pour faire fonctionner la démo sur neoSD

Un jeux Nintendo sur Neo ? pourquoi pas ça peut être fun

Est ce que ça vaudrait pas le coup d'essayer un revese bit overflow en bypass low level? En créant une chaine de bitwise XOR on doit pouvoir gérer plus facilement une structure de patterns condensée.

De ce que j'ai compris, c'est plus une démo technique pour le moment. Histoire d'explorer les contraintes de la neo.
Plus tard, ça pourrait se transformer en autre chose

bonjour OzzyOuzo, prévoi tu une sorti sur mvs de ton mario une fois fini ? en tout cas beau travail à toi, ca donne vraiment envie. quel aurai été le destin de snk si il avait pu avoir de grosse lisence tel mario ou street fighter sur sa consol de salon. prévoi tu un jeu original après ca ?

comme promis, le résultat préliminaire de mes recherches sur la question du bank switch ->

https://github.com/ozzyyzzo4096/ngDataLinker

Pour faire court dans un langage compréhensible par tous, ca permet d'utiliser 9Mo au lieu des 1 ou 2Mo utilisés habituellement lors des productions homebrew.

Et il s'agit de la méthode utilisée dans la version alpha de TeoT qui ne devrait plus tarder. ;-)


Attention : cela nécéssite au final une version modifiée de romwak que j'ai pushé sur https://github.com/freem/romwak mais qui n'a pas encore été intégrée par l'auteur.

Bravo Ozzy
J'ai hâte de voir le résultat avec Teot

En voilà un projet super sympa
J'aime bien l'initiative et franchement, même si c'est un pur produit Nintendo, ça me plairait bien de l'avoir en cartouche sur ma Neo

En tout cas, bravo à toi.

Je suis d'accord c'est un projet super cool, l'idée est géniale ça me laisse rêveur quant à la possibilité qu'il existe un MARIO Arcade.