Abnormal graphical & scaling behaviour in OutRun 2006 - Coast 2 Coast since ppsspp-v0.8.1-192-g925b3bc

[OlK76]

OutRun 2006 - Coast 2 Coast

Last revision to exhibit proper scaling behaviour is v0.8.1-177-g9b84f05
but since there are new "Framebuffer.cpp & Framebuffer.h to do Properly scale FBOs on copy to output".

See Issue #2569)

unknownbrackets opened this pull request 3 days ago
Copy only a screen's worth of pixels from FBO to output...
Merge pull request #2569 from unknownbrackets/fbo-scale …

Problem issue:-

1. Start the game intro in affected revision (0.8.1-192+) with default emulator settings.
2. Try to desactivate the mipmapping and buffered rendering options in ppsspp menu to better view the screen when playing.
3. Intro graphical & scaling abnormality observed since ppsspp-v0.8.1-192-g925b3bc.

Abnormal behaviour in v0.8.1-192-g925b3bc
http://img221.imageshack.us/img221/714/e3xv.jpg

Correct behaviour in v0.8.1-177-g9b84f05.
http://img203.imageshack.us/img203/6088/hjo4.jpg

[dbz400]

How about 0.8.1-190 which is the FBO scaling changes ?

[OlK76]

Yes, this is definitely this change that would cause!

[unknownbrackets]

Can you post a screenshot? I'm guessing it's the same as the Black Rock Shooter video.

-[Unknown]

[OlK76]

new "Framebuffer.cpp & Framebuffer.h to do Properly scale FBOs on copy to output".

See Issue #2569)

unknownbrackets opened this pull request 3 days ago
Copy only a screen's worth of pixels from FBO to output...
Merge pull request #2569 from unknownbrackets/fbo-scale …

Abnormal behaviour in v0.8.1-192-g925b3bc
http://img221.imageshack.us/img221/714/e3xv.jpg

Correct behaviour in v0.8.1-177-g9b84f05.
http://img203.imageshack.us/img203/6088/hjo4.jpg

[unknownbrackets]

Does it change with buffered rendering on or off?

-[Unknown]

[OlK76]

Yes, it change with buffered rendering off!

[dbz400]

@OlK76 , is latest revision fix all these issues ?

[OlK76]

Yes, thank a lot!

[dbz400]

Great. Close this issue when you ok .

[hdd60311]

This game is still blackscreen with menu

[dbz400]

Humm how about in-game then ?

[hdd60311]

It seems to have some serious graphic bugs

[dbz400]

Further investigation on this one and turns out if auto-generate mipmap is used even for desktop , it is all okay as well as texture scaling ON altogether .

    LoadTextureLevel(*entry, 0, replaceImages);
    if (maxLevel > 0)
        glGenerateMipmap(GL_TEXTURE_2D);

[dbz400]

Start with maxLevel = 2 or above, black texture occurs.

    glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAX_LEVEL, maxLevel);

[unknownbrackets]

How many levels does it actually send to GL? If you log the GL error after each one, do they all succeed?

-[Unknown]

[dbz400]

There are 3 , 4 , 5

52:09:134 ATRAC3 play E[HLE]: HLE\sceIo.cpp:1638 SCE_KERNEL_ERROR_NOASYNC = sceIoPollAsync(4, 09fc79d8)
52:09:134 ATRAC3 play I[HLE]: HLE\sceKernelThread.cpp:2085 sceKernelExitThread(0)
52:09:144 user_main I[HLE]: GLES\TextureCache.cpp:1228 Texture Max Level 0
52:09:145 user_main I[HLE]: GLES\TextureCache.cpp:1228 Texture Max Level 0
52:09:146 user_main I[HLE]: GLES\TextureCache.cpp:1228 Texture Max Level 0
52:09:146 user_main I[HLE]: GLES\TextureCache.cpp:1228 Texture Max Level 0
52:09:147 user_main E[HLE]: HLE\sceIo.cpp:1577 SCE_KERNEL_ERROR_NOASYNC = sceIoWaitAsync(4, 09fff500)
52:09:147 user_main I[HLE]: HLE\sceAtrac.cpp:936 sceAtracReleaseAtracID(2)
52:09:292 user_main I[HLE]: GLES\Framebuffer.cpp:580 Creating FBO for 000d4000 : 64 x 64 x 1
52:09:293 user_main I[HLE]: GLES\TextureCache.cpp:1228 Texture Max Level 4
52:09:295 user_main I[HLE]: GLES\TextureCache.cpp:1228 Texture Max Level 4
52:09:295 user_main I[HLE]: GLES\TextureCache.cpp:1228 Texture Max Level 4
52:09:296 user_main I[HLE]: GLES\TextureCache.cpp:1228 Texture Max Level 4
52:09:296 user_main I[HLE]: GLES\TextureCache.cpp:1228 Texture Max Level 4
52:09:297 user_main I[HLE]: GLES\TextureCache.cpp:1228 Texture Max Level 4
52:09:297 user_main I[HLE]: GLES\TextureCache.cpp:1228 Texture Max Level 3
52:09:297 user_main I[HLE]: GLES\TextureCache.cpp:1228 Texture Max Level 4
52:09:298 user_main I[HLE]: GLES\TextureCache.cpp:1228 Texture Max Level 4
52:09:298 user_main I[HLE]: GLES\TextureCache.cpp:1228 Texture Max Level 4

[dbz400]

I did log the GL errors like this but didn't see anything

    GLenum err = glGetError();
    if(err != GL_NO_ERROR)
    {
        INFO_LOG(HLE,"GL ERROR");
    }

[unknownbrackets]

Hmm. Strange. To be clear, I meant the error after this code:

    if (replaceImages) {
        glTexSubImage2D(GL_TEXTURE_2D, level, 0, 0, w, h, components, dstFmt, pixelData);
    } else {
        glTexImage2D(GL_TEXTURE_2D, level, components, w, h, 0, components, dstFmt, pixelData);

It already checks it for out of memory. I'm wondering most specifically if somehow it's getting an error creating the other texture levels.

If it creates all 3/4/5 texture levels, it's really strange...

-[Unknown]

[dbz400]

I just tried something like this however didn't get any GL ERROR

if (replaceImages) {
    glTexSubImage2D(GL_TEXTURE_2D, level, 0, 0, w, h, components, dstFmt, pixelData);
} else {
    glTexImage2D(GL_TEXTURE_2D, level, components, w, h, 0, components, dstFmt, pixelData);
    GLenum err = glGetError();
    if(err != GL_NO_ERROR)
        INFO_LOG(HLE,"GL ERROR");
}

[dbz400]

If i switch back to use auto-gen mipmap which is glGenerateMipmap(GL_TEXTURE_2D) for desktop, all look good .

[dbz400]

I log the maxLevel like this

if (g_Config.bMipMap) {
    INFO_LOG(HLE,"maxLevel=%i",maxLevel);

and the result is

[dbz400]

This one can be closed as well and resolved by #3540

[hdd60311]

Well I found that the car reflection has trouble since 0.9.1-137, 134 build is fine.
137
http://i765.photobucket.com/albums/xx296/hdd60311/1_zpsce0d75c8.jpg
134
http://i765.photobucket.com/albums/xx296/hdd60311/2_zps61dc68d5.jpg

[dbz400]

I checked latest build 408 , it seems to be running fine of the car reflection you mentioned in 134.

[hdd60311]

I tested 408 it still has trouble here, btw I tested with single player mode.
http://i765.photobucket.com/albums/xx296/hdd60311/X_zpsc96294bf.jpg

[dbz400]

What display card you are using ? FYI .I'm using Nvidia card .

[hdd60311]

ATI 5670
I tests repeatedly with 134 and 137, 134 is ok but 137 has trouble, Maybe it has some break between 134 and 137.

Btw has any progress about blackscreen issue with sky when getting into next zone?

[dbz400]

Alright .I think it is bug for ATI card then .Between 134 and 137 , graphical related changes are

1. GLES: Skip GE_LOGIC_COPY for logic ops
2. Use stenciltest for glblendFuncSeparate()

If you revert either of them , which one can fix your issue ?

BTW, the black texture in sky is still unknown .

[hdd60311]

Oh sorry for that could make some builds for testing? I don't know how to revert it...

[unknownbrackets]

I think that was reverted, though?

-[Unknown]

[thedax]

Was it? Hm...guess I'll have to bisect again..

[thedax]

Hm..conflicting results..

git.exe bisect bad

0a44bff is the first bad commit
commit 0a44bff
Author: raven02 <-snipped @raven02's email for anti-spam purposes->
Date: Sat Dec 21 21:27:22 2013 +0800

GLES3: Try to re-enable PSP-based mipmapping generation

:040000 040000 d611648fb38b6484ae534d7d9609332d5902e91d c3cf9d7eb19e2e57cb6f07d44df8e970b2d9c0b2 M Core
:040000 040000 5e79b43b94380dd141dd996dcadcf73061233245 aebd4e542dd8f002b32f3a249018201893f17798 M GPU

In any case, I tested the commit right before this one, and it worked fine, so this should be the 'real' problem, or one of them, if that other one I found broke it too..

Edit: Turning mipmapping OFF seems to 'fix' it, but seeing as mipmapping ON is the default, this is definitely a regression...

[dbz400]

Regarding mipmapping issue , i just played a while until time over and looks okay .Not too sure if it is track specific issue.

[thedax]

Did you have mipmapping on? The track doesn't seem to matter for me.

[dbz400]

Yep , it is with mipmapping on .

Are you playing this track ?

[thedax]

Which track is that?

[dbz400]

This track

[thedax]

Weird. Only looks like that for me if it's off.

[dbz400]

May be you can give me savestate to see how's it looks like on my system with mipmapping on .

[hrydgard]

GPU drivers are not overly consistent with which mipmap pyramids they accept .. but we probably have a minor bug here somewhere. GLES is stricter than GL about falling back to black if something is wrong with the mipmapping setup.

[thedax]

Oh right, I should've mentioned the NVidia driver I'm on: I'm using 334.67. What driver are you using, @raven02?

Here's a savestate made in v0.9.7-11-g3dea6fd: http://www.mediafire.com/download/2xjjxfbn1kf8u6a/ULUS10064_1.03_0.ppst.7z

[dbz400]

My one is 332.21 . I loaded the savestate above and screenshot here

[unknownbrackets]

What are the texture level sizes (GE debugger lists them all next to each other)?

-[Unknown]

[thedax]

For any texture that's black/not rendering properly, you mean? They vary in sizes, but one sample one I'm looking at:

Texture L0 size 64x64
Texture L1 size 32x32
Texture L2 size 32x16
Texture L3 size 32x8
Texture L4 size 32x4
Texture L5 size 32x2
Texture L6 size 1x1
Texture L7 size 1x1

[unknownbrackets]

Yeah, so there it's not using square textures for the other levels. That's not "correct" even if the PSP allows it, your card may not be able to deal with it even if @raven02's can.

Try replacing these lines in LoadTextureLevel():

    int w = gstate.getTextureWidth(level);
    int h = gstate.getTextureHeight(level);

With:

    int w = gstate.getTextureWidth(0) >> level;
    int h = gstate.getTextureHeight(0) >> level;

Which might "force the issue" so to speak. That said, it may be inaccurate.

-[Unknown]

[thedax]

I'd be surprised, he has a GTX 690 (IIRC) and I have a GTX 670, so they're in the same GPU 'family' more or less. Anyway, I'll report back in a minute.

[thedax]

That makes it work, yeah.

[unknownbrackets]

@hrydgard do you think there's any way to detect this? I wonder what it even means when a mipmap level is the same width but half the height... if it works it seems like it still samples from the top left I guess?

-[Unknown]

[thedax]

Would any of the other tabs possibly contain more info you might need?

[hrydgard]

@unknownbrackets I think it's undefined behaviour in GL. Perhaps the mipmap is just skipped and it samples from other mipmaps. Either way, I think we could detect this and just disable mipmapping for the texture, should be the safest option.

[hrydgard]

Can you try again with that change?

[thedax]

That works, thanks. The other issues still remain, of course.

[hrydgard]

This thread is a mess of various issues, resolved and not - could you try to collect the remaining ones and open a new one or two?

[thedax]

Sure. I'll read through this issue and make a new one or two, so feel free to close this.