Open fafling opened 4 years ago
Patch en cause: d0686b2207cf9429b774fab25b7fab373d1a05c8 Encore...
La vidéo d'intro est cassé depuis un bone moment aussi
Régression dans les 2 noyaux suite au patch corrigeant #1400 , capture en CS :
Meme source pour deux textures differentes: new DMA(2619) 6074f60 to 25c00000 new DMA(2619) 60d9210 to 25c02000 vblank new DMA(2619) 6074f60 to 25c00000 new DMA(2619) 60d9210 to 25c0e400
C'est normal en fait, il y a deux joueurs qui courent. Par contre la texture n'est pas complete
Le MSH2 copie une texture de 224 a 224 a partir de la ligne d'ecran 225 jusqu'a la ligne 236.
Le DMA copie cette texture sur la ligne 225 de la trame suivante.
Hatrick hero est en one cycle mode sur le VDP1, donc en 60 fps sur les sprites en NTSC (ce qu'on voit sur le compteur de frames du VDP1). La résolution verticale du VDP2 est en 224 lignes. Le jeu transfère donc une texture vers la VRAM à chaque vblank, en considérant que le VDP1 a fini de tout dessiner à ce moment-là.
Si on regarde le contenu de la zone mémoire de départ, il change régulièrement. J'ai regardé à peu près où se situe le milieu de la texture, à 0x60d9210 + (112*224) = 0x60df410. Il semble donc s'agir d'une zone mémoire de travail en HWRAM où le jeu décompresse une texture avant de la transférer vers la VRAM.
Cette zone est probablement effacée entre chaque décompression. Peut-être que cet effacement commence trop tôt, ou bien progresse plus rapidement dans Kronos que sur la console ce qui le ferait effacer des ligne de texture avant qu'elles ne soient transférées vers la VRAM, ce qui expliquerait les textures incomplètes en VRAM.
Normalement, si un transfert DMA, SCU ou CPU, est en cours à partir de la HWRAM, les CPU n'y ont pas accès tant que le transfert n'est pas fini. La seule possibilité d'accès concurrent est le CPU DMA en mode cycle steal.
En ligne 234, le MSH2 ecrit 0 En ligne 234, le DMA ligne 0 En ligne 240 le MSH2 ecrit la texture.
Il y a une race entre le DMA et le MSH2 sur la HIgh WRAM.
Soit le DMA est trop rapide, soit le SH2 est trop lent.
HIWRAM WL 60dbc7c 0 MSH2 (234) HIWRAM WL 60dbc78 0 MSH2 (234) HIWRAM WL 60dbc74 0 MSH2 (234) HIWRAM WL 60dbc70 0 MSH2 (234) HIWRAM RW 60dbc70 0 DMA (234) HIWRAM RW 60dbc72 0 DMA (234) HIWRAM RW 60dbc74 0 DMA (234) HIWRAM RW 60dbc76 0 DMA (234) HIWRAM RW 60dbc78 0 DMA (234) HIWRAM RW 60dbc7a 0 DMA (234) HIWRAM RW 60dbc7c 0 DMA (234) HIWRAM RW 60dbc7e 0 DMA (234) HIWRAM WB 60dbc72 16 MSH2 (240) HIWRAM WB 60dbc73 18 MSH2 (240) HIWRAM WB 60dbc74 35 MSH2 (240) HIWRAM WB 60dbc75 17 MSH2 (240) HIWRAM WB 60dbc76 19 MSH2 (240) HIWRAM WB 60dbc77 17 MSH2 (240) HIWRAM WB 60dbc78 16 MSH2 (240) HIWRAM WB 60dbc79 16 MSH2 (240) HIWRAM WB 60dbc7a 17 MSH2 (240) HIWRAM WB 60dbc7b 17 MSH2 (240) HIWRAM WB 60dbc7c 18 MSH2 (240) HIWRAM WB 60dbc7d 19 MSH2 (240) HIWRAM WB 60dbc7e 17 MSH2 (240) HIWRAM WB 60dbc7f 1a MSH2 (240)
Les sprites sont de nouveau tronqués dans la dernière WIP et en v2.6.2 publique.
Le problème réapparaît en WIP du 18/12/2023 (https://github.com/FCare/Kronos/commit/341106d270c4ca32714fe4b8a8bce5930f44cf38) qui fixait l'effet de rémanence de Fighters megamix. La précédente du 17/12/2023 (https://github.com/FCare/Kronos/commit/145c281977c2ec9cafc2e33aa83313ad28bea58a) ne l'a pas.
@BenjaminSiskoo Est-ce que tu peux rouvrir ?
Dans la dernière WIP et depuis celle du 02/09, le bas des joueurs est tronqué pendant l'intro dans les 2 noyaux :
Affichage correct en v2.1.3 publique :
Screens faits en CS, en OpenGL l'affichage du RBG0 est incorrect (#235 ).
Testé avec le redump.