Magician Lord (démo technique SuperGrafx)

[Kaminari]

https://www.youtube.com/watch?v=eRcPWkvZg70

Magician Lord - SuperGrafx demo ROM

Ça faisait un moment que je cherchais le moyen de me mettre à la SuperGrafx. Sur certains de mes slideshows, la CoreGrafx m'a posé de sérieux problèmes, et même si je suis super satisfait du résultat, la SGX m'aurait grandement facilité la tâche sur les conversions graphiques les plus difficiles... en particulier Magician Lord ! Sans même parler d'animations ou de parallaxes, le plan de tuiles unique de la CGX et ses limites de sprites pouvaient rendre la création d'un "simple" screen statique extrêmement compliquée.

À mon modeste niveau, j'aime beaucoup l'assembleur. Mais un des problèmes majeurs du bon vieux Magic Kit (en dehors du fait que son développement s'est arrêté il y a plus de 20 ans) est qu'il ne propose aucune fonction SGX. Pire, il aura fallu attendre une décennie supplémentaire pour que le compilateur HuC (la "surcouche" C de Magic Kit) supporte la SGX grâce à la contribution de Tomaitheous (aka. Malducci, Bonknuts, TurboXray...).¹

Il y a quelques jours, je me suis donc plongé naïvement dans HuC 4 (édition 2023 !) pour apprendre non seulement le fonctionnement de ce programme (dont la plupart des fonctions et macros sont empruntées à Magic Kit) mais également le langage C lui-même, auquel je ne connaissais quasiment rien... Heureusement que j'ai fait un peu de Javascript car la syntaxe ne m'a pas trop dépaysé !

Un énorme point faible de HuC est son manque quasi total de documentation. La doc de Magic Kit est spartiate et incomplète, mais les quelques tutoriaux disponibles sur le site de David Michel permettaient cependant à n'importe quel profane de démarrer. HuC en revanche ne propose presque rien aux néophytes, ce qui est vraiment dommage car son potentiel est réel et les performances solides (malgré quelques premiers jours de galère).

J'ai une dette envers Nodtveidt (Old Rover), des groupes Frozen Utopia et Eponasoft. Les tutoriaux qu'il a postés il y a plusieurs années sur son site ObeyBrew m'ont grandement éclairé sur plusieurs points que Magic Kit et HuC n'expliquaient pas du tout, ou alors très mal. N'étant pas programmeur, j'apprécie ce genre d'efforts instructifs. Dommage que son site soit aujourd'hui à l'abandon et ses tutos inachevés

Erratum¹

L'auteur original des librairies SGX pour HuC est en fait notre vieux collègue Xavier Carmona, qui les avait présentées ici-même et les avait postées chez Zeograd en 2006 ! Malducci s'en est servi comme base de travail quelques années plus tard, c'est sa version optimisée qui a été intégrée dans HuC 4.

[Laucops]

Ouah de bon matin ça réveille !

Bravo pour cette superbe démo, et je me dis qu'en tandem avec Touko vous pourrez peut-être faire de grandes choses

[shubibiman]

Au passage, je découvre que Nodtveidt = Old Rover

[franz]

Les screenshots envoyaient déjà du lourd, mais là j'avoue que de voir tout ça bouger, ça laisse une toute autre impression
Well done Kami !
Une question : on peut diriger le perso au pad ou le scrolling est automatique ?

[cazeysan]

Très joli ! Chapeau

[Kaminari]

Merci les gars !

Franz, pour le moment je me suis contenté d'une animation auto, le pad ne sert qu'à mettre la démo en pause Je voulais faire une sorte d'attract mode pour tester les parallaxes. Ce n'est pas très compliqué de faire un scroll manuel et changer la direction du sprite, mais ça demande un peu plus de boulot.

Mon gros problème actuel est que je ne comprends rien aux maps (pour faire des niveaux qui dépassent de l'écran par exemple). J'ai fait plusieurs essais avec l'antique format FMP (Mappy) recommandé par HuC, mais mes tuiles sont totalement dans le désordre et les couleurs sont fracassées. J'ai l'impression que HuC ne gère qu'une seule palette de 16 couleurs par map, ce qui ne peut absolument pas me convenir. Malducci avait teasé il y a longtemps un outil de conversion (FMP2PCE) mais je crois qu'il ne l'a jamais rendu publique.

J'expliquerai plus tard en détails mes soucis avec quelques exemples, en espérant que les pros (Touko, Mooz, Dave, Peperocket) pourront me donner un coup de main pour comprendre ce qui déconne. Je constate malheureusement qu'au niveau graphique il y a une pénurie terrible d'outils adaptés à la PCE.

[Kaminari]

ROM et vidéo mises à jour !

J'ai enfin cracké le code, mais quelle misère ce Mappy...

J'ai d'abord fini par comprendre (enfin... je pense !) un truc que j'ignorais totalement : la PCE gère 256 tuiles uniques pour chaque palette de 16 couleurs (par "uniques", je veux dire des tuiles sans leurs éventuels doublons). Je ne sais pas si c'est une caractéristique de la machine ou une limite du compilo, mais ça semble expliquer pourquoi les 600 tuiles globales de mon avant-plan (toutes palettes confondues) étaient correctes sur une partie de l'image (probablement autour de 256 tuiles), puis partaient en sucette à partir des statues de pierre.¹

L'autre problème (les couleurs défoncées) était donc lié au précédent : les tilesets (les planches de tuiles nécessaires pour dessiner la map) doivent obligatoirement être groupées par palette, c'est à dire une palette de 16 couleurs par fichier de tuiles. Mappy ne permet d'exporter les tuiles que dans un seul fichier graphique... avec toutes les palettes dedans et les tuiles dans le désordre.

J'ai donc trouvé une magouille pour forcer Mappy à ne produire qu'un seul tileset correctement organisé à la fois. J'importe dans Mappy chacune de mes layers de 16 couleurs (par exemple le sol) une par une, en exportant à chaque fois les tuiles optimisées par le logiciel (donc sans doublon) dans un fichier à part limité à 16 couleurs. Toujours dans Mappy, j'ai ensuite mixé mes layers (7 pour l'avant-plan) dans une layer finale, que j'ai gardée tout en supprimant les autres. En effet, HuC ne peut lire que la première layer dans un fichier d'export FMP.

Le vrai problème n'est donc pas tant l'ergonomie foireuse de Mappy, qui fait le job bon gré mal gré, au moins en 16 couleurs. C'est surtout HuC qui n'est que partiellement compatible avec le format de fichier FMP. En effet il n'est capable de lire que la map (la "table des matières" des tuiles), mais pas les tuiles elles-mêmes ni leurs palettes qui sont pourtant stockées dans le fichier. D'où les bidouilles nécessaires pour gérer séparément ces données graphiques. Je comprends pourquoi Malducci voulait automatiser ce processus qui devrait prendre 2 minutes et pas 2 heures

Existe-t-il des outils ou convertisseurs pour faciliter ce boulot assez fastidieux ? Quelqu'un a pu tester FMP2PCE ?

Erratum¹

Finalement rien à voir avec les regroupements de tuiles par palette... C'est en fait une vieille limite du compilateur ! HuC ne gère qu'une seule banque de 256 tuiles, alors que la PC Engine supporte jusqu'à 16 banques de 256 tuiles chacune, pour un total de 4096 tuiles uniques. Pour contourner ce problème, il faut complètement renoncer aux fonctions de tilemapping de HuC et manipuler les fichiers de tuiles avec des outils adaptés comme MergeBMP2PCE de Touko ou MAPeD de 8BitDev.

[pronche]

Je ne peux pas t'aider, seulement t'encourager ! C'est assez bluffant de voir la video

[shubibiman]

Bravo pour la persévérance. En documentant tout ça, tu vas finir par masteriser le pixel art PCE.

[Kaminari]

J'ai surtout l'impression un peu décevante de réinventer la roue.

Je me dis que depuis le temps, il doit exister d'autres méthodes plus simples et déjà documentées pour faire des maps de plus de 16 couleurs, ce n'est pas possible autrement. Les homebrews PCE ne courent pas les rues, mais certains ont dû forcément être confrontés à ces problèmes. Or je ne trouve aucune discussion intéressante à propos des maps utilisant plus d'une palette (à part justement un vieux sujet de Malducci sur pcefx.com dans lequel il parle de son utilitaire FMP2PCE).

Touko, tu fais comment pour Shinobi ?

[franz]

Il faut médiatiser les compétences.

[touko]

C'est cool que tu te mettes au dev .Bon c'est sur que commencer avec un jeu comme ça, ça risque de piquer un peu, surtout en C .
Après si tu as besoin d'un coup de main en ASM, tu fais signe .

Je me dis que depuis le temps, il doit exister d'autres méthodes plus simples et déjà documentées pour faire des maps de plus de 16 couleurs

Pas a ma connaissance non, du coup j'ai codé un outil, qui me permet d'en faire facilement (enfin moi je trouve ça facile), enfin d'en avoir, mais c'est un truc en ligne de commande (qui marche bien maintenant),la version que je t'avais donnée avait un petit bug, elle ne marchait qu'avec 1 seule taille de map, un peu ballot qd même .

Touko, tu fais comment pour Shinobi ?

Lassé d'essayer de trouver un truc, j'ai fait un script, qui ma fois marche très bien maintenant .Je découpe mes images (qui servent de levels) en calques à la main, chaque calque contient les tiles et leur palette correspondante. Les calques ont tous la même taille, celle de la map quoi, et leur superposition donne la map complète .
Je peux illustrer si je suis pas clair .

Ex: pour le level 1 de shinobi , j'ai un calque pour le bâtiment bège+sol, et un pour les caisses => 2 palettes

[Kaminari]

Pour le moment je me fais la main sur l'aspect technique, je ne connais rien à la game logic (tests de collision, plateformes...). Magician Lord est un gros morceau mais j'avais déjà les graphs convertis sous la main et je voulais tâter la SGX

Je pense comprendre ta méthode, a priori je fais un truc similaire avec Mappy. Je ne retrouve pas l'outil en ligne de commande que tu m'avais filé. Si tu peux m'envoyer ta mise à jour, je suis preneur

[touko]

Le lien vers mon dropbox :
https://www.dropbox.com/scl/fi/ed05o2dp ... 7dyuq&dl=0

Avec ça,t'as plus besoin de mappy, tu travailles directement avec les .bmp , il te crée en sortie ton fichier de gfx(avec suppression des tiles identiques), pal(s) et la tilemap à inclure en bin(tu auras donc 3 fichiers en sortie pour tous tes calques .bmp)

Avec un exemple c'est plus parlant .
CALQUE 1:


CALQUE 2:

[Kaminari]

Oui, c'est comme ça aussi que je travaille mes calques.

Merci pour l'outil ! Je vais tester ça ce weekend. La ligne de commande a l'air simple et les instructions intégrées sont claires