[Grandia [Jap] Problème d'affichage sur les batailles...

[BenjaminSiskoo]

Kronos 2.3.1 Mode CS/OpenGL

Savestate :

T-4507G_001.zip

[fafling]

C'est déjà un problème connu, voir #903. Une sauvegarde avant un combat serait utile pour suivre l'évolution du problème en fonction des versions de Kronos.

[Starhowl]

Kronos 2.5.0 recently has been released; does the issue still persist?

[BenjaminSiskoo]

@Starhowl Unfortunately, it's freezing on a black screen juste before going in game. So I don't know

[BenjaminSiskoo]

kronos20240928_facf927

savestate : grandia bataille.zip

[fafling]

Le jeu utilise un framebuffer de type rotation 8, donc de taille 512x512 en 8bpp. Il doit transférer une partie de ce qu'il a dessiné dans le framebuffer vers le NBG1 qui est un bitmap 8bpp. De plus, la zone du framebuffer affichée par les sprites peut être décalée ou transformée par le paramètre de rotation A du RBG0.

Apparemment Kronos a l'air de transférer les pixels 8 bit du framebuffer en leur ajoutant un octet pour en faire des pixels 16 bit. Cela double la taille des données transférée et explique leur aspect en pointillés sur le NBG1. Comme les données transférées ou doublé, elles ont pu effacer des données de la VRAM VDP2 qui se trouvent dans la partition B0 qui suit la partition A1 qui contient le bitmap du NBG1 (bitmap address 0x20000). La partition B0 contient aussi un bitmap 8bpp qui sert au RBG0.

[FCare]

Grandia lit le framebuffer en Word.

La partie haute est toujours a 0: R W 0x1@0x94b2 (105, 17) R W 0x1@0x94b4 (105, 17) R W 0xd4@0x94f6 (105, 17) R W 0xd4@0x94f8 (105, 17) R W 0xd4@0x94fa (105, 17) R W 0xd4@0x94fc (105, 17)

[FCare]

[FCare]

Il est necessaire de prendre en compte le format du vdp1 (8 bits ou 16) quand on accede le framebuffer en lecture (et surement en ecriture).

En Vdp1 8 bits: Acces Byte = 1 pixel Acces Word = 2 pixels Acces Long = 4 pixels

En Vdp1 16 bits: Acces Byte = 1/2 pixel Acces Word = 1 pixel Acces Long = 2 pixels

Dans tous les cas, le framebuffer est exporté en RGBA8, soit 32 bits par pixel, que le pixel fasse 8 ou 16 bits.

Donc dans le cas du :

• Vdp1 8 bits, 1 pixels est present tous les 32 bits en byte le plus bas
• Vdp1 16 bits, 1 pixels est present tous les 32 bits en word le plus bas

Chaque pixel necessite un decalage*4 de l'adresse dans la texture du framebuffer.

Il doit en etre de meme pour le write.

[FCare]

quand c'est bleu: Couche vdp1: on voit bien un personnage avec des codes couleurs differents

Ensuite, il y a un read sur le framebuffer du vdp1

Mais ensuite, dans la couche VDP2, on voit que les codes sont tous les memes:

Donc lors de la lecture du contenu du vdp1 et de la conversion manuelle du programme de jeu avec la vdp2 color ram, ca semble mal se passer

[fafling]

Non, le transfert vers le VDP2 se passe plutôt bien et ce sont les couleurs affrichées par les sprites qui sont incorrectes. On le voit quand on désactive les sprites. Le perso alterne entre couleur uniforme et sa texture normale parce que le jeu le fait clignoter.

Bizarrement il manque une partie des graphismes dessinés sur cette partie du framebuffer dans ce qui est transféré sur le NBG1. Ce sont toutes les 1ères commandes qui sont manquantes. Par exemple l'épée qu'on voit en haut au centre :

Dans l'écran debug du VDP1, ces commandes ont les couleurs correctes, alors que les commandes suivantes qui dessinent ce qui passe sur le NBG1 ont toutes des textures entièrement vertes sur les pixels non transparents. Par exemple la tête de la fille en haut :

A priori, il doit manquer dans le framebuffer ce qui est dessiné pour l'arrière plan, probablement par une autre liste de commandes, et/ou kronos n'affiche pas la bonne partie du framebuffer sur les sprites.

[fafling]

En fait ces commandes de dessin avec textures "vertes" sont des commandes d'effacement. On peut le voir grâce à la 1ère commande de la liste qui dessine un polygone en haut à gauche de l'écran avec le code palette 0 comme couleur, et qui s'affiche en vert aussi.

Conclusion, la liste efface des sprites dessinés précédemment au même endroit par une 1ère liste qu'on ne voit pas dans Kronos, et qui utilisait des color look up table différentes. La lecture dans le framebuffer des données transférées vers le NBG1 doit avoir lieu entre ces 2 listes.

D'après Mednafen :

• Les sprites transférés dans Kronos sur le NBG1 sont corrects.
• Les personnages et ennemis qui sont affichés sur les sprites avec de mauvaises couleurs par Kronos ne devraient pas y être. Il manque donc leur effacement dans Kronos. Un possible suspect serait le polygone d'effacement en début de la 2ème liste qu'on voit dans Kronos, dont les coordonnées pourraient être incorrectes. Où bien des commandes d'effacement des sprites des perso et ennemis ont été écrasées ou non exécutées (mauvais saut ou liste intermédiaire non exécutée ?).
• L'arrière-plan manquant dans Kronos est sur le bitmap du RBG0. On ne voit pas sa texture dans le viewer VDP2 de Kronos lors du combat chargé par la save state de @BenjaminSiskoo car elle garde la conséquence du bug de doublement des pixels transférés, qui a effacé le bitmap du RBG0. Mais si on commence un nouveau combat ensuite, on voit cette texture dans le viewer du RBG0 :

Le RBG0 ne s'affiche peut-être pas à cause d'une mauvaise interprétation de la rotation window dont la zone couvre tout l'écran. L'écran débug du VDP2 n'indique pas si c'est l'intérieur ou l'extérieur de la zone qui est actif.

Save state d'un combat sans le bug de doublement du transfert vers le NBG1 : grandia_bataille_sans_bug_transfert.zip

Et back up ram avec une sauvegarde avant les combats au cas où la save state ne fonctionnerait plus : bkram_Grandia_avant_bataille.zip