developpement master system

[jackselecta 0]

bonjour à toutes et à tous,

Je souhaiterais développer mon propre jeux sur master system. J'ai parcouru des multitudes de sujets concernant ce sujet sur power sms, sur ce forum ...), j'en ai appris pas mal.

Le projet de jeu que j'ai pour l'instant n'a rien de sorcier, je souhaite déplacer une sprite sur x et y via la manette.

 

j'ai bien assimilé que le background était mappé en $3800 de la VRAM, les coordonnées x et y des sprites étaient en $3f00 et $3f80, ainsi que les 11 registres qui permettaient entre autre de scroller le background.

 

Cependant, étant habitué à faire du reverse engineering, j'arrive à lire et à comprendre le langage assembleur (pointeur, registres, flags ...), mais je n'arrive pas à écrire dans ce langage (vraiment pas intuitif au niveau du transfert de données via les registres).

 

y a t il un moyen de coder un jeu via C#, C++ ou VB et ensuite de le compiler pour le z80?

 

merci d'avance

[ichigobankai 183]

Tu peux coder en C via le devkitsms de sverx.
(devkit qui à la base c'est inspiré de notre devkit avec Vingazole)

https://github.com/sverx/devkitSMS/

 

Pour être maintenant "± à l'aise" en ASM, je préfère honnêtement écrire tout ou partie des gestions/transferts de datas en ASM qu'en C où c'est non intuitif et souvent mal compilé.... ;)

[jackselecta 0]

merci pour ta réponse, j'ai souvent utilisé ollydbg, qui m'a permis d'assimiler concrètement les registres x86. Même si les registres ne sont pas les mêmes, le fonctionnement reste similaire (accumulateur, flags, compteur ...)

J'ai pour habitude de me servir de classes, d'objets, tout ce qui est lié à la programmation orientée objet. Seulement, là j'ai l'impression que ce n'est pas possible et rend le code extrêmement complexe (pour ma part).

 

ce qui m'étonne, c'est que pour faire un simple calcul, il est nécessaire de toucher au moins 3 registres ce qui rend le code extrêmement long et à mon point de vue pas optimisé et très peu lisible.

 

Je bloque sur le déplacement d'une simple sprite, alors je n'imagine même pas la gestion des niveaux, des vies, des boss ...

Si effectivement le seul moyen le plus efficace est l'ASM, je pense que je vais préparer les doliprane pour les maux de tête, la perfusion de café et redoubler d'effort :)

[Moons 0]

Bonjour je reviens vers vous pour savoir si depuis il y’a eu de l’avancer ? Moi j’utilise actuellement le DevkitSMS avec le langage C 

[ichigobankai 183]

Sverx rajoute des petits morceaux sur le DevKitSMS et c'est ± le seul kit réellement accessible à tous

Z88dk a pas mal évolué, perso j'ai juste utilisé les premieres versions et c'était pas folichon (optimisation à la ramasse, SDCC c'était pareil), mais c'était y'a pas mal d'années.

Perso j'utilise toujours ma propre lib mix SDCC + WLA-DX (non dispo publiquement)

Apres tout dépend de ce que tu attends de ces lib, si tu veux optimiser (vitesse et/ou place) ou faire des trucs borderline, le C restera toujours loin derriere l'ASM.
Les compilos n'étant pas vraiment magique et dépendent de la façon de coder en C.

[Moons 0]

Le 25/12/2023 à 14:28, ichigobankai a dit :

Sverx rajoute des petits morceaux sur le DevKitSMS et c'est ± le seul kit réellement accessible à tous

Z88dk a pas mal évolué, perso j'ai juste utilisé les premieres versions et c'était pas folichon (optimisation à la ramasse, SDCC c'était pareil), mais c'était y'a pas mal d'années.

Perso j'utilise toujours ma propre lib mix SDCC + WLA-DX (non dispo publiquement)

Apres tout dépend de ce que tu attends de ces lib, si tu veux optimiser (vitesse et/ou place) ou faire des trucs borderline, le C restera toujours loin derriere l'ASM.
Les compilos n'étant pas vraiment magique et dépendent de la façon de coder en C.

Salut moi pour l’instant je suis satisfait du DevkitSMS avec le langage C , en tout cas je ne verrais pas de différence si je codais mon jeu en Assembleur… mais j’aimerai apprendre à coder en assembleur pour la master system juste pour voir si vraiment ça change quelque chose.

[ichigobankai 183]

La différence saute au yeux quand on regarde le fichier ASM généré par SDCC, car c'est assez vite dégueulasse (utilisation de la stack et du registre IY pour tout et n'importe quoi) et forcément ca impact (± beaucoup) les perfs selon les cas. Le vrai gain de l'ASM à la main, c'est la place (et ca y'a pas photo), de plus, en toute logique +compact = +rapide ^^ (meme si c'est pas 100% vrai selon le langage). Perso j'arrive toujours à un gain d'au moins 30% entre le C d'origine et l'ASM fait à la main (en terme de vitesse/cycles)

Mieux vaut plusieurs petites routines en C qu'un gros morceaux, car SDCC génère vite du gros n'importe quoi dans les gros morceaux de code. Evidemment, le fait de couper en plusieurs sous-routines peut normalement aussi améliorer globalement le code si ces morceaux sont réutiliser plusieurs fois (quitte à y passer 1 ou 2 paramètres pour les rendre flexibles)

Comme je le dis souvent le C c'est très bien, et suffisant pour certains dev "pas trop exigeants" (peu de chose à l'écran a un instant T). Mais dans d'autres cas c'est juste pas possible (des que tu vas taper dans des trucs borderlines et vouloir sortir au max ce que peut faire la console, et je ne parle pas de juste un effet à l'écran mais de gérer un jeu complet)