Faire des jeux sur DS

[PypeBros 2]

Salut à tous. Ceux qui se souviennent de moi savent que je fais des jeux et des outils sur DS. Les autres l'ont devinés grâce à leurs pouvoirs Sherlockiens en lisant le titre. De quoi donc vais-je parler ?

 

Mais de vous. Est-ce que vous autres, ici, vous auriez envie que je vous fasse un p'tit tuto sur la manière dont on avance pour faire un jeu DS ? (basé sur mes outils et ma bibliothèque open-source, évidemment).

 

(et quel serait le bon coin du forum pour installer ça ?)

 

style:

 

jour 1 : le setup

 

 

Il vous faudra d'abord le kit de développement non-officiel pour NDS et GBA. Ils ont fait du bon travail et il y a un installeur automatique pour ceux qui travaillent sous Windows.

De mon côté, j'ai préparé une structure d'accueil pour les programmes. Règles de génération des ROMs nds à partir des sources et des données du jeu, les petites bibliothèques supplémentaires pour faire de la musique, etc. Et un un premier programme à faire tourner sur DS. Evidemment, on est sur une machine "bare metal", sans système d'exploitation, donc il y a un peu plus de code d'initialisation qu'à l'habitude, mais le fait de créer un objet "Engine" fait déjà une grande part du travail.

 

jour 2 : les décors

 

 

Vous avez tous déjà utilisé un éditeur de donjons RPG où l'on travaille carré par carré (je crois qu'on dis volontiers des 'chips' ?) plutôt que de mettre un arbre ou une maison d'un coup. Le mode texte de la DS va un cran plus loin: la mémoire de la machine elle-même est découpée en une région pour retenir des pavés de 8x8 (le 'tileset') et une région pour indiquer quel pavé montrer à quel endroit (la 'map' de l'écran, couvrant généralement 256x256 pixels pour la DS). Parfois, on mettra le même tile à plusieurs endroit de l'écran (en inscrivant juste son numéro dans plusieurs cases de la map), et parfois un tile ne sera pas repris (pour l'instant). C'est une technique a peu près aussi vieille que les machines 8-bit et qui a perduré pendant toute la période 16-bit (mais ça, c'est une autre histoire)

...

 

 

 

 

jour 3 : les sprites

 

 

Les sprites ont besoin de données graphiques (des valeurs de couleurs) tout comme les décors, et ces données sont de nouveau constituées de "tiles". On va utiliser surtout des blocs de 16x16 pixels ici (et donc constitués de 2x2 tiles) mais la DS peut en réalité utiliser des sprites de 8x8 à 64x64 pisxels (avec quelques restrictions quand-même).

Mettre à jour la mémoire vidéo pour que les sprites s'affichent à l'écran (quels graphismes, quels réglages, etc) est délégué à la classe SpritePage dans la libgeds, et la fonction "sync()" de GuiEngine fera le nécessaire pour mettre à jour les coordonnées en respectant les timings de la puce vidéo (et faire en sorte que ça ne clignote pas, par exemple).

 

 

[siegounet 5]

j'aurai adoré savoir faire ça sur la SNES.

je n'ai jamais trouvé qu'un tuto sur developpez.com mais il est, pour moi, imbitable ^^" dommage

[PypeBros 2]

Pas mal de choses sont très proches entre les deux, mais c'est clair que sur SNES, ce serait beaucoup plus chaud.

- le choix des langages est plus limité. Il y a bien un compilateur C, mais sinon c'est assembleur. Rien qu'assembleur et pas particulièrement pour le processeur le plus sexy.

- on a nettement moins de mémoire, donc il faut ruser nettement plus.

- on a moins de couleurs (des palettes de 16 alors que la DS nous en donne jusqu'à 256 par palette).

- aucune idée de la façon dont on programme le son, mais ça semble moins confortable que la DS (qui fait penser à un quatuor d'Amigas survitaminés).

 

Entre les deux, il y a la programmation GBA...

 

Mais oui, régulièrement je me dis que si je pouvais faire tourner mon p'tit jeu sur SNES, ce serait quand même un fameux achievement. 'faudra que je regarde un peu du côté de [url=https://github.com/alekmaul/pvsneslib]ce qu'a fait l'ami Alekmaul[/i]...

[M0nsieurL 40]

Porter bilou sur snes, il faudrait au moins utiliser le super fx pour faire les effets de balançoires des petits nuages jaunes...

 

T'es doué, c'est sur, mais il faudrait aussi revoir le nombre d'ennemis à l'écran à la baisse !

[PypeBros 2]

Porter bilou sur snes, il faudrait au moins utiliser le super fx pour faire les effets de balançoires des petits nuages jaunes...

 

T'es doué, c'est sur, mais il faudrait aussi revoir le nombre d'ennemis à l'écran à la baisse !

Pour les cordes des éponges, je pense à un système avec quelques sprites avec des angles pré-rendus ... soit ça, soit des petits pointillés.

 

Tu connais la limite de sprites affichables à l'écran ? Je sais qu'il y a une limite de 10 objets (ou quelques) dans Super Mario World, mais ça n'avait pas l'air lié au hardware vidéo lui-même ...

[PypeBros 2]

avec mes outils de tests, je compte jusqu'à 70 objets (/128 pour DS, et on dirait bien que c'est pareil sur SNES)

 

PS: il n'y a vraiment pas moyen d'éditer ses posts, ici ?

[ichigobankai 197]

si, sur modifier, et au besoin, ensuite sur "utiliser l'éditeur complet"

[M0nsieurL 40]

LA bible snes pour les codeurs, c'est là.

 

Il me semble que c'est 128 sprites de 8*8.

[PypeBros 2]

Hmm. Intéressant. C'est presque le même formattage que celle pour DS ^_^

 

Par contre,

 

2101h - OBSEL - Object Size and Object Base (W)

  7-5   OBJ Size Selection  (0-5, see below) (6-7=Reserved)         Val Small  Large         0 = 8x8    16x16    ;Caution:         1 = 8x8    32x32    ;In 224-lines mode, OBJs with 64-pixel height         2 = 8x8    64x64    ;may wrap from lower to upper screen border.         3 = 16x16  32x32    ;In 239-lines mode, the same problem applies         4 = 16x16  64x64    ;also for OBJs with 32-pixel height.         5 = 32x32  64x64         6 = 16x32  32x64 (undocumented)         7 = 16x32  32x32 (undocumented)

Mais je ne saurais pas encore dire si c'est un réglage global ou local.... ah ? ...

 

After above 512 bytes, additional 32 bytes follow, containing 2-bits per OBJ:

  Bit7    OBJ 3 OBJ Size     (0=Small, 1=Large)

On a donc droit à deux tailles par mode, et chaque sprite peut choisir l'une ou l'autre. Il faudrait que j'en lise plus avant d'annoncer que "bien sûr, on peut utiliser le truc de la reporgrammation pendant les interruptions pour augmenter le nombre de sprites à l'écran", vu qu'un des registres pour l'accès à la mémoire des sprites a l'air d'avoir un comportement un peu bizarre.

[PypeBros 2]

Pour ceux que le mot "registre" effraie déjà, j'ai un petit sketch de Bilou et Bouli échoué sur les plage d'adresses mémoire de la DS.

 

La version avec le texte (manuscrit, désolé) est sur google drive. (et la page 2)

[M0nsieurL 40]

J'aime bien la patte graphique, mais j'ai toujours rien bité à l'histoire des registres :D

[PypeBros 2]

même avec le texte de la version Google Drive ?

[M0nsieurL 40]

Je n'ai pas assez de base en programmation pour tout saisir, mais c'est de ma faute, je n'arrive pas à débloquer de temps pour m'y mettre sérieusement :/

[PypeBros 2]

En attendant de pouvoir "montrer" le fonctionnement des registres, voici toujours le transistor ;)

[M0nsieurL 40]

Transistor pnp ou npn ?

[PypeBros 2]

Transistor pnp ou npn ?

plutôt CMOS, comme à l'intérieur des puces. PNP et NPN sont basé sur de la polarisation et plus utilisés en amplification analogique. CMOS sont plus basés sur une barrière de potentiel. Ils n'ont pas ce côté "sens unique": une fois qu'on a attiré assez d'électoons pour rendre la barrière conductrice plutôt qu'isolante grâce à la charge appliquée "sur l'oeil", je pense que les électoons peuvent traverser le "pont" dans un sens comme dans l'autre selon la différence de potentiel appliquée. (attention, je ne suis pas électronicien).

[PypeBros 2]

On dirait bien que j'ai dessiné le "NMOS", qui "dort bouche fermée" alors que le PMOS, lui, dort "bouche ouverte" et ferme la bouche lorsqu'il voit des électoons. la technologie CMOS n'étant rien d'autre que la possibilité d'utiliser aussi bien l'un que l'autre sur le même chip de silicium.

[PypeBros 2]

Et donc voilà. Un registre, c'est ça. Quelque chose qui ressemble un peu à une zone de mémoire, mais qui en réalité est soit un chef d'orchestre soit un espion de ce qui se passe dans le HardWare.

[X-death 42]

Je croyais qu'un registre était juste une mémoire à accès rapide et ne pouvait pas interagir avec d'autres circuits ?

[PypeBros 2]

Je croyais qu'un registre était juste une mémoire à accès rapide et ne pouvait pas interagir avec d'autres circuits ?

C'est correct pour les registres internes de l'unité arithmétique du processeur. Les registres de calcul, en somme. Mais pour la plupart du reste d'une console (registres vidéo, registres d'entrée/sortie, registres son, etc), ils se trouvent en réalité en-dehors du processeur.

 

On y a accès (depuis le processeur) à travers le bus mémoire. le CPU de la SNES ne sait pas s'il écrit dans un registre du chip graphique ou dans une cellule de sa RAM. Mais le registre dans le chip graphique a bel et bien une "face cachée" qui va être utilisée pour la logique de rendu des images. Sa valeur n'est pas utilisée uniquement par la logique "interface avec le bus mémoire" mais aussi pour les besoins internes du chip: activer ou désactiver les bons transistors. Ils utilisent la même technologie de mémoire à accès rapide, mais seulement du point de vue de la logique qu'ils contrôlent. Le PPU de la SNES doit pouvoir tester lire très rapidement (et très souvent) la couleur de fond, par exemple. Du point de vue du programme sur le CPU, il faut passer par le bus mémoire, attendre que la logique de gestion du bus dans le PPU réagisse, etc.

[PypeBros 2]

Bon, bien sûr, là, on est dans le cas idéal des "registres mappés en mémoire". La DS a un bus d'adresses 32-bit (4Go) contre seulement 4Mo de mémoire physique et moins d'1Mo d'adresses utilisées pour la communication avec le reste du hardware. Donc dès qu'on a besoin d'un registre pour la couleur du fond, la longueur d'un sample sonore ou le niveau de transparence du plan 2, on utilise une adresse rien que pour ça. Du coup on se retrouve avec des choses du genre

 

   BG_PALETTE_SUB[4]=RGB(16,0,16);
   SCHANNEL_LENGTH(4) = 0x42;
   REG_BLDALPHA = 0x1008;

 

Même pour la mémoire vidéo, l'entièreté des 640Ko est directement accessible au CPU.

 

Comparativement, sur les console 16-bits, La quantité de mémoire disponible se compte en poignées de 64K. On va donc retrouver quelques traces d'un "truc" indispensable sur les systèmes 8-bit: une paire "registre d'adresse, registre de données" pour chaque composant annexe. Ainsi, pas question d'écrire directement dans la palette de couleur de la Mega Drive depuis le 68000. On doit indiquer dans le registre de données du PPU notre valeur "RGB(16,0,16)", puis l'équivalent de BG_PALETTE_SUB dans le registre d'adresses du PPU (ou dans l'autre ordre, notez bien: je ne fais pas de la programmation MD pour de bon). Cette fois-ci, la logique derrière ces deux registres aura pour effet d'aller modifier un troisième registre du PPU pour qu'il retienne la bonne couleur.