[Proto]The Depths of Darkness

Bonjour à tous.

Je viens vous présenter mon projet de homebrew qui en est encore au stade d'embryon.
Notamment pour avoir quelques conseils sur certains aspects du développement SMS

Le jeu vas s'apparenter a un puzzle game style Sokoban (par exemple) maquillé en Crawler/RPG

Le joueur devras traverser un certains nombre de tableaux en choisissant le bon chemin pour évoluer a travers le jeu. Il devrais faire façe a des monstres, des pieges et des portes. Il pourras ramasser des potions, des clés, etc...
Le but étant de traverser tout les tableaux.

Je n'ai pour l'instant pas trop réfléchit au Lore du jeu, mais ça devrais s'inspirer de ce que fait la serie de jeu Ultima ( que j'adore )

J'ai vraiment envie de faire aboutir ce jeu et si je rêve un peu en sortir des versions boites, mais j'en suis pas la encore

Voilà un petit aperçu que de ce que donne pour l'instant :




Concernant le developpement, j'utilise le devkitSMS pour coder en C.


Ma première question est des plus simples :
je n'ai pas tout a fait compris les limitations de taille.

Apparemment je ne peux avoir que 16k de code ( ca devrais être suffisant que ce que je veux faire ) ?
Mais du coup je peux avoir combien de data ? J'ai lu beaucoup de choses très différentes donc je suis un peu perdu.
Certains disent qu'on peux monter a 1M , d'autres disent que le maximum légal est 512k ?
Et avec tout ça la compilation via le assets2banks m'interdit d'avoir des ressources de plus de 16k...

Bref je suis un peu paummé,je précise que je suis developpeur de metier mais que j'ai qu'un leger background en electronique mais je reste très novice dans ce domaine.

Merçi de vos conseils

Wahou sympa comme projet! T'as pas une petite démo à partager?

Ichigobankai saura t'aider je pense, mais d'après moi  la limitation pour un jeu est de 4Mo (même si le jeu le plus gros connu fait 1Mo) et je vois pas pourquoi il y aurait une limitation de code à 16Ko, ton truc gère pas les mappers? Sans mapper t'es limité à 48Ko.

Salut Naarshakta,

J'y connais rien en développement, je ne pourrais donc pas t'aider, mais en tout cas visuellement et en terme de concept ça me branche bien!!!
N'hésite pas à nous tenir au courant des avancées de ton projet...je suis curieux de voir le résultat

En général on utilise 32ko de code fixe (slot 0 et 1) et on utilise/switch le slot 2 pour charger la musique, datas etc.


pour un petit jeu comme ca (rien de péjoratif), 32ko de base + quelques bank pour les gfx/musiques devraient suffire (genre 128ko au final, et 128ko faut déjà les remplir)

pour la taille max, le mapper sega était de 512k sur la tres grand majorité des jeux, 2 / 3 jeux sont montés à 1Mo (Virtua Fighter, Street Fighter 2).
Mais on peut monter jusqu'à 4Mo (32Mbits) en étant toujours compatible avec les infos du mapper Sega.
Après un "mapper", en réalité, on peut faire ce que l'on veut (genre avoir 40ko fixe et 8 ko swappable)
bon par contre faut aussi modifier un émulateur pour pouvoir tester ses dev tranquillou !

pour devkitsms par contre je ne pourrais pas trop t'aiguiller, je ne l'utilise pas pour mes devs.
mais si tu as des questions, va sur le discord de SMSpower, Sverx pourra te répondre vu que c'est son bébé ^^
https://discord.gg/h5xrKUK

ichigobankai a écrit:

pour un petit jeu comme ca (rien de péjoratif)...

Pas de soucis, c'est bel et bien un petit jeu ^^

Pour les tailles, c'est bien ce qu'il me semblais oui.
Question taille de code, je ne devrais pas avoir besoin de plus de 16k donc ca devrais le faire sur un seul slot.
J'ai pas encore tout bien compris mais ca viendras.

Si je me base donc sur un schema "classique" admettons 128ko de data.
Ca veux donc dire que j'aurais des 8 bank de 16k chacune ?

@Révo : non désolé par encore de démo, c'est trop tôt ^^ mais je commenterais l'avancement du projet sur ce topic ^^

PS : Oui j'ai prévu d'aller discuter avec Sverx pour voir comment s'articule sa lib

oui 128k ca fait bien 8 bank de 16ko
tu retires à ces 8 banks les 1 ou 2 premieres bank (pour le code fixe).

Je connais pas assez bien la lib de sverx, mais y'a des chances que 16ko soit quand même vite remplie (car ya pas mal de fonctions - et de mémoire en C - et pas sur qu'elle se virent à la compilation si non utilisées)

Nouveau screen posté sur smspower, magnifique!

Ça fait envi

Y a une bonne gestion des couleurs pour les murs, l'eau et l'association des 2.

J'aurais préféré le HUB en bas, je sais que notre sens de lecture est de gauche à droite et haut en bas mais quand on prend de l'âge, on a tendance à regarder l'écran vers le bas. ~~'

J'y avais pas pensé mais maintenant que tu le dis...c'est vrai que je le verrais mieux en bas le HUB

Désolé de la réponse tardive j'étais absent quelques jours.

Le HUB est en haut pour l'instant car je me calque avec un jeu inconnu nommé Zelda
Cela dit rien n'est figé il est possible qu'il change de plaçe au cours du developpement ^^

J'ai rien contre le HUB en haut mais je remarque que je suis plus à l'aise quand celui-ci est en bas.

Soit je deviens trop vieux, soit c'est juste les jeux de nos jours qui ont les 3/4 du temps le HUB en bas. Ce qui m'a habitué à mieux apprécier celui-ci.

Bon courage pour l'avancement de ton jeux.

placer le HUD en haut est surtout une question de simplicité (de code) !
la SMS peut locker les 2 premieres lignes horizontales afin que cela ne bouge pas pendant un scroll (lui aussi horizontal)
le mettre en bas n'est pas du tout aussi simple ^^
(à moins de faire le dev à la main et encore faut jouer avec les interruptions généralement en ASM pour avoir quelque chose de précis et rapide)

Genre jouer les interruptions de cette façon
https://youtu.be/SQPvA0OvR24?t=1973

en sachant qu´il y a une modification de palette quand sonic est dans l´eau, si j´ai bien compris l´astuce.

ichigobankai a écrit:

placer le HUD en haut est surtout une question de simplicité (de code) !
la SMS peut locker les 2 premieres lignes horizontales afin que cela ne bouge pas pendant un scroll (lui aussi horizontal)
le mettre en bas n'est pas du tout aussi simple ^^
(à moins de faire le dev à la main et encore faut jouer avec les interruptions généralement en ASM pour avoir quelque chose de précis et rapide)

Je savais pas du tout ^^
Mais pour l'instant je découvre encore l'architecture...
Je n'ai pas testé les défilements et j'ai encore du mal a cerner comment cela fonctionne.

J'ai pensé à toi, j'ai du coder un changement de palette mid frame pour mon portage GG



en mode VS on aura la possibilité de jouer avec n'importe quel perso, sauf qu'avoir 2 démons pose un souci : une couleur est modulable pour varier la couleur de peau.
Du coup obligé de rajouter une tartine de code pour faire changer une couleur de palette à mi-écran via une interruption (et la restaurer ensuite une fois arrivé dans le vblank)

Dans la capture au dessus, sans changement, la Succube aurait eu la peau verte comme le Gobelin

On voit mieux le bordel dans ces captures
au départ de l'affichage, ligne 0:

à la ligne 104:

une fois dans le vblank, à partir de la ligne 192:

Énorme! Du coup c'est grâce à cette technique qu'on peut afficher les 64 couleurs à la fois sur un écran?

exactement

Magnifique

Peut être que naarsh va avoir une idée pour utiliser cette petite douille.

ichigobankai a écrit:

Du coup obligé de rajouter une tartine de code pour faire changer une couleur de palette à mi-écran via une interruption (et la restaurer ensuite une fois arrivé dans le vblank)

Ah ouais ! alors la il faut que tu m'expliques un peu
Qu'est-ce que tu appelles les interruptions ? tu as un exemple de code a me montrer ?

PS : ton jeu est hyper joli c'est beau

c'est un poil "complexe" et surtout du full ASM...

y'a 3 fonctions,
celle qui allume l'écran et active les interruptions de lignes

Code:

ld a,#0x16 //enable horizontal interrupt
(#0xBF),a
a,#0x80
out (#0xBF),a
ld a,#103 //line - 1
out (#0xBF),a
ld a,#0x8A //Register 10 line interrupt @line 104
out (#0xBF),a

celle en 0x38 (où saute automatiquement l"interruption) et qui va changer la couleur du perso en bas

Code:

push af
in a, ($BF) //clear pending interrupt
ld a, ($C42C) //test if pal midframe enabled
or a
call nz, $D800 //le code de changement de couleur de palette a été copié en ram au demarrage puis y est executé (car ne loge pas entre $38 et $66)
pop af
ei
ret

enfin la fonction de vblank (vbl) qui va restaurer la palette pour la prochaine frame

Code:

1$: halt //on attend la fin de l'affichage actif (cad debut du vblank)
in a, (#0x7E)
bit 7, a //test si la ligne est bien = 192 (interruption de frame étant activé ces 3 lignes n'étant normalement pas necessaire, mais avec l'interruption de ligne activé pour le changement de palette c'est obligatoire de tester)
jr z, 1$

/*
Plein de code perso
*/

call _restore_pal //saut vers une fonction qui remet la bonne couleur de la palette

Ok je vois, en fait c'est une callback qui est appelée lors du dessin la la ligne X
C'est donc comme ça qu'il font les effets de couleur avec l'eau dans Sonic ^^

Une idée de ce qu'on peux faire dans cette interruption ? Içi tu changes la palette mais est-ce qu'on pourrais pas exemple charger d'autres sprites ?

tu peux faire ce que tu veux, mais ca met ta boucle principale en "pause" donc faut faire gaffe à pas trop charger.
les cas classiques c'est changement de couleurs ou decalage du scroll (pour faire du raster effect)
Après les sprites c'est plutot lourd comme truc, normalement on gere les calculs pendant l'affichage actif et on balance la maj des positions etc dans le vblank (via des intructions OUTI entre autre)

Autre exemple, avec mon pote Vingazole on a aussi utilisé les interruptions pour jouer des samples en temps réel (et plutot propre, avec un "vrai" moteur de jeu assez conséquent qui tourne).

https://www.smspower.org/forums/17613-RickDangerousWIPDemo

Les interruptions se déclenchent toutes les 3 lignes (de mémoire, c'est peut etre 4) pour mettre à jour la lecture de samples (si il y en a un d'activé), c'est chaud à caler car pour le coup faut compter tous les cycles pour etre synchro et loger dans le hblank, le pire étant le vblank, entierement codé en ASM avec boucle dépliée et tous les cycles comptés pour tomber juste (sinon ca sonne faux)

Sur youtube en français tu peux trouver la chaîne de yupsilandre https://upsilandre.over-blog.com/
Il fait plusieurs vidéos sur des systèmes de l'époque 8/16 bits, même vieux micro, il a un blog et Twitter facilement trouvable sur Google.

Tu peux apprendre / comprendre comment les développeurs de l'époque faisaient certains trucages.

Y a aussi un live avec yannosh 51 qui traine sur youtube.

Y a aussi
https://www.gamekult.com/forum/t/ou-sont-les-sprites-patrick-juvet-1977/345355?page=3
Le sujet reste une bonne source de trouvaille en FR.

En anglais y a plusieurs sites mais globalement les 3/4 sont surtout au niveau des 16 bits. Toujours sur youtube tu as gamehut / coding secret un vieux développeur qui aime la megadrive, il donne max d'infos sur les secrets de développement de l'époque ( même pour la saturn), certains sont possibles sur 8 bits mais avec max de contraintes ( si j'ai bien compris les différents commentaires des vidéos)

Je sais plus si je l'ai récupéré ici ou sur sms power mais y a une doc sms traduite en français, mais original disponible, j'ai regardé en vrac ça me semblait compréhensible.

Petit bonus 2 topics que j'adore sur gamopat

https://www.gamopat-forum.com/t68638-le-genie-des-graphistes-des-annees-80
https://www.gamopat-forum.com/t81724-moteur-de-jeu-de-course-en-2d-pseudo3d

Et si tu veux faire un jeu de plateforme sans trop codé y a revo qui avait fait un tuto rapide sur kidded https://www.gamopat-forum.com/t90461-tutoriel-video-kidded-editeur-alex-kidd-in-miracle-world-sms#2482527

Désolé un peu en vrac mais pas facile pour moi de faire un long message sur un écran 5 pouces.

Merçi pour les liens je vais regarder tout ça.

Perso ce qui me plait c'est justement le dev donc j'ai pas peur de prendre les choses frontalement
Par contre je dev uniquement en C, l'assembleur je sais faire mais j'en ai trop fait dans mon boulot et j'ai fais une overdose lol