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.
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 ?
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.
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.
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.
NOTE: le côté "ouais, mais non, j'ai pas de SNES ni d'écran pour brancher une SNES dessus, de toutes façons, et les cartouches-linker coûtent bonbon" devrait pouvoir s'incliner devant un appareil comme le BittBoy. à cogiter.
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. 🤗
ReplyDeletedans un décors pour SNES, il faut absolument penser les blocs pour qu'ils soient ré-utilisable avec des flips x, y, xz.
ReplyDeleteMieux, 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...
Ah ouaip, c'est coquin la gestion de tout cela !
ReplyDelete@Unknown: "il faut absolument penser les blocs pour qu'ils soient ré-utilisable avec des flips x, y"
ReplyDeleteoui, 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.
@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"
ReplyDeleteTu 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.