Kaminari Visual Collection

[franz]

Je me suis dis la même chose. On est sûrs que c'est pas un pseudo de Kami ce compte ?

[Kaminari]

Deux adaptations graphiques de In the Hunt sur PCE à quelques mois d'intervalle, c'est un hasard de calendrier assez surprenant. Peut-être motivé par le retour d'Akio aux affaires ?

Je peux déjà dire que ça ne vient pas de ma ROM, c'est une conversion de palette automatique à la grosse d'un quelconque screenshot arcade.

[shubibiman]

Ok donc vraiment le hasard

[Kaminari]

J'ai rebossé un peu sur les graphs de Chō Makai Mura, que j'avais laissé en suspens il y a 3 mois. Ce genre de maquette est vraiment complexe pour une CoreGrafx et je commençais à me sentir à l'étroit...

Je me suis récemment investi dans HuC, notamment pour pouvoir utiliser la librairie SuperGrafx dont le support manque cruellement dans Magic Kit. Après mûre réflexion, j'ai décidé de migrer tout mon projet sur SGX afin d'exploiter pleinement les deux plans de tuiles et deux plans de sprites.

Visuellement, vous ne constaterez probablement pas de différence. Mais du point de vue du processus de création, ça n'a plus rien à voir ! Je peux enfin concevoir mes screens comme s'ils étaient destinés à un proto fonctionnel, avec possibilité de scrolls parallaxes et animations de sprites. C'est d'ailleurs en adaptant sur SGX mon screen de Magician Lord que j'ai fini par pondre à l'insu de mon plein gré une petite démo technique

La ROM du slideshow a été mise à jour, mais elle nécessite désormais une SuperGrafx (ou un accessoire/émulateur compatible). Bonnes fêtes !

The Ghost Ship (SFC/SGX)


The Sea of Madness (SFC/SGX)


The Smelting Furnace (SFC/SGX)


The Molten Towers (SFC/SGX)


The Rotten Guts (SFC/SGX)

[shubibiman]

[Laucops]

C'est une fois de plus de toute beautay

On constate à nouveau que les teintes bleues et rouges/orangées nécessitent visiblement moins d'adaptations que les bruns de la voile du bateau ou les gris de la tour.

[Kaminari]

The Spinning Stomach (SFC/SGX)


The Poisonous Bowels (SFC/SGX)


The Frozen Forest (SFC/SGX)

---

Petit test d'animation de couleurs, faites à la main dans la douleur...
8 palettes pour le background et 4 palettes pour les fruits de l'arbre. (Capture GIF avec Mesen.)



Vous noterez que dans plusieurs niveaux, la Super Famicom renonce au plein écran et affiche son interface sur fond noir. C'est parce que dans ce jeu, le BG3 de la SFC est coupé en deux ; il est utilisé pour la GUI dans la partie supérieure et pour le background juste en dessous, ce qui a obligé les graphistes à faire des bricolages disgracieux (la GUI peut s'afficher en transparence par dessus les avant-plans en BG1 et BG2 mais, bien entendu, pas par dessus le décor de fond puisqu'ils partagent le même plan BG3).

Sur SuperGrafx j'affiche la GUI en sprites, ce qui règle le problème

[franz]

C'est beau les images qui bougent
Sinon, t'as fait comment pour faire spinner le stomach sur SGX ?

[Kaminari]

Le mode 7 (qui donne l'impression d'avoir été contractuellement obligatoire dans chaque jeu SFC) n'apporte comme souvent strictement rien au gameplay, en particulier dans Chō Makai Mura où le niveau 4 rotationne tout seul pendant que tu poireautes dans ta cage

D'un point de vue purement théorique, je pense qu'on pourrait le remplacer par une utilisation astucieuse du splitscreen (découpage de l'écran ligne par ligne) pour créer une "déformation" du décor vers la gauche et la droite. Ou alors faire comme dans Son Son 2, un bon vieux fondu au noir pour suggérer un "transfert" vers une autre section du niveau... Cheap mais efficace. Ce ne sont pas les solutions qui manquent ! Je suis sûr qu'un demomaker comme Mooz aurait plein d'idées

---

Au passage, un grand merci à Touko pour MergeBMP2PCE !

J'utilise désormais systématiquement ton outil à la place de Mappy et Pro Motion. Il permet non seulement de fusionner facilement des calques, mais aussi de créer les maps et optimiser les tuiles. Les fonctions de tilemap de HuC sont très rudimentaires, elles n'ont d'ailleurs pas évolué en 20 ans (à part ajouter le format de map de Pro Motion en plus de celui de Mappy). Je trouve hallucinant que le compilo ne supporte encore qu'une seule banque de 256 tuiles, alors que la PCE peut gérer jusqu'à 4096 tuiles uniques (2048 exploitables en pratique sur CGX). C'est une limitation très sévère dont s'affranchit MergeBMP2PCE.

En plus de ses capacités de fusion de calques, MergeBMP2PCE a une grande qualité par rapport à GFX2PCE : on peut spécifier l'adresse de stockage des tuiles en VRAM, alors que l'outil d'Alek est hardcodé à l'adresse 0x1000 pour respecter la convention imposée par Magic Kit et HuC (ce qui fait perdre quelques précieux octets, surtout quand on n'a pas besoin de la police de caractère de HuC).

Petite astuce avec MergeBMP2PCE pour créer une map à partir d'un seul calque : il suffit de spécifier deux fois le même fichier en paramètres (comme si on fusionnait deux images identiques) et de bloquer la palette avec un slash "/" (pour ne garder qu'une seule palette). Exemple :

Code : Tout sélectionner

MergeBMP2PCE.exe 0x0400 0/ bg1.bmp bg1.bmp MonMagnifiqueBG1

Cette bidouille n'est pas documentée dans la ligne de commande. Je ne sais pas si elle est intentionnelle mais elle est super pratique

Les seuls trucs qui manquent par rapport à GFX2PCE, c'est le support des tuiles/blocs de taille 16 (MergeBMP2PCE ne fonctionne qu'en taille 8 ?) et accessoirement le format PNG.

Touko, tu devrais créer un sujet dédié avec un lien vers ton outil, parce qu'il mérite d'être épinglé en post-it !

[Kaminari]

@Touko

Sur certaines images, je rencontre un problème avec MergeBMP2PCE.

Supposons que je bosse sur 4 calques (appelés bg1.bmp, bg2.bmp etc). J'ai beau spécifier bg1.bmp comme palette de départ, l'outil va ignorer ma demande et choisir automatiquement un autre calque. Dans l'exemple ci-dessous, il a décidé de fusionner les calques dans l'ordre 3-2-1-4. Je ne comprends pas la logique, mais je me demande s'il ne choisit pas le calque dont la première couleur est la plus foncée de toutes, ou bien le premier calque avec une tuile non vide en 0,0 (pure spéculation de ma part, je n'ai pas fait de test poussé).



C'est surtout ennuyeux quand tu veux créer deux maps sur SGX (pour le BG1 et le BG2) qui partagent les mêmes palettes, mais ces palettes se retrouvent classées dans un ordre différent pour chaque map et les couleurs d'un des deux plans ne correspondent donc plus.

Ça ne le fait pas avec tous mes screens (je dirais environ 20%) mais ça ressemble quand même à un bug.

[touko]

Salut, oui c'est normal en fait .
Le premier calque doit être celui qui commence avec la première tile .C'est pour ça qu'il change l'ordre, il fait cette détection, si le fichier que tu lui passes n'est pas celui avec la première tile .
Je sais plus pk j'avais été obligé de faire ça,mais il y avait un souci sinon .

EDIT : Ah oui c'est parce que j'utilise une tile témoin(qui va servir de pseudo masque) à l'adresse 0x0000 pour définir la tile qui va servir de tile "vide" comme base pour le mixages .

Faudrait que je revois ça un des ces 4 pour que ça se base automatiquement sur la tile vide .

[Kaminari]

Merci de la confirmation.

Pour mes deux plans de tuiles qui partagent les mêmes palettes, j'ai contourné le problème de deux façons.

La première solution est de renommer les calques de la deuxième map dans le même ordre imposé par l'outil pour la première map (par exemple changer bg1.bmp en bg3.bmp). La plupart du temps ça marche, sauf si la deuxième map est créée elle aussi avec un ordre de palette différent.

L'autre solution radicale est de démarrer les numéros de palette de la deuxième map dans un slot distinct, genre palette #3 au lieu de palette #0 (comme si les palettes de la deuxième map étaient différentes de celles de la première). C'est dommage car ça produit des palettes en double et c'est un peu du gâchis, mais au moins ça fonctionne.

[touko]

Oui c'est dommage de perdre des slots pour rien,sauf si tu en utilise moins de 16, ça peut être une bonne solution.
C'est vrai que je n'avais pas pensé à une utilisation des palettes aussi radicale que la tienne
Je pense que le meilleurs moyen pour ton cas,c'est de s'arranger pour que les calques soient pris dans le bon ordre.
Un simple:
1_bg3.bmp
2_bg1.bmp
etc.
devrait suffire .

[Kaminari]

Yep, cette solution fournit de bons résultats pour le moment.

Il faut dire que la SFC utilise fréquemment ses plans BG1 et BG2 pour faire des calques "à la Photoshop". Pour éviter de se prendre la tête avec les effets de bord (conflits de couleurs dans une même tuile) et devoir faire des palettes mixées comme sur PCE, les graphistes SFC préféraient découper et répartir des morceaux de décors entre les deux plans de tuiles en fonction de leurs palettes respectives — découpage de tuiles que je subodore avoir été entièrement automatisé par leur logiciel de dessin de l'époque, tellement ça semble anarchique. Et parfois ces morceaux de décors utilisent les mêmes palettes entre le BG1 et le BG2.

Exemple de bricolage de tuiles/palettes sur Super Famicom :

Calques SFC (BG1/BG2)


Sur SuperGrafx, j'ai reconstruit la scène différemment et de façon plus optimale.

Calques SGX (BG1/BG2)


En tout cas, ton outil est une bénédiction pour les graphos PCE

[touko]

Merci, en tous cas si ça peut t'être utile tant mieux
Faudra que je m'y replonge pour améliorer ça .