Cars - Race-O-Rama (USA) graphics problem #4112

scraggles80 · 2013-10-11T08:43:56Z

no matter what rendering mode i change it to nothing fixes it

dbz400 · 2013-10-12T02:09:49Z

Humm it did render partially correct for a time being.

dbz400 · 2013-10-12T02:26:27Z

Humm it somehow depth related

    // Depth Test
    if (gstate.isDepthTestEnabled()) {
        glstate.depthTest.enable();
        glstate.depthFunc.set(ztests[gstate.getDepthTestFunction()]);
        glstate.depthWrite.set(gstate.isDepthWriteEnabled() || alwaysDepthWrite ? GL_TRUE : GL_FALSE);
    } else {
        //glstate.depthTest.disable();
    }

If i comment out the above "glstate.depthTest.disable()" , it show more correctly

dbz400 · 2013-12-07T08:13:00Z

The car itself looks better now as well as the background though still something cover up half screen,

unknownbrackets · 2014-01-05T04:26:10Z

If you step through in the GE debugger, does it draw the white at one point? Does the vertex preview show just the left side or more of the screen (if more of the screen, would indicate a test is likely..)?

-[Unknown]

dbz400 · 2014-01-05T04:30:52Z

Yes, the white looks like draw progressively from left to right

unknownbrackets · 2014-01-05T05:01:20Z

Okay, so from where I'm sitting, something is wrong with the texture at 0x042cc000. Does it ever render to a framebuffer at that address (even at the beginning of the track or etc.)?

-[Unknown]

dbz400 · 2014-01-05T05:16:20Z

Humm this is the log (or something related to 000cc000 depth buffer?)

15:01:473 main_thread I[G3D]: GLES\ShaderManager.cpp:146 Linked shader: vs 16 fs 65
15:01:473 main_thread W[G3D]: GLES\TextureCache.cpp:213 Render to texture with different formats 0 != 3
15:01:477 main_thread I[SCEGE]: GLES\Framebuffer.cpp:785 Creating FBO for 00000200 : 480 x 272 x 0
15:01:477 main_thread W[SCEGE]: GLES\Framebuffer.cpp:805 FBO reusing depthbuffer, 00000200/000cc000 and 00088000/000cc000
15:01:481 main_thread I[SCEGE]: GLES\Framebuffer.cpp:785 Creating FBO for 00000400 : 480 x 272 x 0
15:01:481 main_thread W[SCEGE]: GLES\Framebuffer.cpp:805 FBO reusing depthbuffer, 00000400/000cc000 and 00088000/000cc000
15:01:487 main_thread I[SCEGE]: GLES\Framebuffer.cpp:785 Creating FBO for 00000600 : 480 x 272 x 0
15:01:487 main_thread W[SCEGE]: GLES\Framebuffer.cpp:805 FBO reusing depthbuffer, 00000600/000cc000 and 00088000/000cc000

15:01:514 main_thread I[SCEGE]: GLES\Framebuffer.cpp:785 Creating FBO for 0015e000 : 128 x 128 x 2
15:01:514 main_thread W[SCEGE]: GLES\Framebuffer.cpp:805 FBO reusing depthbuffer, 0015e000/000cc000 and 00088000/000cc000
15:01:515 main_thread I[SCEGE]: GLES\Framebuffer.cpp:785 Creating FBO for 00112000 : 64 x 64 x 2
15:01:515 main_thread W[SCEGE]: GLES\Framebuffer.cpp:805 FBO reusing depthbuffer, 00112000/000cc000 and 00088000/000cc000

dbz400 · 2014-01-05T05:19:25Z

Not too sure if it is related to depth .If i do this

    // Depth Test
    if (gstate.isDepthTestEnabled()) {
        glstate.depthTest.enable();
        glstate.depthFunc.set(ztests[gstate.getDepthTestFunction()]);
        glstate.depthWrite.set(gstate.isDepthWriteEnabled() || alwaysDepthWrite ? GL_TRUE : GL_FALSE);
    } else {
        //glstate.depthTest.disable();
    }

unknownbrackets · 2014-01-05T05:34:31Z

Well, it would be 002cc000. 000cc000 is pretty far away. None of those are nearby, but maybe the game is doing a block transfer or something.

-[Unknown]

dbz400 · 2014-01-05T05:41:20Z

Probably yes

40:53:739 main_thread I[G3D]: GLES\GLES_GPU.cpp:1534 Block transfer: 0bb41be0/20 -> 041fcf00/20, 32x4x4 (0,0)->(0,0)
40:53:739 main_thread I[G3D]: GLES\GLES_GPU.cpp:1534 Block transfer: 0bb41de0/20 -> 041fd100/20, 32x1x4 (0,0)->(0,0)
40:53:739 main_thread I[G3D]: GLES\GLES_GPU.cpp:1534 Block transfer: 0bb41e60/20 -> 041fd180/20, 32x1x4 (0,0)->(0,0)
40:53:740 main_thread I[G3D]: GLES\GLES_GPU.cpp:1534 Block transfer: 0bb515e0/20 -> 0411db00/20, 32x4x4 (0,0)->(0,0)
40:53:740 main_thread I[G3D]: GLES\GLES_GPU.cpp:1534 Block transfer: 0bb517e0/20 -> 0411dd00/20, 32x2x4 (0,0)->(0,0)
40:53:740 main_thread I[G3D]: GLES\GLES_GPU.cpp:1534 Block transfer: 0bb518e0/20 -> 0411de00/20, 32x1x4 (0,0)->(0,0)
40:53:740 main_thread I[G3D]: GLES\GLES_GPU.cpp:1534 Block transfer: 0bb51960/20 -> 0411de80/20, 32x1x4 (0,0)->(0,0)
40:53:740 main_thread I[G3D]: GLES\GLES_GPU.cpp:1534 Block transfer: 0bb51a20/20 -> 0418b300/20, 32x4x4 (0,0)->(0,0)
40:53:740 main_thread I[G3D]: GLES\GLES_GPU.cpp:1534 Block transfer: 0bb51c20/20 -> 0418b500/20, 32x2x4 (0,0)->(0,0)
40:53:740 main_thread I[G3D]: GLES\GLES_GPU.cpp:1534 Block transfer: 0bb51d20/20 -> 0418b600/20, 32x1x4 (0,0)->(0,0)
40:53:740 main_thread I[G3D]: GLES\GLES_GPU.cpp:1534 Block transfer: 0bb51da0/20 -> 0418b680/20, 32x1x4 (0,0)->(0,0)

hrydgard · 2014-01-05T10:17:52Z

Those small block transfers are probably unrelated, can you try logging only big ones (maybe where height > 64 or something)?

dbz400 · 2014-01-05T11:43:14Z

Here it is height > 64

42:48:007 main_thread I[G3D]: GLES\GLES_GPU.cpp:1535 Block transfer: 0bb52b60/40 -> 04170c00/40, 64x128x4 (0,0)->(0,0)
42:48:007 main_thread I[G3D]: GLES\GLES_GPU.cpp:1535 Block transfer: 0ba63860/20 -> 04140000/20, 32x128x4 (0,0)->(0,0)
42:48:008 main_thread I[G3D]: GLES\GLES_GPU.cpp:1535 Block transfer: 0bab00e0/20 -> 04183b00/20, 32x128x4 (0,0)->(0,0)
42:48:008 main_thread I[G3D]: GLES\GLES_GPU.cpp:1535 Block transfer: 0bae0760/20 -> 04194c00/20, 32x128x4 (0,0)->(0,0)
42:48:008 main_thread I[G3D]: GLES\GLES_GPU.cpp:1535 Block transfer: 0bb42260/20 -> 0419a200/20, 32x128x4 (0,0)->(0,0)
42:48:008 main_thread I[G3D]: GLES\GLES_GPU.cpp:1535 Block transfer: 0bb02160/40 -> 041b4680/40, 64x256x4 (0,0)->(0,0)
42:48:008 main_thread I[G3D]: GLES\GLES_GPU.cpp:1535 Block transfer: 0bb12160/20 -> 041c4680/20, 32x128x4 (0,0)->(0,0)
42:48:009 main_thread I[G3D]: GLES\GLES_GPU.cpp:1535 Block transfer: 0bb484e0/20 -> 041cc880/20, 32x128x4 (0,0)->(0,0)
42:48:059 main_thread I[G3D]: GLES\GLES_GPU.cpp:1535 Block transfer: 040883c0/100 -> 0b4ae080/80, 16x128x4 (0,0)->(0,0)
42:48:059 main_thread I[G3D]: GLES\GLES_GPU.cpp:1535 Block transfer: 040883c0/100 -> 0b4ae080/80, 16x128x4 (0,0)->(16,0)
42:48:059 main_thread I[G3D]: GLES\GLES_GPU.cpp:1535 Block transfer: 040883c0/100 -> 0b4ae080/80, 16x128x4 (0,0)->(32,0)
42:48:059 main_thread I[G3D]: GLES\GLES_GPU.cpp:1535 Block transfer: 040883c0/100 -> 0b4ae080/80, 16x128x4 (0,0)->(48,0)
42:48:059 main_thread I[G3D]: GLES\GLES_GPU.cpp:1535 Block transfer: 040883c0/100 -> 0b4ae080/80, 16x128x4 (0,0)->(64,0)
42:48:059 main_thread I[G3D]: GLES\GLES_GPU.cpp:1535 Block transfer: 040883c0/100 -> 0b4ae080/80, 16x128x4 (0,0)->(80,0)
42:48:059 main_thread I[G3D]: GLES\GLES_GPU.cpp:1535 Block transfer: 040883c0/100 -> 0b4ae080/80, 16x128x4 (0,0)->(96,0)
42:48:059 main_thread I[G3D]: GLES\GLES_GPU.cpp:1535 Block transfer: 040883c0/100 -> 0b4ae080/80, 16x128x4 (0,0)->(112,0)
42:48:066 main_thread I[G3D]: GLES\GLES_GPU.cpp:1535 Block transfer: 0bb52b60/40 -> 04170c00/40, 64x128x4 (0,0)->(0,0)
42:48:066 main_thread I[G3D]: GLES\GLES_GPU.cpp:1535 Block transfer: 0ba63860/20 -> 04140000/20, 32x128x4 (0,0)->(0,0)
42:48:066 main_thread I[G3D]: GLES\GLES_GPU.cpp:1535 Block transfer: 0bab00e0/20 -> 04183b00/20, 32x128x4 (0,0)->(0,0)
42:48:066 main_thread I[G3D]: GLES\GLES_GPU.cpp:1535 Block transfer: 0bae0760/20 -> 04194c00/20, 32x128x4 (0,0)->(0,0)
42:48:067 main_thread I[G3D]: GLES\GLES_GPU.cpp:1535 Block transfer: 0bb42260/20 -> 0419a200/20, 32x128x4 (0,0)->(0,0)
42:48:067 main_thread I[G3D]: GLES\GLES_GPU.cpp:1535 Block transfer: 0bb02160/40 -> 041b4680/40, 64x256x4 (0,0)->(0,0)
42:48:067 main_thread I[G3D]: GLES\GLES_GPU.cpp:1535 Block transfer: 0bb12160/20 -> 041c4680/20, 32x128x4 (0,0)->(0,0)
42:48:067 main_thread I[G3D]: GLES\GLES_GPU.cpp:1535 Block transfer: 0bb484e0/20 -> 041cc880/20, 32x128x4 (0,0)->(0,0)

hrydgard · 2014-01-05T12:09:54Z

Looks like all of them are copying to VRAM above the framebuffers so all of those are probably just regular texture updates (the game uploads new textures to VRAM). This means that that kind of block transfer is probably not the issue. The game might be doing tricks with sceDmacMemcpy or its own manual cpu memcpy though, or something... hard to say.

dbz400 · 2014-01-05T13:27:59Z

I see.Probably it is depth issue .

dbz400 · 2014-01-11T08:54:48Z

This is the screenshot where v->format == fmt

unknownbrackets · 2014-02-16T09:54:36Z

Have the recent depth changes affected this?

-[Unknown]

dbz400 · 2014-02-16T13:39:55Z

Same issue here.

dbz400 · 2014-03-28T16:13:43Z

Looks like the above issue is somehow affected by u_stencilReplaceValue . STENCIL_VALUE_UNIFORM basically return from GE_FORMAT_8888 or 4444 .Should they have different for u_stencilReplaceValue ?

    case STENCIL_VALUE_UNIFORM:
        WRITE(p, "  %s.a = u_stencilReplaceValue;\n", fragColor0);

dbz400 · 2014-03-28T16:18:04Z

If i tried to divide it by a factor

WRITE(p, " %s.a = u_stencilReplaceValue / 4.0;\n", fragColor0);

The car and background looks better

The shadow also looks more correct in FF Type-0

unknownbrackets · 2014-06-07T06:56:12Z

Has this changed at all with the latest framebuffer size estimation changes, and with "simulate block transfers" enabled?

-[Unknown]

ppmeis · 2014-07-14T13:40:30Z

Tested with latest build. Same issues:

ppmeis · 2015-07-25T21:46:01Z

Tested with latest build. Even worse than before:

unknownbrackets · 2015-07-25T23:19:42Z

Interesting. It might help to find where it got worse.

-[Unknown]

daniel229 · 2015-07-31T11:00:24Z

That affected by #7509

unknownbrackets · 2015-08-02T17:24:04Z

Interesting. What does the source texture and settings look like when it draws the white?

Maybe it is now an alpha/stencil/blending issue.

-[Unknown]

daniel229 · 2015-08-02T23:27:13Z

These are when it drew the white.

unknownbrackets · 2018-11-26T02:33:48Z

Thanks. I think the other bugs fixed got us to the point where it's just the depth texturing left, and #9850 indeed represents that issue more clearly.

-[Unknown]

dbz400 mentioned this issue Jan 11, 2014

Split Second Velocity Colour Issue. #4472

Closed

dbz400 mentioned this issue Mar 18, 2014

Alternative framebuffer approach #5679

Closed

unknownbrackets added the No Feedback label Jul 10, 2014

unknownbrackets removed the No Feedback label Jul 14, 2014

thedax mentioned this issue Jul 31, 2014

Remaining issues with depth testing precision/clamping #6660

Closed

daniel229 mentioned this issue Mar 15, 2015

tales of destiny 2 grahpics problem and speed problem #7587

Closed

unknownbrackets closed this as completed Nov 26, 2018

hrydgard added the GE emulation Backend-independent GPU issues label Dec 12, 2022

hrydgard added this to the v1.14.0 milestone Dec 12, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Cars - Race-O-Rama (USA) graphics problem #4112

Cars - Race-O-Rama (USA) graphics problem #4112

scraggles80 commented Oct 11, 2013

dbz400 commented Oct 12, 2013

dbz400 commented Oct 12, 2013

dbz400 commented Dec 7, 2013

unknownbrackets commented Jan 5, 2014

dbz400 commented Jan 5, 2014

unknownbrackets commented Jan 5, 2014

dbz400 commented Jan 5, 2014

dbz400 commented Jan 5, 2014

unknownbrackets commented Jan 5, 2014

dbz400 commented Jan 5, 2014

hrydgard commented Jan 5, 2014

dbz400 commented Jan 5, 2014

hrydgard commented Jan 5, 2014

dbz400 commented Jan 5, 2014

dbz400 commented Jan 11, 2014

unknownbrackets commented Feb 16, 2014

dbz400 commented Feb 16, 2014

dbz400 commented Mar 28, 2014

dbz400 commented Mar 28, 2014

unknownbrackets commented Jun 7, 2014

ppmeis commented Jul 14, 2014

ppmeis commented Jul 25, 2015

unknownbrackets commented Jul 25, 2015

daniel229 commented Jul 31, 2015

unknownbrackets commented Aug 2, 2015

daniel229 commented Aug 2, 2015

unknownbrackets commented Nov 26, 2018

Cars - Race-O-Rama (USA) graphics problem #4112

Cars - Race-O-Rama (USA) graphics problem #4112

Comments

scraggles80 commented Oct 11, 2013

dbz400 commented Oct 12, 2013

dbz400 commented Oct 12, 2013

dbz400 commented Dec 7, 2013

unknownbrackets commented Jan 5, 2014

dbz400 commented Jan 5, 2014

unknownbrackets commented Jan 5, 2014

dbz400 commented Jan 5, 2014

dbz400 commented Jan 5, 2014

unknownbrackets commented Jan 5, 2014

dbz400 commented Jan 5, 2014

hrydgard commented Jan 5, 2014

dbz400 commented Jan 5, 2014

hrydgard commented Jan 5, 2014

dbz400 commented Jan 5, 2014

dbz400 commented Jan 11, 2014

unknownbrackets commented Feb 16, 2014

dbz400 commented Feb 16, 2014

dbz400 commented Mar 28, 2014

dbz400 commented Mar 28, 2014

unknownbrackets commented Jun 7, 2014

ppmeis commented Jul 14, 2014

ppmeis commented Jul 25, 2015

unknownbrackets commented Jul 25, 2015

daniel229 commented Jul 31, 2015

unknownbrackets commented Aug 2, 2015

daniel229 commented Aug 2, 2015

unknownbrackets commented Nov 26, 2018