bon. On y va ... devkitpro réinstallé, les outils "ndstools" et "dsbuild" recompilés depuis le CVS, idem pour les examples (eux aussi repris direct du CVS), cette fois-ci, ça va marcher.
Et en effet. Je jubile: les premières images créées par un programme compilé localement s'affichent sur l'émulateur DeSmuMe ... S'agit maintenant de comprendre comment tout ça marche. Comme quasiment toutes les consoles (GB, SNES, ...), la DS construit ces images en partant d'un certain nombre de "plans de fond" superposés les uns aux autres (BG0...BG3) par-dessus lesquels seront animés des "sprites" (mario, les goombas ...)
comme il y a deux écrans, et en fait deux "processeurs graphiques" quasiment indépendant, on va retrouver une grande partie des commandes en doubles, ainsi,
videoSetMode( MODE_0_2D |
DISPLAY_SPR_ACTIVE | //turn on sprites
DISPLAY_BG0_ACTIVE | //turn on background 0
DISPLAY_SPR_1D //this is used when in tile mode
);
agit sur l'écran du haut et active une couche de fond (par exemple pour du "texte"), et les sprites. Alors que videoSetModeSub(MODE_0_2D |
DISPLAY_SPR_1D_LAYOUT |
DISPLAY_SPR_ACTIVE |
DISPLAY_BG0_ACTIVE |
DISPLAY_BG1_ACTIVE );
active l'écran du bas (l'écran tactile) avec deux couches de décors et les sprites... Il faudra ensuite remplir les infos de tous ces petits pixels dans la mémoire video, qui se retrouve découpé en plusieurs tranches:
- le contenu des plans de fond, qui se programment comme un plateau de "Scrabble" : dans chaque case, vous pouvez mettre une lettre -- sauf que dans ce cas-ci, une "lettre" peut très bien contenir un morceau d'arbre, de mur, un nuage, etc.
- les caractères à utiliser sur le plan de fond (c'est ici que vous décidez si on verra un "A" ou un coin de nuage.
- le contenu des sprites (grosso modo, l'image de Mario en BMP)
- le contrôle des sprites: lequel est affiché où, etc.
Tout cela se règle avec vramSetMainBanks, dont le fonctionnement exact m'échappe encore un peu ...
Evidemment, tout comme on avait "videoSetMode" et "videoSetModeSub", il y aura une mémoire différente pour l'écran supérieur et l'écran inférieur: SPRITE_GFX_SUB, par exemple, définit l'aspect des sprites sur l'écran tactile, alors que SPRITE_GFX sert pour l'écran supérieur ... Idem avec OAM (où sont les sprites, écran supérieur) et OAM_SUB (où sont les sprites, écran tactile).
Le résultat en image: le programe "TestTouch" modifié par les soins de votre serviteur pour afficher la "grosse balle rouge" (là où vous avez cliqué) sur l'écran tactile du dessous aussi bien qu'au dessus. Ca ne sert absolument à rien, bien sûr, et s'il n'était pas 23h33, je passerait probablement un peu de temps à remplacer la balle rouge par une bleue avec des yeux ... ce sera pour une autre fois.
Voilà. Désolé si c'est complètement technique et imbuvable. Je suis un programmeur et on ne se refait pas. Déplacer des sprites sans devoir tout repeindre à la main, ça fait 10 ans que j'avais plus fait ça (la programmation vidéo sur PC, c'est vraiment le summum de l'horreur). 'vais me coucher, maintenant. A+
