Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Existing FMV fix thought.
#1
Hi! Before I get into it, I wanna thank the people behind this project a lot for all their efforts. I've been using PCSX2 off and on over the years trying to learn how best to use it with my differing hardware configs and despite being a challenge at times, it's also been pretty useful to learn how this stuff works.

Anyway, to the point at hand, which I gather has been a persistent obstacle across many games and iterations of PCSX2. The somewhat frequent FMV issue, which more recent versions of PCSX2 have tried to work around with the plugin mode switch fix is great, for the most part, except for one minor issue I've noticed (which I'm sure others have too).

When the plugin mode is switched, there's a hiccup as the emulator (I assume) tries to rerender the scene using that different method. This hiccup can vary in duration, I suspect, depending on the user's hardware config (as well as, I imagine, whatever else the PC's trying to process at the time). With this being the case, and I'd try to adjust this myself if I knew where to look, it seems like it may be better to offer an option to set when this switch occurs a moment preceding the FMV and a moment after (so reentry into in-game talk isn't disrupted).

I'm not sure how the current fix is operating (again, not sure where to look) so I'm not sure if there's another technical challenge underlying this, but seeing as it's already automatically switching for games somehow, it occurred to me that providing a means to adjust that automatic switch could be beneficial.

Hopefully this makes sense. If not, here's an abbreviated version to cut out any syntactical fluff that may create confusion:

-FMV game fix that switches graphical plugin's mode (hardware to software) currently activates a little too shortly before FMV occurs.
-Due to this, when the mode switch occurs, it creates a hiccup/delay as PCSX2 attempts to make the switch, distorting FMVs' quality at times (e.g. audio stretching/dragging as PC tries to catch up.
-Following that, when it switches back to the user's default plugin mode (e.g. hardware) for in-game scenes, it repeats the distortion error by stretching the characters' dialogue.
-Provided this, and the likelihood it's rooted in the users' hardware config in general, it may be a good idea (if possible) to enhance the fix by giving it settings to adjust when the switch occurs (a minute or more preceding a FMV/succeeding FMV).

Still not an ideal solution, but could prove better than the existing one given that it doesn't require the user to have played the game before and know when FMVs are coming or to spoil it for themselves so they can tap F9 ahead of each.

Anywho, thanks very much again for all the dedication to this project! I've had a load of fun experimenting with it with various games. =D
Reply

Sponsored links

#2
Switching before the fmv flag was set is not possible as one can not know when a fmv is triggered. But I think this is not your idea.

To enable a delay should be possible. But I question that this will change anything. If the hiccup appears because of renderer-switch you will always observe this. Independent on the delay. I would rather like my hiccup in the beginning of a fmv not somewhere in the middle. Same is valid for switching back. Would be strange to play for one minute when suddenly HD strikes you (& a hiccup)...

But it could be that this hiccup is not even due to renderer switch but due to load times. Sometimes there is large data-transfer when scenes change/new textures are loaded. This is well known for FFX. Therefore the hiccup might not be solvable by delayed renderer switch. Simple test: disable automatic switch.

If loading issues are present it would be good to test if they disappear on a RAMDISK (if your system has sufficient RAM).

If you really want to stick to this idea of a delayed switch we might be able to help you to program it by yourself if you have basic knowledge (and possibly visual studio as environment). I think it is like a 5-10 liner for non-thread safe solutions (short delays) and maybe a 10-20 liner for a thread safe (unlimited delays) solution.

And now the mean part: I think spu2-X setting synchronization mode -> async mix will absolutely solve your problem. But since you wrote a wall of text I can do that as well. :-P
Reply
#3
Heh. Yeah, sorry about the wall of text. I did try to cut it down at the end if anyone was skimming and wanted to get to the major points of it.

Anywho, so about the very last point there...It's definitely not all in the audio, so I don't think it's in that alone.

I think we're mostly on the same page about this, and I should've noted that I have tested this with the auto-switch disabled. There is absolutely no delay in the transition to the FMV when run in this manner, but then we run into why the fix was created to begin with, which is that they glitch (e.g. Silent Hill 2's FMVs render at a lower position than they should w/ hardware mode). Unless I'm misunderstanding the point posed there, I believe this indicates the source of the delay is not entirely in scene change/texture load-in but instead in the plugin switch.

You're also right regarding that a delay will appear regardless, but at least in my experience with running some tests, the effects of the plugin mode switch are less pronounced (i.e. they subside faster) when not at the start of FMVs rather than at them. As you noted, a simple test can bear this out: disable FMV fix, switch plugin modes back and forth with F9 as you play a game.

However as I note in my OP, this may vary between users' configs, so it may be that you don't observe the delays that I do when running with the fix, which led me to the conclusion that permitting the enabling/setting of delays before switching might be the next best solution.

(As a sidenote: I have tried simply running with software mode, but then visual glitches crop up, so it makes more sense to me to just work with the awkward pauses occasionally before a FMV loads up.)
Reply
#4
Rama had already remarked that the FMV fix isn't coded all that nicely, It would possibly have to be revamped a bit, that's why no games use the FMV hack as a default gamefix.
We're supposed to be working as a team, if we aren't helping and suggesting things to each other, we aren't working as a team.
- Refraction

[Image: 84t1dRu.png]
Reply
#5
Aah, that sounds like what I thought might be the case. Which is also why I thought it might be good to throw some input in for whenever it might get revised. =)
Reply




Users browsing this thread: 1 Guest(s)