Tengai Makyō Zero (démo technique hybride PCE/SGX)

[Kaminari]

Tengai Makyō Zero (ROM hybride PCE/SGX)

Après avoir passé des années à chercher en vain des infos sur les tests de collision...
Y aurait-il un début de kekchose !?

[shubibiman]

C'est toi qui as fait ça ?

[Zhebus]

Super!
Je suis loin d'en être là. Je bosse le scrolling :')
Tu fais ça comment?

[Kaminari]

C'est toi qui as fait ça ?

Oui Monsieur

Tu fais ça comment?

J'ai récemment découvert la chaine YouTube de Pigsy, un développeur MD britannique qui bosse sur un remake de Shinobi GG et un "demake" impressionnant de Dracula X PS1 pour la Mega Drive.

Entre deux présentations de ses démos techniques, il passe beaucoup de temps à poster de nombreux tutoriaux sur divers aspects du développement rétro. Les tests de collision avec le décor constituent l'une des demandes les plus récurrentes dans ce domaine — et je comprends pourquoi, parce que ce type de compétence relève aujourd'hui littéralement de l'abandonware. Très peu de gens qui comprennent les méthodes de l'époque partagent ces infos, surtout que des outils de développement "clés en main" permettent de s'en affranchir, ce qui est carrément dommage. Quand tu comprends finalement le concept, tu te dis effectivement que ça doit être de la connaissance triviale ; mais quand tu es novice, le concept même t'échappe.

Il existe plusieurs méthodes de collision, mais l'une des plus "simples" et populaires est celle du tableau (array). Cela consiste essentiellement à représenter de manière simplifiée les tuiles (16x16 pixels) de ton écran sous forme de 0 et de 1. Les tuiles 0 sont "libres" (on peut marcher dessus) et les tuiles 1 sont solides (ton sprite ne se déplacera pas).

Exemple en C avec la table de ma démo :

Code : Tout sélectionner

const unsigned char HOUSE_COLLISION_ARRAY[256] =
{
	1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
	1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
	1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
	1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
	1, 0, 0, 0, 1, 0, 1, 1, 0, 0, 1, 1, 0, 0, 1, 1,
	1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1,
	1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1,
	1, 0, 1, 0, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1,
	1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1,
	1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1,
	1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1,
	1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1,
	1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1,
	1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1,
	1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
	1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1
};

Pour savoir sur quelle tuile ton sprite va se retrouver, il faut quelques petites étapes assez simples :

1. Convertir ta position pixels en position tuiles (généralement via une division par 16).
2. Une formule pour calculer le numéro de la tuile sur laquelle va se déplacer ton sprite lors du prochain mouvement de pad.
3. Interroger ton tableau de collision pour savoir si la tuile en question est libre (valeur 0) ou solide (valeur 1).
4. Du code pour "repousser" (pushback) ton sprite à sa position précédente en X et/ou Y si cette tuile est solide.

On peut étendre ce système très versatile à des tuiles de type différent, au hasard valeur 2 pour définir une tuile qu'on pourrait traverser dans un sens mais pas dans un autre (un tapis roulant par exemple). Une fois que tu as capté le fonctionnement général, ça coule de source. Mais c'est un peu comme les cathédrales : personne n'a transmis de méthode de construction... parce qu'à l'époque tout le monde savait apparemment comment les construire !

Pour les curieux : Tengai Makyō Zero - Test de collision (SGX)

[cazeysan]

Bigrement intéressant

[Kaminari]

J'ai mis à jour ma démo avec l'ajout d'un scrolling dynamique comme dans les vrais JRPGs.

Deux jours de debugging pour faire coïncider le défilement de l'écran avec la table de collision

On peut aussi accélérer avec le bouton II

[touko]

Deux jours de debugging pour faire coïncider le défilement de l'écran avec la table de collision

La première fois c'est pas évident, une fois compris le truc, ça se fait assez facilement .
Après mettre un octet/tile peut faire vite grossir le fichier de collisions .

[Kaminari]

Nouvelle mise à jour de ma petite démo, avec un mode totalement inédit depuis 1990 : la compatibilité hybride PCE/SGX !

PCE ou SGX ?


Il vous est donc maintenant possible de tester la ROM sur n'importe quel modèle de PC Engine. Le code de base (mouvements, collisions) est le même, en revanche la partie graphique est totalement spécifique à chaque machine (notamment les sprite-masks sur PCE, nécessaires pour cacher les personnages derrière des morceaux de décor). La détection hardware PCE/SGX est automatique.

Sur SuperGrafx (comme sur Super Famicom), le plancher et les murs sont sur le BG2, tandis que le mobilier est affiché sur le BG1. Le sprite du héros est placé entre les deux plans et profite ainsi d'une "occultation" naturelle sans avoir à coder grand chose.

SGX (Background 2 / Background 1)


Mais sur PCE, j'ai dû reconstruire l'essentiel du décor sur un seul plan de tuiles et cacher le héros avec toute une série de masques — des sprites dynamiques "invisibles" qui ne s'activent qu'à proximité du héros. Les meubles dont la palette ne peut pas être facilement mixée avec celle du décor (futons, etc) sont affichés en sprites pour disposer de leurs propres couleurs. Sur PCE, vous pouvez afficher les masques en bleu foncé avec Select pour avoir une idée de leur fonctionnement. La technique est particulièrement efficace sur le mur du bas. J'ai mis près d'une semaine pour peaufiner cette usine à gaz !

PCE (Background / Sprites)


Ce système de masques est assez peu fréquent sur PC Engine, mais il a été utilisé de façon remarquable dans des jeux comme Magicoal. Concernant ma démo, le résultat sur PCE est virtuellement identique au rendu SGX, par contre cette approche nécessite beaucoup plus de boulot

[shubibiman]

Tu vas bien finir par nous faire un jeu complet !

[kawickboy]

Le 1er RPG en français sur PCE sans patch.

[Kaminari]

Si vous avez la possibilité de tester la ROM sur diverses bécanes (GT, TurboGrafx, voire des consoles FPGA), le résultat m'intéresse !

[Zhebus]

Hello Kami,

Je testerai sur la SGX et la core (et Mister possible aussi), je te ferai un retour.
Bravo et merci pour l'explication des différences entre PCE et SGX.

edit: mais il n'y a que le fichier sgx en tech demo? tu n'as pas le fichier pce pour tester sur pcengine?

[Kaminari]

Merci Zhebus

La ROM contient le code PCE/SGX, c'est pour ça qu'elle est hybride

L'extension .sgx n'a pas d'importance sur une vraie console. Elle ne sert qu'aux émulateurs comme Mesen ou Mednafen pour forcer le mode SGX. Sans cette extension, ces émus ne sont compatibles qu'avec les 5 jeux commerciaux officiels...

[Zhebus]

Ok du coup j'ai testé sur SGX et Le mister et tout marche nickel (j'avais déjà testé Magician Lord et in the hunt).
Je dois rebrancher ma core, je testerai ce soir si j'ai le temps.

Je peux faire une vidéo si besoin

[Kaminari]

Merci du retour pour le Mister !

J'ai déjà testé la ROM avec succès sur PCE et CGX. Pas ressorti la CGX2 ni la Duo-R, mais ça devrait tourner sans soucis.

Si vous avez un Super HD System qui traine, je suis curieux de savoir si ça tourne ou pas avec l'émulateur SGX intégré. D'après les limitations techniques indiquées par Terra Onion dans leur manuel PDF :

Due to the way SHDS3 Pro interacts with the original SuperGrafx software to use as much original hardware as possible,
some game calls may need to be modified on SuperGrafx homebrew in order to obtain full compatibility.

Du pur charabia.