Magician Lord (démo technique SuperGrafx)

[touko]

Pas de soucis, si tu as des questions sur l'outil ou un pb n'hésites pas, car des fois je pense être clair dans mes explications, ou celles de l'outil et je ne le suis pas .

Précision, tes calques doivent être en .bmp indexés 16 couleurs, avec la couleur 0 bien positionnée
Je mets aussi les fichiers .bmp directement au même endroit que l'outil, je suis pas sur d'avoir intégré la prise en compte d'un chemin .
EDIT: Je confirme .

Précision 2 : MergeBMP2PCE.exe 0x1000 1 *.bmp directement fonctionne aussi .

[GameOver]

Je ne comprends rien ou presque à vos échanges, mais en tout cas la démo est superbe !
Bonne continuation.

[touko]

@Kaminari : Pour la doc de Huc dans le répertoire de huc tu as un dossier doc où la doc des fonctions est en html et en format texte(choisis la version classique pas fr,car pas du tout à jour il me semble), par contre je sais pas si dans la version 4, elle a été mise à jour .

[Kaminari]

La doc de HuC 4 date de 2005, c'est toujours celle de la version 3.21. Pour l'essentiel, elle reprend les infos de Magic Kit adaptées au C. Je me suis surtout servi des includes SGX (et du petit test de scroll fourni dans les exemples de code) pour essayer de comprendre les nouvelles fonctions.

Je me demande par ailleurs si HuC 4 n'a pas un gros bug avec la SGX.

J'ai fait des tests de résolution en 336x224 avec l'instruction set_xres(336), et seul le VDC1 bascule correctement en 336. Le VDC2 est corrompu de manière bizarre, comme si la console voulait le forcer en 256. L'écran est coupé sur la droite (justement à partir de 256 pixels) et il manque une ligne sur deux.

Exemple avec l'arrière-plan de In the Hunt (émulateur Mesen) :



Le bug apparait sur le hardware et avec Mesen, mais pas avec Ootake qui affiche le plan correctement. J'imagine que Ootake interprète set_xres comme une instruction valide pour les deux plans et force le 336 sur les deux VDCs.

Le problème est qu'il n'existe pas à ma connaissance d'instruction SGX équivalente, genre sgx_set_xres. Ce qui semble logique vu que la SGX ne peut pas mixer deux plans de résolution différente (contrairement à la PC-FX). L'instruction set_xres devrait normalement être suffisante...?

@Touko, tu as rencontré ce problème avec ton Shinobi SGX (qui je crois est aussi en 336) ? Aurais-tu une solution pour HuC ?

[touko]

L'instruction set_xres devrait normalement être suffisante...?

Non, faut changer la conf du VDC SGX au niveau de la gestion de l'image via les registres d'affichages .
Cette fonction ne le fait que pour celui de la PCE, donc tu te retrouves avec un dotclock de midres, mais avec des réglage pour un dot de lowres.

@Touko, tu as rencontré ce problème avec ton Shinobi SGX (qui je crois est aussi en 336) ?

Non j'utilise mes propres fonctions/libs .

Aurais-tu une solution pour HuC ?

Je vais essayer de voir,mais ça ressemble à un VDC mal initialisé au niveau des registres d'affichages .
set_xres paramètre que le VDC1 (PCE) et pas celui de la SGX .

EDIT: J'ai regardé les fonctions, et l'init du VDC2(SGX) ne se fait qu'au démarrage donc en 256 pixels, set_xres de HuC ne param que le VDC1 donc le problème me semble là .

[Kaminari]

Ok, merci du diagnostic

Ça confirme mes craintes, il faudrait une instruction dédiée sgx_set_xres. J'ai zieuté les sources (library.asm) mais c'est de l'assembleur bas niveau et totalement hors de mes compétences. Surprenant que Malducci n'ait pas pensé à l'implémenter avec les autres fonctions (sgx_load_vram etc). Il a dû se dire que le 256x224 ferait le job pour tout le monde

Je vais transmettre le problème sur le github de HuC 4, mais je ne sais pas qui se charge du développement aujourd'hui. Elmer ou Dave ? Il n'y a plus de mise à jour depuis mai 2023.

[touko]

Il faudrait surtout inclure le VDC de la SGX dans la fonction set_xres, perso j'ai fait comme ça .

Surprenant que Malducci n'ait pas pensé à l'implémenter avec les autres fonctions (sgx_load_vram etc). Il a dû se dire que le 256x224 ferait le job pour tout le monde

Je pense que c'est plus un oubli car il faisait ses tests classiquement en 256 pixels .

Je vais transmettre le problème sur le github de HuC 4, mais je ne sais pas qui se charge du développement aujourd'hui. Elmer ou Dave ? Il n'y a plus de mise à jour depuis mai 2023.

C'est elmer, mais si t'as pas de réponse concluante, je te ferai la modif, il me faudra juste ton huc de dev + tes ressources pour faire les tests .
Soit on intégrera ça dans la fonction, soit faire une fonction dédiée,qui bouffera encore de la ROM .

[Kaminari]

Quel bel homme

Pour le kit de dev, j'utilise la distrib standard de HuC dispo sur le github. Je n'ai pas modifié les fonctions. Si tu penses qu'un set_xres unifié est pour le mieux, je te fais confiance !

Pour les ressources, je te filerai mes deux calques et le bout de code que j'utilise pour afficher l'image en 336. Je verrais ça ce soir ou demain.

Pour info, voici comment ça rend avec Ootake :

[touko]

Pour le kit de dev, j'utilise la distrib standard de HuC dispo sur le github. Je n'ai pas modifié les fonctions. Si tu penses qu'un set_xres unifié est pour le mieux, je te fais confiance !

Ca serait le mieux pour la praticité (1 seule fonction) et le plus simple, mais chiant si tu fais une maj du kit .
Perso c'est ce que j'ai fait .

Pour les ressources, je te filerai mes deux calques et le bout de code que j'utilise pour afficher l'image en 336. Je verrais ça ce soir ou demain.

Pour les sources, c'est juste par flemme, si je peux éviter d'avoir à faire/inclure les données ça me fera gagner du temps .
L'idéal c'est d'avoir ton bout de code et les includes dedans pour me faciliter la tâche et me permettre de faire la fonction de suite .

Pour info, voici comment ça rend avec Ootake :

[Kaminari]

Je t'ai envoyé un MP.

[Edit] Merci pour ton support technique ! On devrait tous avoir un service info aussi compétent et surtout gratuit

[touko]

Lol c'est gentil, mais faut pas pousser

Si je peux rendre service ce sera avec plaisir .

[Kaminari]

J'ai mis la ROM de Magician Lord à jour avec un début de commencement de gameplay

On peut marcher, sauter, s'accroupir... bref, les bases de l'animation d'un perso. Je n'ai pas la prétention de faire le portage d'un tel jeu, mais il se trouve qu'il me rend bien service pour expérimenter plein de petits trucs

Sur l'écran-titre, vous pouvez aussi afficher séparément les deux plans de la SGX (avec I et II) pour voir un peu comment tournent les parallaxes.

[touko]

C'est déjà pas mal
C'est clairement formateur, après ça, rien ne t'empêche de te lancer dans une vraie conversion arcade, en choisissant un projet moins difficile et essayer de le mener jusqu'au bout .

[franz]

On n'a pas de Tetris sur PC Engine.
J'dis ça j'dis rien...

[Kaminari]

Mais si

Blox par notre ami Dave Shadoff