-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
Comments
Maybe somehow related with previous persona 2 brightness fix. try to use revision older than 127 |
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 :( |
So You were able to fix it, yes? |
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] |
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? |
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] |
I'm using Sonic Rivals 2. I still can't understand... I can't edit anything on Display List. I'm so stupid XD |
@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? |
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] |
If the palette contains 16-bit entries, I believe it can indeed go up to 512 but not with that mask applied, yes. |
Well, is there a fix? |
I downloaded the latest build and it's no longer too bright! However, it lags so much.. |
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? |
@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. |
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. |
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 |
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. |
@DonelBueno I have just realized that. |
None of the latest fixes seem to work. The menu is laggy when loading buttons such as Story Mode or Options. |
Does that mean it got faster? -[Unknown] |
Seems unlikely, reopening until confirmation. |
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 |
Guys, as now you can switch DX9/OGL I've found out that it's too bright on DX9, same as on first screenshot. |
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] |
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.) 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] |
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... |
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] |
Or just throw up our hands and optimize the software rasterizer :) Yeah, I dunno ... |
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] |
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. |
@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. |
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. |
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] |
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. |
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? |
Can you show a screenshot of your problem? |
This happened to me on an actual PSP. Surprised to barely see any people talking about the issue |
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?
The text was updated successfully, but these errors were encountered: