Closed legluondunet closed 4 months ago
I joined you the log file: onimusha_log.txt
i'm not sure what to make of this one. the NTSC version plays the video.. but then again the ntsc version is 3.9GB. The PAL version is 2.1GB and looks like it wants to start playing the video but doesn't and skips right to a cinematic closer to in-game.
the opening cinematic is a pretty long video and i just wonder if they didn't just drop it for some reason on the PAL version. anyone with a pal ps2 could test on hardware.
To answer Seta-San's question (If it isn't already): After a youtube search:
https://www.youtube.com/watch?v=Lnllcxmbu6Q
Video is played.
That video does NOT play on the PAL version on PCSX2.
That video does NOT play on the PAL version on PCSX2.
It was in response to seta-san asking if anyone could test if the video is even played on the PAL Version by testing it on hardware. That video, from what I can tell, is the Pal Version on PS2.
Look at the size difference between the two NTSC version. http://redump.org/disc/3769/
PAL http://redump.org/disc/720/
That video is the pal version and it sort of confirms my suspicions. This issue was likely made based on a bad dump that is probably ubiquitous online because the info on redump seems to be based on the same bad dump. This issue is most likely invalid.
Buying a fresh copy, so we'll find out
This is timing issue, +3 cyclerate is required for video to play. +2 play it too, but end too early.
It still skips it completely here.... But I will get a new copy of the game in a few days and confirm if it's a dump problem.
It literally flashes up one frame them disappears here.
Sorry, it was -3, not +3.
Okay that makes more sense, and my video does play with that setting.
Bad dump with a compressed iso leading to cdvd timing issues?
iso compression is completely transparent to the emulation
I did have a quick look at this, at normal cycle rate I'm not quite sure what's going on.... it starts an FDEC command (skip n bits then return the next 32bits of the bitstream) after clearing the input and turning off IPU_TO DMA, but the command never finishes, because the game never starts IPU_TO DMA or sends any data in the FIFO. So eventually the game just gives up and cancels the movie.
I'm not sure why it's different with a different cycle rate, it's very strange..
What does it do on the ntsc version?
Not sure, didn't look. But the size discrepancy is apparently because the NTSC version also contains the japanese FMV's.
Although it's a moot point now, I can indeed confirm that the disc is 2GB for the EU region, as I just ripped the copy I got in the post
Well. Insane timing issue it is. How to make the Ipu respond faster?
I doubt it's as simple as that....
Game abort video because one frame take too long to decode (display?). When frameAbort_timer in custom function readMpeg hit previously set value, game jump to videoDecAbort(). Developer expected some issues, and patched PAL release to increase that value by 10 times comparing to NTSC releases (from 30 to 300 very long loops).
Only place where frameCount can change is function _decodeOrSkipFrame, part of Sony MPEG library. Worth to note that _decodeOrSkipFrame, and readMpeg run at different threads juggled by RotateThreadReadyQueue.
check_frameCount:
0x1C0198 beqz $s0, first_run
0x1C019C nop
0x1C01A0 lw $v1, frameCount [8($s3)] <-- count added in _decodeOrSkipFrame
0x1C01A4 lw $v0, frameCount_old
0x1C01A8 bne $v1, $v0, new_frame
0x1C01AC nop
0x1C01B0 lw $v1, frameAbort_timer
0x1C01B4 addiu $v0, $v1, 1
0x1C01B8 slti $at, $v1, 0x12C (300)
0x1C01BC beqz $at, abort_decoding
0x1C01C0 sw $v0, frameAbort_timer
0x1C01C4 b continue__
0x1C01C8 lw $v1, controller_val
new_frame:
0x1C01CC sw $v1, frameCount_old
0x1C01D0 sw $zero, frameAbort_timer
0x1C01D4 nop
To play that video correctly on PCSX2 at default cyclerate 0x1C01B8 slti $at, $v1, 0x12C (300)
need to be patched to 0x1C01B8 slti $at, $v1, 0x1F4 (500)
. So it's really missing some timing by a lot, and messing with IPU code seems to not affect it. No idea how to fix this one, fact that devs decided to increase that time even on real hw doesn't make it easier for pcsx2.
It's likely expecting more bus contention with IPU and CPU I guess, which of course we can't really simulate (apart from having instant DMA's), which is an idea floating around, but need to think how to tackle it well
The intro movie is playing on both PAL and USA versions for me on the latest stable release with all default settings. Would be great if someone can confirm second hand
when I start a new game, I can see a cinematic:
The cinematic played until the end. I can not reproduce this issue.
Thank you PCSX2 team! The 2.0 stable version is such a great emulator and available even on Linux!
PCSX2 version: PCSX2 1.5.0-0 - compiled on Aug 10 2019
Description of the issue:
(What's the problem? - Screenshots showing the issue if applicable)
Hello, intro cinematic does not play correctly, stop after 1 second playing.How to reproduce the issue:
(Detailed step by step guide on how to replicate the issue)
Launch the game and stay at the first screen "PRESS START BUTTON", wait a minute, a cinematic should play but you only playing 1 second, then close.PC specifications:
(For example: CPU: Intel Core 2 Duo E4600 GPU: Gigabyte GTX 750Ti OS: Windows 10 64 Bit)
Ubuntu 19.04