Split Second Velocity Colour Issue.

[jbakach]

Hi, I've been trying to play this game, but there's a problem, when the first video is loaded it crashes on Android. A few seconds after the first image, it crashes for no reason, I could think is a problem of the video conversion. Who knows, also tried to disable the sound to see if it fixes the problem, but no luck.

[pal1000]

Was always like that, if not try testing older builds to determine which commit broke it, use orphis buildbot if it's hard to use the compiler and a git client. Take a look at wiki on this site to learn how to do git bisecting, orphis buildbot makes this task much easier because you don't need to build older revisions, just download and them using the procedure from the wiki.

[jbakach]

It runs now without any problem, but there are a lot of missing graphics, and also graphic errors. Here are some screenshots to see what I tell you guys, the car has a black square and it makes the playablity really bad. @hrydgard can you take a look at this, I notice a acceptable speed with a Xperia Play.

[0x0ade]

Looks like blending has got problems. Include the fact that you run it on PowerVR and it's all "explained" as they tend to bugs.

[asorcinelli]

I have the "black" rectangle too. My phone is a Galaxy S3.

[jbakach]

@angelde98 you're wrong, the Xperia Play doesn't have PVR, it has Adreno 205 GPU. So there is no relation with what you said. Maybe someone can take a look to this issue, as it may fix more games with problems like this.

[0x0ade]

Oh, wait... Dafuq did I Google then?

Sorry... :/

[aki21]

the black square back of the car happen on all renderer now,before buffered render help but not now,the bug make game unplayable.

[dbz400]

@aki21 , any idea which revision render it okay in buffered -rendering mode?

[dbz400]

Tested on Windows build except black square , other work fine .

[dbz400]

Humm it is AttachFrameBuffer issue. Same bug as Sega Rally.#3852

[jbakach]

The problem is still there with the last build.

[dbz400]

Yes , it is not fixed in master build as I still cannot find a way to make it work without breaking others.

[jbakach]

Maybe @hrydgard can figure out how to fix this issue without breaking others of course. I hope so hehe.Thanks for your attention.

All the best,

jbakach.

[jbakach]

@raven02 how did you fix this issue, can you share it here with us?

Thanks in advance.

[jbakach]

Anyone?

[jbakach]

@hrydgard Hi, can you please take a look at this? I think it may fix tekken 5 life bar.

[hrydgard]

@jbakach why do you think so?

[jbakach]

@hrydgard Because when the graphics were okay, tekken 5 was having status bar working.

[jbakach]

@hrydgard Can you please fix this for 0.9.6? How can I help you?

Thanks in advance.

[dbz400]

It looks like it is the v->format == fmt issue .When we include it here , the black box gone .This also fixes the wrong racing car color in Outrun 2006 #2603 and white box in #4112 . (However this one is gonna break the KH shadow if i remember correctly)

if (MaskedEqual(v->fb_address, fb_address) && v->format == fmt) {

[jbakach]

Is there any planned fix for this game? I love it a lot, and I'd like to play it whenever it's available to be played correctly, I will be really thankfull if you can fix this game. Thanks in advance for your interest.

[ultrooxid]

@hrydgard @raven02 Please fix it . It`s very cool game , but don't work normal on android .

I found it. if (MaskedEqual(v->fb_address, fb_address) && v->format == fmt) {
How can i put it in android version?

[ultrooxid]

@hrydgard @raven02 i see the =fmt) in The files but it does not work even when I click on the plus(((black box not gone in different renderings

[unknownbrackets]

How does this look with the latest framebuffer size estimation and etc. changes?

-[Unknown]

[daniel229]

Still wrong color, and appearing a black box.
the color might need RGB mask implemented

W[G3D]: GLES\StateMapping.cpp:505 Unsupported RGB mask: r=ff g=ff b=0f
W[G3D]: GLES\TextureCache.cpp:280 Render to texture with different formats 2 != 0

[unknownbrackets]

Hmm. Those are pretty different formats. The black box is persistent and unaffected by simulate block transfers? What does the GE debugger say when drawing it?

-[Unknown]

[daniel229]

simulate block transfer does not help.
drawing the black box

copy the black box to the car

[unknownbrackets]

Hmm. Might be a stencil issue, seems like it's trying to alpha blend that.

-[Unknown]

[daniel229]

Demo
https://drive.google.com/file/d/0BzGZGDfFE68zVk1NOFh0M040bEU/edit?usp=sharing

[thedax]

Is the only remaining issue here the black box? If so, I'm going to close this in favour of #7492. @daniel229, can you please see how this game is looking in the latest builds?

[daniel229]

remaining issue,the black box and the colour.

[thedax]

Thanks @daniel229. Renamed the issue to differentiate it from #7492.

[unknownbrackets]

So, the issue with the color here is that the game is drawing to the same framebuffer using different 16-bit color formats. For example, 4444 and 565. This causes wrong colors, because we just take the RGB values of each one, rather than re-interpreting.

To solve this, we could do any of the following:

1. We could create a new framebuffer when the format changes, and re-interpret the rgb (similar to depal) when this happens. This would be devastatingly slow for this game and others, I think.
2. We could choose a "master" format for each framebuffer, and eventually change it (like w/h.) If the render doesn't match the master format, we would do extra work in the fragment shader (I guess?) to re-write the RGBA values to be more appropriate for the conversion being applied.
3. We could try some alternative method for newer GL that involves image buffers or something, which might (?) give better performance than adding lots of work to the frag shader?

Picking the right format for the framebuffer seems tricky. I guess we want the format really to prioritize what it is used as, rather than rendered from, if there are multiple formats...

-[Unknown]

[hrydgard]

The best solution is probably 1 if we make sure not to recreate the buffers every frame but instead keep a second one around for each simulated fb (both really 8888) so we could "ping-pong" at each such conversion, and while it would slow things down, it would probably not be "devastatingly" slow - just like depal isn't. It would of course not be free though and would be quite a bit of work. In modern GL we could probably even do the conversions in-place using a compute shader.

[unknownbrackets]

Well, I know that Kingdom Hearts and some other games zero out framebuffers with the wrong format, and do this for shadows and things multiple times per frame IIRC. So, I do think it could be very slow, especially on not super strong devices.

-[Unknown]

[BogdanTheGeek]

This issue can be fixed by turning on buffered rendering and running in OpenGL (DX 11 is a bit more stuttery).

[unknownbrackets]

Could anyone post a GE dump? I think we know what the issue is, but it'd help debug and verify it.

See here for instructions - it's not hard and works on Android too:
https://github.com/hrydgard/ppsspp/wiki/How-to-create-a-frame-dump

You can zip that and then drag and drop it into a reply here.

-[Unknown]

[benderscruffy01]

i think this is an android problem as it doesnt happen in windows version

[unknownbrackets]

Ah, missed and forgot that there's a demo for this one.

The remaining issue is the color of the numbers:

Dumps like NPUH90093_#4472_hud2.zip are not playing back correctly on a PSP, but the HUD is showing right:

And I'm pretty sure those colors are right (not a side effect of whatever GE dump bug is making the sky not show), referencing this gameplay video from 2010:
https://youtu.be/PX5GTxpphKs?t=175

I think it's a framebuffer reinterpretation problem though.

-[Unknown]

[ghost]

This safe close now? In favor of #13957

[hrydgard]

Yeah, that issue is about the remaining problems with the game, so we don't need this one anymore.