VI: Implement post-scanout XFB output #9993
Conversation
|
Can't read the code, but tested. Fixes WWE Crush Hour. |
| { | ||
| // If the game does change VI registers while a frame is scanning out, we need to defer output | ||
| // until the end when all those changes have been collated. |
There was a problem hiding this comment.
Not accurate. This code-path only uses the last update to VI registers, all other updates get discarded.
In the case of WWE Crush Hour, there is probably a tiny bit of tearing that we are not emulating. The
// To correctly handle that case we would need to collate all changes
// to VI during scanout
comment from before should be preserved for future reference, but I don't really think it's worth actually implementing that just to emulate a bit of glitchyness in this one game.
There was a problem hiding this comment.
Maybe also comment to state that this still isn't accurate.
There was a problem hiding this comment.
Isn't that essentially what collating the changes is though? The alternative would be handling the scanout pixel by pixel and changing things as the registers get updated during scanout, which obviously isn't viable for for a hardware backend and really slow to implement in software.
There was a problem hiding this comment.
collating means collecting (and implies actually using them) rather than discarding.
Shouldn't be too hard to actually implement in a hardware implementation. Just a collect a list of regions, with the vi properties and XFB buffers they refer to. Then issue a draw call for each region to draw that section of XFB into the final output buffer.
The rendering cost when there is only one update as expected will almost identical to the current implementation. You just pay a tiny bit of overhead for each additional region that needs to be drawn (and slightly more overhead again when a region starts outside of hblank)
But IMO, not worth implementing, unless some demoscene intro exploits it.
|
To be clear, this isn't more accurate. It's just inaccurate in a different way that produces an acceptable result with this one game. |
This adds about a frame of latency, and since most games don't change VI registers during scanout, we can get away with outputting the XFB at the start of scanout. WWE Crush Hour is the (only currently known) exception, which has flickering problems when doing it this way. This adds a path to perform the output at the end of scanout, and gates it behind an option which defaults to using the latency-reducing pre-scanout path.
The game has flickering problems when using early output.
This adds about a frame of latency, and since most games don't change VI registers during scanout, we can get away with outputting the XFB at the start of scanout. WWE Crush Hour is the (only currently known) exception, which has flickering problems when doing it this way.
This adds a path to perform the output at the end of scanout, and gates it behind an option which defaults to using the latency-reducing pre-scanout path.
I also included the appropriate INI change.