Gsdx black fmv #1222
Gsdx black fmv #1222
Conversation
|
Your third commit causes some graphical issues on Bomber man Kart and also random crashes at few instances. Compiled without third commit: compiled with third commit: |
|
Third commit also causes random crashes on Ben 10 : Protector of earth. though without any graphical glitches. The issue isn't reproducible with the first two commits. |
gregory38
force-pushed
the
gsdx-black-fmv
branch
2 times, most recently
from
4df3439 to
21a1c4d
Compare
|
Only the latest commit impact the rendering. I updated the code to support 16 bits format. And to check the size of the upload. I'm not sure it will fix the crashes but it won't be worst. |
|
the new commit seems to fix to all the regressions, I'll try doing an indepth test later. |
|
Oh great. Today is my ludky day. Texture blocks are 2 time smaller in 16 bits, so I guess it was overflown. By the way, it must be tested without the "Switch to GSdx SW when an FMV plays" gamefix. Hopefully it will become useless. |
|
I'll test GT4 later; just hope it will get past the copyright screen :( |
|
I doubt this will fix GT4, that doesn't even work in software mode, the video doesn't even actually play as far as I'm aware. |
I assume it's a core issue ? Edit: I did further testing on the build for regression at some more games and it seems to be fine. I didn't test any games with broken FMV's though, I don't have any such games. |
|
This commit hasn't fixed any software mode-only video's I've tried. I still needed to f9 to software mode to see the video's. |
|
@FlatOutPS2 Please explicitly state games so we don't test the same games again... |
|
@FlatOutPS2 |
|
Here are two video GS dumps that only play in software mode: |
|
Thanks you. I can reproduce the bug on my side. Now remains to understand the issue and to fix it. |
|
Hum, trailer seems to work with the preload hack (at least on the dump) |
|
On the other dump (spy hunter), it is very interesting. @ssakash will love it. So the game uses an internal resolution of 640x512, very standard. But it draws the texture on the rectangle (0 , 992 ) x (640, 1232). In native resolution the FB is 1280x1024... So you can understand that texture is drawn in the void.... Currently the source texture is located at 0x1400 and the FB at 0x0 (FBW == 10). The pixel (0) x (992) is therefore located at (992/32) == 31th height page. A page row is 320 blocks. So we are around 0x26C0 which mean in the source texture. In others word, the game overflow the frame buffer to draw into the texture. It copies (blits) data from the top of the texture to a lower part... Now I can search a rope to hang myself :p I dunno how to fix it. Let's try a bigger FB to see if it "fixes" the bug. Good new the bottom part is correctly drawn in the FB. Bad new the texture isn't invalidated so there is a texture cache bug too. |
|
Ok I understand the texture cache bug. What ought to be the correct version |
|
FWIW, I added a check on FB size. And it seems that the "trailer.gs" also draw outside of the FB, namely between 1024th line and 1280th line. I give it a closer look and it seems a similar pattern as above. I really don't know how to fix it. So far, it seems FMV rendering is done after the line 1024, so maybe I can try to detect the pattern and completely invalidate the RT target. It won't be fast, but it could be enough for a couple of FMV. Boys, it is time to find game that suffers of this issue, so I can polish my idea. |
gregory38
force-pushed
the
gsdx-black-fmv
branch
from
21a1c4d to
d750ba7
Compare
|
I pushed a tentative fix for native resolution. Please test some games @ramapcsx2, @FlatOutPS2 |
|
It doesn't fix it. It did show some vertical lines dancing on the screen at times, but it's stil black most of the time. This happened with all the games I tested. Edit: The vertical lines appear when the entire screen is used by a video. Most video's have black borders to give a "cinematic" feel, and with those the screen is just black, so it only sees either the very bottom or the top of a video and stretches it accross the screen as vertical lines. |
|
Just to sure, you're in native mode. |
|
Yes, it's completely black at higher resolutions. |
|
Ok. The issue is the texture cache management. I suspect I fix the bug in the middle of the flow, it means that if the texture cache is correct at instant T of the video, the next frame will be correct. However I suspect a bug remains in the start of the video. First frame is likely wrong, and it is likely reused. I would need a bigger gs dump, one that start before the FMV so cache is polluted with wrong data. |
|
Is this enough? |
|
Did you try with the preload hack? |
|
Yes, same result. |
|
Hum I slowed down the rendering, and I spot a couple of glitches. However I'm far from a black screen. Could you tell me the complete name of the game? I will try to find it in my local resellers. |
|
I have a trail. Here a texture cache lookup of the frame. We try to load data from pointer 0x800. I can you see there are 2 valid buffers. One that ranges from 0 to 0x2800 and the others one that ranges from 0x800 -> 0x1000. The texture cache take the 2nd one. But I think it mustn't exists, because it is a subpart of the first buffer. Indeed if I check the texture, the small buffer is fully black. |
|
Thanks for your report. I will revert my change for the auto-detection of the height. It requires 2 frames to stabilize, and just fill the texture cache with junk. |
The hint is based on the rendering
It often happens the game try to upload the FMV directly which typically gave a black screen. Commit fix rules of roses and I hope various black screen FMV Performance impact must be tested, and I'm afraid of strange texture cache behavior. V2: check the size of the transfer too V3: add support of 16 bits format V4: avoid division by 0
It will be used in the following commit
It will be used in next commit. However, it might not be the best solution
The long story: Game blits FMV far aways of the RT which is actually the input of the RO texture... Currently GSdx suffers of 2 bugs. 1/ RT is too small 2/ texture isn't properly updated with the rendered value. Texture is invalidated but it reads back the pixels from the GS memory whereas the correct value is located on the GPU. This commit will replace the standard draw by a manual blit. Therefore it avoid size issue and bad upscaling issue. v2: * Use various copy to be more compatible with dx api * Move all part of the hack info the BlitFMV function v3: add log message
Try to avoid random black screen frame v2: don't force the preload hack on the frame It creates a ghost image over FMV v3: support offset within a frame
So let's increase the height. It will increase the memory requirement on some games v2: try to do it automatically (not sure it will useful as most game will requires it) v3: let's back to an hardcoded 1280 size. It generates too much issue
gregory38
force-pushed
the
gsdx-black-fmv
branch
from
01b3651 to
8943a9d
Compare
|
I reverted my auto detection code. On 007, I don't have the flickering on the dump. And the gap is normal. The game renders the FMV as line. FF DoC uses points. Hack is possible (by replacement of the line by some sprite with the CPU or a Geometry Shader) |
|
Here's another game that's still suffering from FMV flickering (as of 8943a9d)... Monster Attack
|
|
@Aced14 I think your dump is too small. I can't reproduce the issue on my side. |
|
@gregory38 Here's a multi-frame GS dump of Monster Attack: Just to provide more information, when this game starts up, it checks for memory card data, then proceeds to show company logos. The first logo is a static image for "agetec" (fades in/out and works fine in all GSdx modes and renderers). The second logo is for "D3 PUBLISHER", which uses an FMV. In GSdx hardware (both OGL and DX11), that particular FMV flickers heavily between black and its "real" video frames. It doesn't flicker in GSdx's software modes. |
|
@Aced14 could you provide me a short iso dump? Try to search on forum how to generate it, I don't remember which plugin can create it. I didn't manage to reproduce the issue with the GS dump. Otherwise I think I will merge the PR. So far it seems to solve more bug than to introduce new one ;) |
|
@gregory38 Monster Attack: Block dump. From what I researched, it seems that only the Linuz ISO CDVD plugin can read/write block dumps. But it's not included in modern PCSX2 builds. I copied it out of a summer 2014 build and used it within this PR's latest AppVeyor build. |
|
Finally the rules of rose FMV can be render in hardware mode. |
|
This PR introduces half-screen issue with Splinter Cell Chaos Theory : half bottom is black. Should I add it to #1339 ? |
Thanks :) I have added it for you to the "Extra" list as it has a link to here. |
Commits fix rules of roses and I hope various black screen FMV
Performance impact must be tested, and I'm afraid of strange texture cache behavior.