Programmation Master System en Assembleur + variante en C

bravo c est deja ca !

Un petit pas de franchi , affichement d'un background moche + un sprite de 3tiles de hauteur tres moche (la sorte de bout de bois marron).

Cela semble vraiment ultra galère tout de même (pour un gars comme moi en tout cas).

La programmation en c n'est pas particulièrement difficile ( c'est pour ça que je préfère commencer par là , même si apparemment on est assez limité techniquement) , par contre c'est autre chose en assembleur , ça devient vite le bazar. Je trouve que les tutoriels de garzul sont très sympa pour débuter en programmation master system .

La doc master system traduite par vingazole est interessante pour comprendre le fonctionnement de la master system et connaitre certains parametres que tu emplois dans ton code. Exemple tout bete , ca sert a rien d'essayer d'afficher une image de 500*600 si tu ne peux afficher que 256*192 pixels. Il y'a d'autres documents sur lesquels s'appuyer mais celui ci a l'avantage d'etre en francais donc indispensable (en plus il est dispo sur le forum   

Ca y'est ca bouge. Le bout de bois est devenu un petit bonhomme , j'ai utilisé la couleur transparente pour délimiter les contours , et le personnage peut se deplacer a droite ou a gauche ( il suffit d'ajouter ou retirer 1 aux coordonnées x des positions des sprites selon que l'on appuie a droite ou a gauche).
Petite video pour accompagner , attention ca pique un peu les yeux ,  

plutot bien pour un début !

ouais classe !

Bien.

  

C'est le temps la clé de tout apparemment.

En fait, pour la programmation d'un vrai jeu Sms ou Megadrive, comme ceux que l'on a dans nos collections, je ne vois pas quelqu'un se lancer dedans si il ne compte pas le vendre au bout.

Cela semble être un boulot à part entière.

Juste à titre d'information, un jeu comme Streets of rage 1 Megadrive est il programmé sous assembleur, ou sur c.

Tous les jeux à l'époque étaient probablement programmés en assembleur, il n'y avait pas les outils de développement amateur qui ont été créés depuis.

je suis d'accord , pratiquement sur que les développeurs utilisaient l'assembleur , par contre pour l'édition des graphismes , musiques , aucune idée des logiciels qu'ils pouvaient utiliser à l'époque .

pedro76 a écrit:

je suis d'accord , pratiquement sur que les développeurs utilisaient l'assembleur , par contre pour l'édition des graphismes , musiques , aucune idée des logiciels qu'ils pouvaient utiliser à l'époque .

Je pense que ils y a une syntaxe pour les graphismes sur la master system, onc pas sûr que ils passaient par un logiciel

Ma copine est venue a la rescousse pour s'occuper des graphismes , elle trouvait mon perso trop moche. Bon c'est vrai maintenant c'est un peu plus joli.


Pour l'instant , en ce qui concerne l'affichage background , sprite et déplacement basique de sprite , le z88dk  est plutot simple et fonctionne bien , on va voir ce que ca donne pour la suite.

pour la partie graphismes/son, presque sur que chaque boite développait ses outils d'importation/conversion.

Sinon ca a de la gueule !
Jusque là j'ai fait "pareil" (enfin obtenu la meme chose), c'est la partie maj du SAT (sprites) - où je merdais (mettre à jour la table des sprites quand un perso bouge par exemple, maj en temps réel et pas "stocker" toutes les phases d'anim).
Bon après j'ai pas cherché 10 ans non plus... ^^

C'est en voyant ton exemple de megaman que m'est venu l'envie de commencer par le c au lieu de l'assembleur ( j'ai été carrément bluffé par la cascade ). Pour l'instant le programme est assez simple a lire alors que si j'étais en assembleur je me serai bien pris la tete de nombreuses fois pour en arriver là. Vu que les librairies du z88 sont en assembleur il doit etre possible de les modifier ou d'en creer des nouvelles s'il y'a des problemes.
Bon pour l'instant j'en suis pas du tout la , on verra par la suite .

Petite video de l'avancement , le personnage se tourne selon la direction qu'on lui donne.

c'est bon ça !

C'est tout mignon en plus

c est clair c est bien beau

Merci beaucoup pour vos commentaires , c'est très encourageant .
Par rapport à mon utilisation du z88 , je me suis déjà aperçu de plusieurs limitations lors de l'utilisation des tiles en background par rapport au manuel de référence traduit par Vingazole.
Dans l'état actuel des choses ( sans modification des librairies master system du z88dk ), pas de possibilité de flipper le caractère horizontalement ou verticalement , un seul set de couleur disponible sur les deux , les sprites masquent automatiquement le background ( pas de possibilité de mettre un décor devant le sprite snif) .

Tres bon boulot pedro76. Tu as galere pour en arrive la ou pour l'instant ca va? J'aimerai comprendre le code mais c'est trop prise de tete pour moi   

pedro76 a écrit:

Merci beaucoup pour vos commentaires , c'est très encourageant .
Par rapport à mon utilisation du z88 , je me suis déjà aperçu de plusieurs limitations lors de l'utilisation des tiles en background par rapport au manuel de référence traduit par Vingazole.
Dans l'état actuel des choses ( sans modification des librairies master system du z88dk ), pas de possibilité de flipper le caractère horizontalement ou verticalement , un seul set de couleur disponible sur les deux , les sprites masquent automatiquement le background ( pas de possibilité de mettre un décor devant le sprite snif) .

J'ai jeté un oeil sur ce z88, j'ai l'impression qu'il n'y a pas grand chose d'implémenté pour gérer notre console adorée

Je vais essayer de voir si je peux résoudre ton problème

C'est bien sympa tout ca ^^

pedro76 a écrit:

Dans l'état actuel des choses ( sans modification des librairies master system du z88dk ), pas de possibilité de flipper le caractère horizontalement ou verticalement , un seul set de couleur disponible sur les deux , les sprites masquent automatiquement le background ( pas de possibilité de mettre un décor devant le sprite snif) .

Tu parles de quoi tiles ou sprites ?
Je ne me rappel plus des limitations de z88 mais les sprites on ne peut pas les flipper et n'utilisent que la palette n°2.

Je parlais du background mais en effet c'est exactement pareil pour les sprites , c'est basé sur le même principe , une palette background ou sprite , un tile que l'on affecte , une position sur l'écran et pis basta).
Pour le problème de décor devant un sprite , j'ai trouvé une petite astuce , si je déclare par exemple une colonne en sprite , mon personnage en le deplacant peut se retouver au meme endroit que cette colonne, et lorsque deux sprite se retrouve au meme endroit il y'en a qu'un seul d'afficher (logique) , il y'a une priorité d'affichage selon la déclaration du tile.

Sinon pour répondre à revo, honnetement pour l'instant où j'en suis , c'est très simple , je vais mettre la source commentée bientot , comme ca tout le monde pourra bouger son petit bonhomme .
Pour le code , c'est presque du francais, ( en gros tu charge des images et tu dis où les placer) .
Pour les outils graphiques , j'utilise paint , paint.net et bmp2tile ( incontournable , parce que coder ses images à la main c long et fastidieux , je le faisais sur des images en 2 couleurs pour comprendre le fonctionnement ).

Bon la cette semaine je vais essayer d'avoir une surface de jeu de 2 écrans , rajouter des anims et décor , comprendre comment fonctionne le son sur la master system et pîs peut etre essayer de trafiquer un peu les librairies.

si j'ai le temps aujourd'hui, je ferais un essai avec un export d'un des ecrans de lost raider car j'ai bcp de flip + 1er plan.