Opening animation in Brave Story has major artifacts

[prxy]

there are no opening video of brave story new traveler it just show white screen and then the only video that appear is just a bunch of dragon flying...in my psp it shows a video of the introduction of all character in the games before that flying dragon appear...and in the game beginning where it should be a big door video and some text it only shows a white screen but the text appear

[unknownbrackets]

AFAIK (could be wrong) this is actually a "cutscene" more than a video, i.e. it's rendered realtime.

If I dump the frame while the white screen is being displayed, a bunch of stuff is dumped. So I'm pretty sure it's just rendering incorrectly.

-[Unknown]

[unknownbrackets]

Works in software renderer, and does a lot of render-to-texture, so most likely an issue with that.

-[Unknown]

[unknownbrackets]

I think I fixed it (same commits that fixed Mana Khemia), but it's still pretty ugly/glitchy.

-[Unknown]

[solarmystic]

@unknownbrackets

I can confirm that observation. It appears somewhat normally on my system in the latest builds. Referring to the realtime rendered introduction with the big door and the character introductions.

[unknownbrackets]

Yeah, but similar to 3rd Birthday, it's got all sorts of noise overlaid on top.

-[Unknown]

[unknownbrackets]

If I make the "Render to area containing texture at %08x" case invalid, the glitches go away.

The texture is at 0x0413b000, and the framebuffer is at 0013a000 (both are RGBA.) The stride is 128.

Actually, the game specifies 0x0413b000 for the framebuffer, but we ignore those bits. Maybe that's been involved in the suboffsets all along (will need to retest SAO.)...

@hrydgard any idea if the & 0xFFE000 is correct? I noticed JPCSP does not do it. I also noted they do this: http://code.google.com/p/jpcsp/source/detail?r=2928

Anyway, changing that does not fix the noise.

Killing the & 0xFFE000 in the softgpu definitely improves some graphics in the intro.

-[Unknown]

[dbz400]

@unknownbrackets , just wonder the glitches you mentioned is it the top right corner one below?

[dbz400]

or you mean this big square shadow ?

[solarmystic]

@raven02

I see them both. The triangular glitch is very obvious, especially in brighter areas in the game.

The big square shadows during battle switch back to normal ones at times, depending on the scene.

Also, playing the game in just 1x rendering resolution makes it look absolutely horribly. 2x and 3x clears up quite a number of the artifacts.

[dbz400]

Yep , the big square shadows are bit funny , it only renders wrong in that scene when all those characters come close .When they seperate , shadow renders correct .

[unknownbrackets]

Hmm. So, here's something strange.

If I open the GE debugger during the video, click "Step Tex", and hold enter, after a dozen or so frames it will start to look fine. Step Frame doesn't do the trick. I wondered why and reproduced that this line was "the one":

glGetTexImage(GL_TEXTURE_2D, 0, GL_RGBA, GL_UNSIGNED_BYTE, buffer.GetData());

If that is executed, everything looks good (of course, it's pretty slow.) If it's not, it looks bad. Even if I remove the SetTexture call. I'm not sure why. Does that have side effects?

0x0413b000 seems to just be one of the stages in its bloom effect. Maybe it's a blending or stencil issue...

-[Unknown]

[dbz400]

Looks like the right hand corner graphical issue as well as in-game one are somehow related to the flip texture and i can see it also affect other games like RR2.

gstate_c.flipTexture = true;

I think we assume flip texture is set to always true for render-to-texture

[unknownbrackets]

It should always be true when a texture is set from a render-to-texture. Is it not?

-[Unknown]

[dbz400]

I'm not sure if it is the case that for any render-to-texture , it should be always flipped .

[hrydgard]

It should be set whenever we texture from an FBO, as OpenGL's coordinate systems for framebuffers is a bit backwards.

[dbz400]

I see. Then the graphical issue may be due to other things then

[dbz400]

One workaround now is setting 10x rendering resolution to counteract the artifact

-Auto

-10x

[dbz400]

I'm wondering is it the render-to-texture resolution not scale up to the internal resolution ? One example

-Auto (Text is very blurred)

-10x (Text is much clear)

[unknownbrackets]

@hrydgard I figured this out. It's rendering to an address it's texturing from. The render-to-texture code triggers and it assigns the framebuffer as a texture to itself. This causes the glitches. I think it happens in a few other games.

I wonder what the best solution is?

Actually, it seems like 3rd Birthday does this too.

-[Unknown]

[hrydgard]

Hm. That would cause glitches, yes, surprised it doesn't on the PSP hardware. We could copy the framebuffer into a regular texture, then texture from that when rendering to the framebuffer.

Either way we should definitely add report logging for this situation.

[unknownbrackets]

It seems to happen in quite a few games, actually:
http://report.ppsspp.org/logs/kind/428 (61 so far)

-[Unknown]

[dbz400]

Not too sure if we need to reopen it . I just tested it out on my Aderno device , seems to be the introductory cut-scene is in all in white color when using all rendering modes except software rendering .

• Softgpu
  
• All rendering modes ( non-rendering , rendering and framebuffer read mode)
  

[solarmystic]

Seems like it's only an issue on mobile devices, the cutscene still displays properly on my PC using Buffered Rendering on the latest revision:-

[dbz400]

Yep PC is fine so it is interesting .I'm wondering if this scene requires some extensions to work that not available on mobile.

[dbz400]

Probably this one should be re-open .At least Android has issue rendering this cutscene.

[unknownbrackets]

I think we changed this so it works on Android. Is it still a problem?

-[Unknown]

[unknownbrackets]

Well, I thought it was working but now I'm only getting white screens. So either it never did actually or it was broken recently...

On Android GLES2.

-[Unknown]

[unknownbrackets]

Turns out it doesn't work on GLES2 due to logic ops (which affects Direct3D 9 as well.)

It's possible to emulate the logic op either using blending or in the shader . Should probably test the interaction between logic ops and blending... my guess it is applies after blending but dunno...

-[Unknown]