Sonic Rivals 2 too bright in Buffered Mode (now too slow)

[FireChaos]

This happens when I'm playing this game. it is not normal and it bothers me because I can't see where I'm stepping at. Any help?

[Metafalica]

Maybe somehow related with previous persona 2 brightness fix. try to use revision older than 127

[unknownbrackets]

https://github.com/hrydgard/ppsspp/wiki/How-to-find-a-graphic-issue-with-the-GE-debugger

-[Unknown]

[FireChaos]

I don't get what I should do, there's loads of text in GE Debugger and I can't think I can screenshot it all :(

[LasagnaPie]

This also effect Sonic Rivals 1.. Using the GE Debugger Step Tex.. the issue appears
when this appear.

"SetVertexType: through, u16 texcoords, s16 positions" (Display List)
"Vertex type : float tex coords, float positions (Settings)"

[LasagnaPie]

Same with Sonic Rivals 2 when Vertex type "float texcoords, float positions" change
from "float textcoords, ABGR 8888 colors, float positions"

[FireChaos]

So You were able to fix it, yes?
How did you do that? (I'm abit.. umm... unfamilliar with ppsspp)

[unknownbrackets]

It's blending the screen on top of itself, it looks like. If you look at the texture tab when it's drawing (use step prim when you see the full scene on the left side with step tex), does it show the texture format using a CLUT?

If so, it may be helped by #5767.

-[Unknown]

[FireChaos]

I just wish I was such a programmer-like. I pressed step Prim, then Step Tex and it showed the game in a photo like it has to be. what is next?

[LasagnaPie]

Using step prim
(Display List)
CLUT base addr: b4e860
CLUT addr upper 00080000
c4000020: Clut load: 000020
c500ff23: Clut format: 00ff23 (ABGR 8888)
01b4f080: VADDR: b4f080 => 08b4f080
*DrawPrim type 4: TRIANGLE_STRIP count: 4 vaddr= 08b4f080

[unknownbrackets]

Yeah, it's using CLUT32 with a simpl-ish shift, although it uses two channels which is annoying afaict.

So it's likely that will help it. Either way it seems to be a clut issue.

-[Unknown]

[FireChaos]

I'm using Sonic Rivals 2. I still can't understand... I can't edit anything on Display List. I'm so stupid XD

[hrydgard]

@unknownbrackets , a shift of 8 with a mask of 0xFF will simply access the green channel of a 32-bit texture, how is it using two channels?

[unknownbrackets]

Hmm, I thought it could go up to 512 we were thinking? I forget what the logic was. I mean, it definitely looks like it's after/mainly after green.

Edit: oh nevermind, of course it'd be masked to 0xff anyway. So yeah, then, this should be fine.

-[Unknown]

[hrydgard]

If the palette contains 16-bit entries, I believe it can indeed go up to 512 but not with that mask applied, yes.

[FireChaos]

I took a picture of Step Text and Step Prim.
Step Tex

Step Prim

Both are on display List.

[FireChaos]

Well, is there a fix?

[FireChaos]

I downloaded the latest build and it's no longer too bright! However, it lags so much..

[hrydgard]

Thanks for testing @FireChaos. Alright, so as suspected this was a CLUT/framebuffer problem, and now that we have implemented that, it works. However, I wouldn't expect much slowdown at all from the method we used to implement it, so that's surprising. What GPU are you using and what kind of a framerate drop are you seeing?

[FireChaos]

@hrydgard My GPU is Intel(R) Pentium(R) CPU G620 @ 2.60GHz 2.60 GHz as seen from My Computer>Properties . And what do you mean by framerate drop? How many frames are skipped? I have enabled auto frameskipping and set frameskip to 1 in the settings menu.

[hrydgard]

OK let's start over.

When it was overbright, was it already slow, or did the overbright fix seem to cause it to become slower? If so, about how much? You can enable the FPS counter feature to get an idea.

[FireChaos]

Alright, when it was bright, I put it to 2x PSP and played normally, but when it was loading the levels it was lagging like now. I pressed Esc to open ppsspp menu, hold it for 1 second, closed it and the game was gaining speed and could run just fine, even in 3x PSP, but in 4xPSP it had small lags. 1xPSP was running okay, but it was pixelated. Now, this trick doesn't work. and when I switch from 1xPSP to another or vice versa, like 2x to 3x the screen becomes buggy

[DonelBueno]

I've just tested it here on v0.9.8-659 x64 and v0.9.8-896 x64.

It dropped from 170 fps to 50 fps. The GPU usage rised a lot, but at 50 fps, it is still CPU bound.

System: i7 980x @ 4.22 GHz, GTX 580 Lightning, 12 GB DDR3 @ 1760 MHz CL 7, Windows 7 Ultimate SP1 64 bits.

[FireChaos]

@DonelBueno I have just realized that.

[FireChaos]

None of the latest fixes seem to work. The menu is laggy when loading buttons such as Story Mode or Options.

[unknownbrackets]

Does that mean it got faster?

-[Unknown]

[hrydgard]

Seems unlikely, reopening until confirmation.

[LasagnaPie]

I can confirm the performance issues, the game is sensitive to Rendering Resolution.. if using Auto(1920x1080), it's extremely slow and even makes Windows unstable..

I checked GPU-Z and with IR at 1080p the VRAM Usage is around 1GB
so seems to be a memory issue.

[DarkD]

Guys, as now you can switch DX9/OGL I've found out that it's too bright on DX9, same as on first screenshot.

[unknownbrackets]

That's expected because it doesn't have depal yet. Right now it doesn't work. When it's implemented, it'll definitely have a performance cost, but it remains to be seen how it will compare to GLES.

-[Unknown]

[unknownbrackets]

I don't really know what this game is doing, but it's doing something very, very, very evil.

From some logs and GE debugger info I got:

Step 1. Break the screen into a grid of blocks that are sized 32x34 (so, 15x8 blocks, or 120 total blocks.)
Step 2. Somehow render a scene (I think) to a temporary buffer, at regular 480x272 size.
Step 3. Go through each block in the grid, from top left going down and then right:
Step 3.1. First, depal the temp buffer to get red (CLUT32 shift 0). Draw this to the screen with no blending or tests - so just draw it (apparently, the result is red too.)
Step 3.2. Next, same block, extract the green (shift is 8 now. ) This time, turn on blending (ONE + ONE), but leave everything else off still.
Step 3.3. Don't forget about blue. Can't move on to the next block without shift=16. Still blending as before.
Step 3.4. Copy some portion (using texturing) of our same source temp buffer (this time as 8888) to another temporary buffer. I'm not sure if this is the same block but it's done every other (?) block anyway (the above are all done every single block.)
Step 4. Apply bloom from the result (not sure exactly how it does this.)

So, in other words, rendering a frame in this game currently involves exactly 120 * 3 = 360 separate depal passes. All except the first 3 just regenerate data we already created in previous passes. It also swaps framebuffers at least 60 times during this (to draw to a separate temp buffer), and uses the same depal'd framebuffer as a non-depal texture that many times too.

To recap: this game does something very, very, very evil. I mean, why would you do that? Just to be evil, right? It can't be necessary. No part of that horror is necessary.

-[Unknown]

[hrydgard]

They clearly want to use depal to apply some gamma curve or similar separately on R, G and B, for what purpose I do not know, to make the bloom look better or something. It's also known that there is some kind of performance issue with PSP VRAM that usually makes it beneficial to do things that fill a lot of pixels in 32 or 64-pixel wide stripes (this can be seen in the strange multi-rect clears that games do). But I don't get why it would split vertically, and why it wouldn't just do these things as multi-rect draws.. and all that render target swapping...

[unknownbrackets]

Right. I get that it's doing different adjustments for R, G, and B, but it could do a bunch of rects all at once (it's actually using triangle strips) to get the job done from the same texture with the same clut. I'm pretty sure this would perform better than what they're doing now even on a real PSP...

I guess our best option would be caching X recent depal FBOs per framebuffer? But that could really drink up VRAM...

That or maybe depal'ing only the 32x34 chunk it's going to use...

-[Unknown]

[hrydgard]

Or just throw up our hands and optimize the software rasterizer :) Yeah, I dunno ...

[unknownbrackets]

Another idea is just bypassing the blit entirely for certain depals.

For example, we could dedicate 2-3 bits of the frag shader id to a "depal profile id", or simply a "clean" swizzle. If the value != 0, we would do the depal directly in the normal rendering fragment shader.

If we ran out of profile id space, we'd continue depaling the current way, and we might do it the current way still for certain complex depals. But since this game is only using a certain full channel (r, g, and b), it should be relatively simple to do this way.

And this would mean a lot less copying. Though, I'm not sure what the speed impact would be to games that use depal more naturally...

-[Unknown]

[ppmeis]

Tested with latest build. Everything is too slow but with good color using 10x IR:

Using 4x IR game runs at good speed and colors:

But if I enable "Disable slower effects", speed is normal but bright is too high:

[TKC2802]

How do I fix this on Android? I tried to play sonic rivals 2, but when I start the race, the whole thing just lags badly and the screen turns very bright. This is in buffered rendering mode. When I changed to non-buffered rendering mode, the whole thing ran smoothly. However, the screen turned totally black instead. I am using redmi 1s.

[hrydgard]

@TKC2802 you don't, there's currently no way to run this game properly with good performance. It's doing things that are completely insane on modern mobile GPUs but happened to run fast enough on the PSP's.

[Mann-Nova]

So has anyone figured out how to make this game run smoothly at any resolution higher than 1x? Like previously mentioned, Disabling Slower Effects causes the game to have some weird bloomed up brightness that makes it rather unenjoyable to play, but I can't think of another way to run it (and Rivals 1, for that matter) at a high resolution smoothly. Really unfortunate for someone who needs to capture game footage in HD and can't.

[unknownbrackets]

Possibly now still too bright in Vulkan. Might help if someone gave comparison screenshots in each backend.

Vulkan may run this game smoother now.

-[Unknown]

[mgemt]

I Confirm on the latest android build colors has been fixed, the games (Sonic Rivals 1) run perfect 30 fps with Vulkan backend on Android v1.7.5-414 but Struggle with the OpenGL ES Backend
Device: Snapdragon 636
Vulkan:

OpenGL ES:

[hrydgard]

Yeah, Vulkan runs this game great now after I added the hack that rearranges the frame rendering operations for performance on modern GPUs. Unfortunately haven't implemented this yet for OpenGL, but it works at least, the only remaining issue is that perf could be improved so I'm closing this.

[Duglor]

So i have this brightness problems on sonic 1 and sonic 2 on lr-ppsspp for retropie. What must i change any retroarch settings to in order to fix this issue?

[hrydgard]

Can you show a screenshot of your problem?

[Duglor]

Having problems with my pc currently...so in the meantime, it's basically this exactly. I mean it looks exactly like these to the T. But on the latest ppsspp Retropie build.

[placeboyue]

This happened to me on an actual PSP. Surprised to barely see any people talking about the issue