Monday, September 02, 2019

Super Bilou ?

Because yeah, I can't help: the SuperNES draws me like a magnet. No matter how many times I refrain myself from looking deeper into it, I keep wondering how school rush would feel on the 16-bit queen.

But there is no easy answer. The SNES means only 128 colours for all 3 tiled layers. It means that either the ink or the owl must be patched to work with only 4 colours per tile. And it most likely mean that the twin playground layers of School Rush levels must be merged into a single one, with sprites automatically used where Bilou must enter objects like big binders.


Parce que oui, il n'y a rien à faire: la Super Nintendo exerce un magnétisme sur moi, et quelque soit le nombre de fois que j'aie décidé de ne pas m'attarder dessus, je ne peux pas m'empêcher de recommencer à me demander comment Bilou tournerait dessus. Après tout, le jeu a été conçu à une époque où les 16-bits régnaient en maîtres, et faire tourner le jeu sur une vraie machine 16-bit, ce serait la consécration. Et la Super Nintendo est à mon avis la seule machine grand-public qui serait capable de faire tourner un portage correct du jeu. La Mega-Drive et l'Amiga manquent tous les deux de couleurs ... puis je me vois assez mal demander à mon frangin de travailler sur une bande-son Mega Drive, même si l'assembleur 68000 est définitivement plus sexy que le 6502+ de la SNES.

Mais tourner sur SNES, ça veut dire tenir sur 128 couleurs pour l'ensemble des décors, retravailler l'encre ou le hibou du décor parallaxe pour qu'il ne prenne que 4 couleurs par tile, et autres contraintes de ce genre. Et ça veut dire aussi que je dois fusionner les deux couches de tiles en une seule, parce qu'il n'y aura pas assez de plans sans ça. J'ai bien tenté de faire l'encre avec des sprites ou une tranche de hibou en sprites pendant qu'on bascule un des décors du hibou vers l'encre, mais les ressources de la console en terme de sprites sont trop limitées pour ça. Ce n'est pas pour rien si les vagues des niveaux d'eau dans Sonic montrent un clignotement pair/impair ... mais je ne peux pas faire ça si je veux que l'encre ait l'air opaque.

But even with all those limitations, I feel like it would be the only mass-marketed 16-bit  that could host ports of the game. Both Mega-Drive and Amiga lack colours , and I don't feel like asking my bro to give Sega FM chip a try, even though 68000 assembly has more hex appeal than SNES 6502+ instruction set.

I tried other approaches, like using a row of sprites for the owl statue if the ink approaches enough, since there isn't enough sprite resources to implement ink waves as sprites as on the DS (more on that in a later post). But I had to come to the conclusion that merging the two layers into one is the only practical thing to do. So the next question is: how much overlap between layers is there in the levels of School Rush?

Voyons donc cette histoire de fusion. Ayant un niveau modeste en pixel art et un moteur de jeu basé sur un contenu quasi-statique de la mémoire vidéo, j'avais essayé au maximum d'éviter dans School Rush d'introduire des tiles qui seraient une combinaison de deux objets (un classeur à l'avant-plan et un morceau de bois à l'arrière plan). Au lieu de ça, j'utilisais deux plans verouillés ensembles tout en mettant les graphismes sur l'un ou l'autre plan selon les besoin. Avec le GPU sous stéroïdes de la DS (si, si), il me restait encore de quoi faire tout le reste. Ramener les deux plans sur un seul est possible parce que la SNES permet pour chaque tile dans la map de fixer sa priorité par rapport aux sprites. Reste à trouver des solutions pour afficher les superpositions. Du coup y en a-t-il beaucoup dans School Rush, et où sont-elles ?

I have fairly simple tilesets in School Rush, and used overlap to make object-bridging tiles. Merging means that these tiles now need new slots in the tileset. How many of these are there ? Can they fit the remaining space in the tileset or do I need to use virtual tilesets as I plan to implement in later versions of libgeds.

In most of the game, there is only a few tiles of overlap, in corners, often with green books or binders. These could either be done with overlay sprites or merged tiles. No problemo.


Les plus fréquentes proviennent des livres et des classeurs verts. Je dis 'fréquents', mais il n'y en a pas tant que ça par écran. Ce ne serait probablement pas pratique de construire une palette qui permette de combiner 'verts et mauves', une autre avec 'verts et bruns', etc. donc je m'orienterais probablement vers une implémentation avec des petits sprites 8x8 par-dessus le graphisme de la "couche" la plus distante de la version DS. Pas de soucis en vue ici.

Il y a ensuite une série de structures où la superposition n'est pas fondamentale pour le gameplay, voire parfois carrément accidentelle. C'est le cas avec la zone encadrée en bleu clair sur l'image ci-contre. Là une simple modification de la map suffira.

Viennent aussi les graphismes qui sont réalisés avec une combinaison de deux tiles plus simples pour des raisons de facilité, comme ce tube qui rentre dans le classeur, mais qui en réalité ne se coude pas et passe simplement par-derrière. Là, on pourra probablement se contenter d'un nouveau jeu de tiles parce que les version "simplifiées" ne sont pas utilisées telles qu'elles dans le niveau.

There are other locations where overlap allows to create sophisticated tiles with simpler ones -- like with the purple areas on the screenshot next. But in the level where I find these, the 'simpler' tiles aren't used anywhere else, so I could just have these in the SuperNES vram and that's it. Then there are locations where the level could be simplified to avoid overlap (like with the cyan area) without altering the layout of the play area.

Then there is the annoying areas. Those where we don't see parallax background layer with some wooden walls. They lead to a significant amount of additional tiles, especially given the complexity of that background (16 unique tiles). There isn't much else in these areas, hopefully. And not so many structure. Stacking sprites should work, but that makes more palettes needed. Alternatively, I would have to simplify the background texture locally and have a copy of those tiles with a simple, but opaque background.

Là où les choses se corsent réellement, c'est pour les "cachettes", ces passages du niveau où on est à l'intérieur d'un banc. Ici, n'importe quel objet qui n'est pas simplement rectangulaire introduit des nouveaux tiles. Et pour corser encore les choses, la texture de "fond de bois" prend facilement 16 tiles. On va avoir des combinaisons dans tous les sens si on n'y prend par garde. On risque de manquer de palettes si on essaie d'utiliser des sprites pour tout ça. Par contre, je pourrais essayer de faire une variante de ces tiles sur un fond opaque mais plus simple, et ajouter une variante des tiles de la texture "bois" qui permet la transition vers les objets. A condition que j'aie assez de place dans mon tileset pour caser tout ça.

Likely, the last, vertical level will be impossible to port to the SuperNES, and it is the reason why I started consuming the last 256 tiles of the 1024-tiles set.

So final move. Let's pick the latest tileset. Let's clear out all the tiles that feature only opaque pixels. Then let's clear those that are mirrors of each others (maybe not that wise, but there weren't so many of them). The result is about half the free room that not implementing the vertical level leaves. I can have two alternate (opaque) backgrounds of these. Or at least, I could if the SNES had 96 or 128KiB of video memory. But it only has 64.



Ce ne sera probablement pas le cas avec la version finale de School Rush et son niveau vertical qui introduisait justement plein de nouveaux tiles-de-raccord, mais si je m'en tiens aux 4 niveaux horizontaux d'origine, il me reste un bon quart (256 tiles) de mémoire disponible. Belote.

Maintenant, voyons un peu quelle quantité de mémoire représentent tous ces tiles qui possèdent des pixels transparents. On est dimanche soir, j'ai la flemme de scripter quelque-chose de pratique. J'y vais à la main comme un bourrin. Verdict: on pourrait faire tenir encore 2 à 3 copies de ces tiles-là dans un tileset de 1024 éléments. Rebelote.





Mais la Super Nintendo n'a que 64KiB de mémoire, à partager entre les graphismes des décors, des sprites et les "maps" (comptez 4KiB pour un écran qui scrolle horizontalement, 2KiB pour un arrière plan qui reboucle), et un tileset complet en 16 couleurs pèse 32KiB. Mon décor de hibou (534 tiles et 10 couleurs) est légèrement au-dessus des 16 KiB. Les techniques de "virtual tilesets" seront donc incontournables.

5 comments:

Pierrick said...

Aaaah... Les limitations harware. Ou, l'art de faire rentrer des carrés dans des ronds... 😊 Ne soit pas trop dur avec toi même , il y a belle lurette, que tu t'es élevé niveau pixel art à un niveau que je n'attendrais probablement jamais. Pour ce qui est des contraintes, il faut toujours sacrifier quelque chose pour rester dans les clous. La vraie question c'est, comment revoir ses exigences à la baisse en s'en tenant le plus possible à ce qu'on a dans la tête ? A base de compromis. Le code sur machines "limitées" (et encore dis toi que tu es relativement le "cul dans le beurre"), c'est la négociation. 😊 Simplifie toi la vie et revoit tes exigences à la baisse. Être trop ambitieux n'amène que des tracas. 😉 By the way, c'est génial ce que tu fais. Et je suis sûr qu'avec un peu de concessions et de pragmatisme, tu trouveras un terrain d'entente entre ta machine et toi. 🤗

Unknown said...

dans un décors pour SNES, il faut absolument penser les blocs pour qu'ils soient ré-utilisable avec des flips x, y, xz.

Mieux, il faut penser à réutiliser le bitmap avec une autre palette de couleur.

Et ensuite, une fois toute les astuces dépensées, faire un en sorte que la mémoire écran soit juste le cache de la rom afin de faire entrer et sortir les blocs.

Mais c'est assez compliqué a faire :
- il faut tenir une comptabilité de tout ce qui sort, y compris en diagonal,
- établir des clusters


si le sujet passionne quelqu'un je peux développer...


cyborgjeff said...

Ah ouaip, c'est coquin la gestion de tout cela !

PypeBros said...

@Unknown: "il faut absolument penser les blocs pour qu'ils soient ré-utilisable avec des flips x, y"
oui, j'imagine que si je reprenais les tilesheet de Tintin au Tibet ou d'Aladdin, je pourrais en trouver. C'est flagrant dans Donkey Kong Country, en tout cas, où les faces gauche et droites d'un mur sont des miroirs les uns des autres, et tant pis pour les choses triviales telles que les règles élémentaires de perspective.

" faire un en sorte que la mémoire écran soit juste le cache de la rom afin de faire entrer et sortir les blocs"
C'est une technique que j'aimerais mettre en place à terme, mais qui demande un moteur de jeu un cran au-dessus de ce que j'ai actuellement pour DS, avec un support pour ce que j'appelle un virtual tileset. J'avais cru pouvoir m'en sortir sans mais vu que la VRAM de la SNES est moitié moins grande, ce sera incontournable.

PypeBros said...

@Pierrick: "Ne soit pas trop dur avec toi même , il y a belle lurette, que tu t'es élevé niveau pixel art à un niveau que je n'attendrais probablement jamais"

Tu devrais essayer le traît direct au stylet avec le Sprite Editor pour DS ^_^

Mais plus sérieusement, quand je dis que j'ai un niveau modeste en pixel art, c'est parce qu'entre-temps des types comme 08-n7r6-7984, Arne et Snakepixel on continuer de faire évoluer le média alors que je suis encore loin derrière le standard de qualité des Bitmap Brothers dans les années '90.

En clair, j'ai réussi à avoir des graphismes qui pourraient être mieux cotés que ceux de James Pond ou SuperFrog en 256 couleurs, mais de là à faire quelque-chose de convaincant avec 16x4 couleurs ... euh ... j'ai encore des années de travail avant d'y parvenir ^^' Je le sais pour avoir essayé avec les palettes d'Aladdin il y a quelques jours.