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

Ridge Racer 1 and 2 speedometers do not show correctly #8509

Closed
unknownbrackets opened this issue Jan 26, 2016 · 62 comments · Fixed by #16115
Closed

Ridge Racer 1 and 2 speedometers do not show correctly #8509

unknownbrackets opened this issue Jan 26, 2016 · 62 comments · Fixed by #16115
Labels
GE emulation Backend-independent GPU issues
Milestone

Comments

@unknownbrackets
Copy link
Collaborator

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:

        int w = std::min(pixels % vfb->fb_stride, (int)vfb->width);
        int h = std::min((pixels + vfb->fb_stride - 1) / vfb->fb_stride, (int)vfb->height);

Needs to have:

        if (w == 0 || h > 1) {
            // Exactly aligned, or more than one row.
            w = std::min(vfb->fb_stride, (int)vfb->width);
        }

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:

  1. The framebuffer is detected as being 256x272. I'm not sure if parts of it are or are not used for other drawing, so this might be a correct estimate.
  2. For the purposes of the CLUT, only 256x1 is useful.
  3. At some point or another, white gets loaded in the row below the CLUT (and neither it nor the area that ought to be transparent seem to be redrawn regularly.)
  4. At some point, this white ends up blended (partially) into the framebuffer. The effect is better at >2x. I'm not sure why, since I thought we blitted using NEAREST...

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:

  • Render to CLUT bug
  • Line drawing bug
  • 1x PSP resolution bug

-[Unknown]

@unknownbrackets
Copy link
Collaborator Author

Just noting, the linear stuff is from the initial upload of course, and using nearest for BufFilter fixes it. I guess we could make memcpy uploads use nearest by default or using some heuristics....

-[Unknown]

@ghost
Copy link

ghost commented Dec 9, 2017

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

@amurgshere
Copy link

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

@Back2Life888
Copy link

Any kind of workarounds in here??

@hrydgard
Copy link
Owner

hrydgard commented Feb 3, 2021

No, not at this time.

@hrydgard hrydgard added this to the v1.12.0 milestone Feb 3, 2021
@hrydgard hrydgard added the GE emulation Backend-independent GPU issues label Feb 3, 2021
@hrydgard hrydgard modified the milestones: v1.12.0, Future-Prio Aug 29, 2021
@unknownbrackets
Copy link
Collaborator Author

As I recall, more is needed, but #15076 should hopefully at least improve one of the steps here that were broken before.

-[Unknown]

@Back2Life888
Copy link

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?

@unknownbrackets
Copy link
Collaborator Author

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.

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]

@Back2Life888
Copy link

What tool do you use to mess around with the speedometers?

@unknownbrackets
Copy link
Collaborator Author

Software rendering does seem to mostly be getting these right.

-[Unknown]

@Back2Life888
Copy link

Back2Life888 commented Feb 22, 2022

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.

@unknownbrackets
Copy link
Collaborator Author

Well, I did describe how it renders speedometers above. Software rendering is much faster in the latest git builds, though, just to note.

-[Unknown]

@mrwallace888
Copy link

Still an issue, huh?

@Back2Life888
Copy link

Still an issue, huh?

Can't read or back track before posting, huh?

@ghost
Copy link

ghost commented Sep 11, 2022

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.

@unknownbrackets
Copy link
Collaborator Author

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]

@ghost
Copy link

ghost commented Sep 11, 2022

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

@Back2Life888
Copy link

Back2Life888 commented Sep 12, 2022

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.

@ghost
Copy link

ghost commented Sep 16, 2022

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.

image

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.

@hrydgard
Copy link
Owner

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

@stuken
Copy link
Contributor

stuken commented Sep 22, 2022

Looks like it's nearly there.
Auto max quality texture filtering on vulkan is also triggering corruption. Auto and lower appear unaffected.
There is also the grey box appearing on that specific cars speedo at above native res.

@Back2Life888
Copy link

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.

@hrydgard
Copy link
Owner

hrydgard commented Sep 22, 2022

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.

@hrydgard
Copy link
Owner

That should take care of that, at least.

@hrydgard
Copy link
Owner

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

@ghost
Copy link

ghost commented Sep 22, 2022

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

@hrydgard
Copy link
Owner

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.

@hrydgard
Copy link
Owner

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.

@hrydgard
Copy link
Owner

Moved lens flare investigation to #16083 .

@hrydgard
Copy link
Owner

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

@stuken
Copy link
Contributor

stuken commented Sep 23, 2022

Unforunatly there is still the issue with the outline on some speedos while upscaling.
First is x4, second is x1. The same issue occurs on all rendering backends.
UCES00422_00002
UCES00422_00003

@hrydgard
Copy link
Owner

OK, I'll look into that. What car is that?

@Back2Life888
Copy link

Back2Life888 commented Sep 23, 2022

It's the Gnade Esperanza. Also, I'm gonna leave a list of the following cars which have CLUT based speedometers:

  • Danver Bayonet (All models)
  • Gnade Esperanza (All models)
  • Assoluto Fatalita (All models)
  • Kamata Angelus (RR1 Model only)
  • Soldat Crinale (All models)
  • Namco Pac Man (RR2 Model only)

@hrydgard hrydgard reopened this Sep 23, 2022
@Back2Life888
Copy link

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.

@Back2Life888
Copy link

Back2Life888 commented Sep 23, 2022

Hey stuken, do you happen to have 4x upscaling on whilst the rest of the other settings are on low?

@stuken
Copy link
Contributor

stuken commented Sep 23, 2022

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.

@Back2Life888
Copy link

Back2Life888 commented Sep 23, 2022

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.

@hrydgard
Copy link
Owner

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.

@ghost
Copy link

ghost commented Sep 23, 2022

@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
191885679-9004a260-1413-43ad-a06a-86088bdc9294

@hrydgard
Copy link
Owner

hrydgard commented Sep 23, 2022

Thanks, I'll get that fixed soon anyway, gonna rework a bit of how the Vulkan backend synchronizes.

#16090 should take care of it.

@ghost
Copy link

ghost commented Sep 23, 2022

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.

@hrydgard
Copy link
Owner

Oh, they still happen? I really need a sure-fire way to reproduce them.

@hrydgard
Copy link
Owner

hrydgard commented Sep 26, 2022

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.

hrydgard added a commit that referenced this issue Sep 26, 2022
… 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).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
GE emulation Backend-independent GPU issues
Projects
None yet
6 participants