-
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
Ridge Racer 1 and 2 speedometers do not show correctly #8509
Comments
Just noting, the linear stuff is from the initial upload of course, and using nearest for -[Unknown] |
Thanks for looking into this. I Hope you can look at this again when you have free time. Also probably not terribly helpful to you, but here's a video of me playing horribly with the retail UMD on a psp 1000: https://www.youtube.com/watch?v=bJHAb5s1C5Y |
Would be great if we could #8276 and this one fixed so that the Speedos in Ridge Ricer 1 and 2 render properly, +1 for this to be fixed :) Please... |
Any kind of workarounds in here?? |
No, not at this time. |
As I recall, more is needed, but #15076 should hopefully at least improve one of the steps here that were broken before. -[Unknown] |
So you're saying that the speedometers are sort of but not actually working now? |
This part from the above should be fixed now. I think the render-to-clut fix might've been reverted, but I'll try to mess with this again at some point. With the line thing fixed, it should be more easily fixable... -[Unknown] |
What tool do you use to mess around with the speedometers? |
Software rendering does seem to mostly be getting these right. -[Unknown] |
Yes it does although it is extremely slow. You could look into how the game loads in the speedometers in Software rendering and then recreate it with the Software rendering disabled. And not only does the speedometers load in correctly. The headlight effect which only renders in OpenGL on AMD cards loads in properly in Vulkan. |
Well, I did describe how it renders speedometers above. Software rendering is much faster in the latest git builds, though, just to note. -[Unknown] |
Still an issue, huh? |
Can't read or back track before posting, huh? |
The speedometers work now, but Interestingly an error with the software render shows up when enabling clut download for ridge racer. In midtown expressway instead of there being a black triangle explosion at the beginning of the race there's instead missing polygons on the track in a few places. Another thing that happens is the headlight coronas disappear which doesn't happen in software. |
Is the headlight issue only present on hardware renderers, or did you mean to say those were all issues in software? It might belong in a separate issue, although very possible headlights are handled this same way as "lens flares." -[Unknown] |
Sorry about that last post, anyway polygons was with hardware render with clut download enabled. The headlight issue has nothing to do with this and was a mistake on my part |
I'm using Build 2022-09-12 08:35:13 from Buildbot. Issue still persists. However, something is different with the speedometers now. If you save a save state of the game in Software Rendering mode with the cars with the broken speedometers and then reload it again in Hardware rendering, the speedometers kinda bug out in a weird way. |
Go to any level with a sun effect and it'll draw garbage all over the screen. Sunset drive is a perfect example. Looks like it's pointing to the wrong texture when drawing (some kind of memory corruption?). Probably was always there but is showing now because of clut downloads. Edit: Oh now i get it, those tracks with the weird lines on the screen is some kind of effect that's not being drawn correctly in the software GE and now it's showing up in HW. I don't think this is related to the speedometer though. |
#16076 should fix the glitches when texture scaling is enabled. Before this change, I once managed to get a corrupted speedomeeter, with another texture applied, similar to the described glitch, but having a hard time reproducing it reliably... It's got to be some state clearing/dirtying issue, I think. |
Looks like it's nearly there. |
I'm kinda getting confused as to why the headlight glare broke down when the speedometers are fixed. In old builds, the headlight glare works on AMD but is bugged on NVIDIA. In NVIDIA, chances are the headlight glare would only render on 1 headlight and will render at a very short distance or won't even render at all. |
Believe me, I am also confused about the headlights, heh. Need to investigate how they really work. Will fix the problem with auto max quality shortly. |
That should take care of that, at least. |
So I wanted to look into the headlight glare issue, and am playing on hardware, but struggling to find a single place in the game where I can see them. Not in the camera zoom around the car before the race, not in an actual race (you see the car from the back the whole time) and opponents don't have headlight glares if I turn around ... Any tips on where they should be? I do recall seeing them too but don't remember where :P |
Play midtown expressway then let the camera pan around your car at the beginning of the race. It should show the headlight lense flairs, you can see them with the software render that is |
Ah I get it, it's on night courses they show up. And indeed, on the real hardware, pretty big highlights. Hope they're not based on depth buffer readbacks, let's see. |
Since the digital speedometers are OK now, I'm gonna close this, and open a new issue for the headlight glares. Something very strange seems to be going on with them. |
Moved lens flare investigation to #16083 . |
@combo-pizza did you somehow post and delete something here? I got an email notification where you report an error that I'm very surprised you got, and would like to know how to reproduce (the "readyForFence" assertion). |
OK, I'll look into that. What car is that? |
It's the Gnade Esperanza. Also, I'm gonna leave a list of the following cars which have CLUT based speedometers:
|
Hmm weird. It doesn't occur on me. I have Hybrid and Bicubic 5x upscaling, Auto 1:1, Auto Max Quality, 16x Filtering and the Esperanza's speedometer works fine, hell it's even upscaled properly with no bugs and it looks crisper and sharper. |
Hey stuken, do you happen to have 4x upscaling on whilst the rest of the other settings are on low? |
All texture scaling modes dont make a difference. It disappears at auto 1:1 res scaling but appears at any of the x2, x3 and so on modes. |
Well no wonder it doesn't occur on me. Setting it on 2x, it occurs for me now but the gauge of the RR2 Crinale which is CLUT isn't that bad. It just has a box shadow on it like the Assoluto Bisonte (The Bisonte isn't CLUT based but it has a weird box shadow on it) and it doesn't look that major like in the Esperanza. |
Alright, not so serious but of course I'll fix it anyway, looking at something else right now but will get to it relatively soon. |
@hrydgard Sorry about that, I got frustrated because I couldn't reproduce it and just gave up. But here's the image I took from the post before |
Thanks, I'll get that fixed soon anyway, gonna rework a bit of how the Vulkan backend synchronizes. #16090 should take care of it. |
Thank you! I don't know if it's fixed but I at least tried opening it over fifty times with your new build and didn't get any messages like that. |
Oh, they still happen? I really need a sure-fire way to reproduce them. |
Regarding the speedo it's the Galaga Esperanza, not Gnade, took me a while to find it :) Anyway, hm, I'm getting a much fainter effect but I can reproduce the problem. Will check it out. |
… nearest filtering Solves the last problem with the speedometers - so we can finally say: Fixes #8509 Render-to-CLUT for speedometers renders on top of an image that just comes from the underlying memory, so it's been drawn to the framebuffer with DrawPixels. That adds filtering so at higher resolutions, there's some blurring of the CLUT, causing artifacts. We can solve this two ways: either we force on lower-resolution-for-effects for Ridge Racer games, or we use nearest filtering when doing DrawPixels of the memory under a framebuffer. For best result, we do the latter. (The speedometers look even better with nearest filtering, but that's a more general issue of UI looking better that way).
Shortly after drawing with texture 0x09b41fb0, the game renders to the framebuffer 001e4e40. It draws line primitives based on your speed, with matching alpha values for how filled the speedometer should be.
Next, it loads that framebuffer as a CLUT. As of writing, this doesn't work correctly - because of a small bug in the CLUT download:
Needs to have:
Anyway, it's just as well, since that would still draw incorrectly. Anyway, it uses this CLUT now to render the speedometer.
So, what goes wrong? Lines. Lines go wrong. Without #8276, the lines (at ALL resolutions) are drawn incorrectly, and so the framebuffer is not right. It somewhat works to increase the line width, although this is still somewhat wrong.
The reason is, it draw lines e.g. from (0,0)-(5,0). OpenGL centers the line, but the game clearly expects (this is throughmode btw) the line to be drawn downward, and this problem only gets worse the higher the internal resolution is. But it even doesn't work at 1x for this reason.
Anyway, there's an extra problem. Suppose that we fixed all the above - the speedometer would then render perfectly at 1x. But... it would not render correctly at 2x. Why? Because of linear filtering. Here's what happens:
Ultimately, this means there's a white box around the speedometer. Lines aren't the issue here, since it's not even drawing to the part of the palette that is supposed to be transparent and ends up blended with white.
So to summarize:
-[Unknown]
The text was updated successfully, but these errors were encountered: