"640K should be enough for everybody"

L'an dernier, déjà, Gédéon (eh oui, encore lui) attirait mon attention sur quelques pavés disgracieux dans le bas de l'écran de jeu. Rien de bien grave, pensais-je alors: j'ai juste oublié de supprimer les boutons "beam in/beam out" dans mon "runner".

Sauf que dans Apple Assault, c'est un bon quart de l'écran qui disparaît (un peu moins sur DS), rendant les instructions peu lisibles sur émulateur.

You sure have noticed that ugly purple area in the bottom of the "menu screen", and maybe you've noticed it doesn't show up (or not as much) on real hardware. I initially thought this was due to some GUI code from runme that was still hanging around, but a debugging session proved the painful reality: I'm overspending my 128K VRAM budget. By a mere 4K, but that's unfortunately enough to doom the visual output -- or to trash the precious ASCII character set when the game is run by runme-on-R4.

J'ai donc ressorti mon kit du parfait débuggueur histoire de voir un peu où les choses tournent de travers... pour me rendre compte qu'apparamment tout va bien. Ouais... Sauf que:

• 980 tiles pour les troncs, branche, terre, tout ça: 64Ko
• 587 tiles pour aahowto.spr (l'image de fond) : 36Ko à vue de nez.
• 4 maps 64x32 pour les faire le scrolling : 16 Ko
• Les caractères ASCII et les "layers standards" du GuiEngine (surtout utile pour runme): 16Ko
• total : 132Ko alors que la VRAM n'en offre que 128 pour ce genre de graphismes.
  

Bref, les tiles constituant l'image "aahowto.spr" sont placé en-dehors de la zone de mémoire normalement prévue pour eux. Sur hardware, les bits de poids fort sont ignoré (le hardware adore faire ça: ça veut dire que si vous mettez une barette de 1Mo et que vous demandez à écrire à l'adresse 1Mo+42K, vous écrasez en réalité ce qu'il y avait au début de votre mémoire, à l'adresse 42K) et les majuscules sont écrasés par le fond d'écran (rendant délicate l'utilisation du reste de runme :P).

L'émulateur, lui, ne fait rien de tout ça. Les données que j'ai écrites au-delà des 128K sont perdues, et le contenu de l'écran utilise à la place des "pavés tout vides" -- donc du mauve qui fait tache.

La bonne nouvelle, c'est que aahowto.spr n'utilise que 14 ou 15 couleurs. Je devrais donc pouvoir le convertir en un layer 16 couleurs (au lieu de 256) et diminuer de moitié sa consommation de VRAM. Il y aurait bien d'autres solutions également (après tout, je ne déborde "que" de 75 tiles, or j'ai 44 tiles inutilisées sur les avant-plan et l'équivalent de 64 tiles libre dans la zone "maps pour le scrolling". Le hic, c'est que les jeux de tiles d'un plan doivent obligatoirement commencer à une adresse multiple de 16K, ce qui tue toute possibilité de "compression" de ce genre. L'idée étant que quand la puce vidéo de la DS rencontre le tile numéro 345 sur une map, elle s'empresse de calculer données_en_vram = 345 x 64 + TILE_BASE[no_de_layer] * 16K ...

Bon, je ne suis pas au limites des possibilités de la DS, loin de là (j'utilise 512K de VRAM sur les 640 disponibles), mais je frôle ce qu'il est possible de faire sin mô d'tchiesse.

There are a couple of options to fix this issue, but none of them could be hacked in a few hours. The best approach would likely to take advantage of the 16-colours background screen and to trim it from ~36K to ~14K, which would perfectly fit the available VRAM. I could alternatively try and map more memory on tiles (I'm only using 512K out of the 640 available on the DS), but that could have strongs implication later on, that would prevent me from doing 3D or using different palettes on the different planes. The DS hardware offers some flexibility on how you use the VRAM, but you quickly realise that there are more constraints than degrees of freedom :P

Bienvenue dans le monde réel >_<
edit: c'est fait