Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
FireChaos opened this issue May 22, 2014 · 47 comments
Closed

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

FireChaos opened this issue May 22, 2014 · 47 comments
Milestone

Comments

@FireChaos
Copy link

untitled
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
Copy link

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

@unknownbrackets
Copy link
Collaborator

@FireChaos
Copy link
Author

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
Copy link

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)"

bug

@LasagnaPie
Copy link

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

sr2

@FireChaos
Copy link
Author

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

@unknownbrackets
Copy link
Collaborator

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
Copy link
Author

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
Copy link

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

sonoctex

@unknownbrackets
Copy link
Collaborator

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
Copy link
Author

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
Copy link
Owner

@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
Copy link
Collaborator

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
Copy link
Owner

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

@FireChaos
Copy link
Author

I took a picture of Step Text and Step Prim.
Step Tex
untitled
Step Prim
untitledprim
Both are on display List.

@FireChaos
Copy link
Author

Well, is there a fix?

@FireChaos
Copy link
Author

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

@hrydgard
Copy link
Owner

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
Copy link
Author

@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
Copy link
Owner

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
Copy link
Author

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
Copy link

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
Copy link
Author

@DonelBueno I have just realized that.

@FireChaos
Copy link
Author

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

@unknownbrackets
Copy link
Collaborator

Does that mean it got faster?

-[Unknown]

@hrydgard
Copy link
Owner

hrydgard commented Jun 3, 2014

Seems unlikely, reopening until confirmation.

@hrydgard hrydgard reopened this Jun 3, 2014
@LasagnaPie
Copy link

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
Copy link

DarkD commented Sep 22, 2014

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
Copy link
Collaborator

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
Copy link
Collaborator

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
Copy link
Owner

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
Copy link
Collaborator

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
Copy link
Owner

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

@unknownbrackets
Copy link
Collaborator

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
Copy link
Contributor

ppmeis commented Jul 26, 2015

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

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

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

@TKC2802
Copy link

TKC2802 commented Sep 26, 2015

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
Copy link
Owner

@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.

@hrydgard hrydgard changed the title Game too bright on Buffering Mode [Sonic Rivals 2] (now too slow) Sonic Rivals 2 too bright in Buffered Mode (now too slow) Jan 26, 2016
@Mann-Nova
Copy link

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
Copy link
Collaborator

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
Copy link

mgemt commented Feb 6, 2019

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:
screenshot_20190206-200651
OpenGL ES:
screenshot_20190206-200725

@hrydgard
Copy link
Owner

hrydgard commented Feb 6, 2019

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
Copy link

Duglor commented Aug 16, 2023

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
Copy link
Owner

Can you show a screenshot of your problem?

@Duglor
Copy link

Duglor commented Aug 17, 2023

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.

Image1
Image2

@placeboyue
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests