Interpolation - Intermediate Proposal

[anikom15]

I have a question about the current VDLP emulation. Are the interpolation corner weight bits recovered for each pixel in the framebuffer? If so, I have an idea for how the core could transmit the corner weight information so the interpolation can be done with post-processing. While this is not intended to be an accurate solution, the idea is that this could at least be used to demonstrate and prototype the effect.

The requirements for this is that the core output 320x240 mode. It should work with either the CLUT enabled or disabled. The two bits for the corner weight will be stored in the lowest bit of the red and blue channels. The first bit can be set, for example, as R = 0 is top, R = 1 is bottom, B = 0 is right, B = 1 is left. This will impact color representation slightly, but it should be very minimal. My second question is if this operation is possible to implement easily in the core.

A shader can then recover the bit values when sampling the input texture. Even though the shader operates in floating-point, there is enough precision to determine the bit value precisely. Once the corner weight values are known, it's easy for me to write a shader to implement the interpolation. I was not able to determine how the weighting is precisely calculated. If unknown I will use a distance-based weighting.

Any thoughts on this would be welcome.

[hizzlekizzle]

Why not pack it into the alpha channel? That would give you more room/precision and avoid affecting the colors at all.

[anikom15]

If that’s possible, that would be preferred.

ETA: It would be best to use the upper two significant bits instead of the least bits in this case.

[trapexit]

There is no attempt in the code to support the cornerweight upscaling currently.

I'm not sure I understand the reason for doing it as a shader (besides performance). Opera is intentionally low level and my immediate preference would that the crispy or corner weighted upscaling be done in the VDLP.

If I was trying to turn it into a shader I'd probably limit the scope to both horizontal and vertical being enabled and do the whole image. I'm not sure any game tried to do more than that. It's been on my todo list to add some debugging code to see what games are trying to do with regard to interpolation to see if it even makes sense to implement fully.

https://3dodev.com/documentation/development/opera/pf25/ppgfldr/ggsfldr/gpgfldr/3gpgg

[anikom15]

It would be for demonstration and prototyping. I’m not capable of implementing it in the Opera code itself, but I can write shaders well enough.

You can find my code here:
https://github.com/anikom15/scanline-classic/blob/master/shaders/3do-interpolation.slang

Since there isn’t any cornerweight data available, I simulate that data for demonstration purposes with a completely arbitrary algorithm. I also had to make up my own weighting method based on Euclidian distance because the weighting is not documented.

Any feedback on what the shader is doing wrong will be very valuable.

[trapexit]

with a completely arbitrary algorithm

Have you looked at the patent and dev docs for the algo? There are multiple ways to select the cornerweight and if you're just trying to create a "3DO interpolation" filter you could use a number of related ways to do it. Fixed cornerweight selections and some form of dynamic based on input pixels.

[anikom15]

with a completely arbitrary algorithm

Have you looked at the patent and dev docs for the algo? There are multiple ways to select the cornerweight and if you're just trying to create a "3DO interpolation" filter you could use a number of related ways to do it. Fixed cornerweight selections and some form of dynamic based on input pixels.

That’s out of the scope of the shader. The VDLP embeds the cornerweight data in the 16th bit and the LSB of the blue channel. Since that’s not preserved by the time the color data is passed to the shader, the shader sees all cornerweight data at the same location (that specific location is not important, only relative location between pixels).

The simulate cornerweights setting is to allow a demonstration with simulated cornerweight placement. This is not meant to replace the core’s operation. The request here is specifically to embed the cornerweight data into the color output channels so they can be recovered by the shader and the simulated data is not needed.

The interpolation code in the shader is implemented exactly as I could find it in the dev docs and patent. Since they don’t specify the weighting function, I have chosen to use a Euclidian distance weighting function. If the exact function is determined I can easily change it to use that.

In short, the shader’s purpose is only to do the interpolation, not to determine cornerweights.

[trapexit]

The request here is specifically to embed the cornerweight data into the color output channels so they can be recovered by the shader and the simulated data is not needed.

Yes, I understand that. But why? Why wouldn't the VDLP code then just do the interpolation then? Why pass off the responsibility to a shader rather than just embedding it into the VDLP code directly like everything else?

In the very least there should be a reference implementation that exists in the standard VDLP emulation as it's the VDLP emulation that is also responsible for CLUT, PLUT, and other conversions.

The interpolation code in the shader is implemented exactly as I could find it in the dev docs and patent. Since they don’t specify the weighting function, I have chosen to use a Euclidian distance weighting function. If the exact function is determined I can easily change it to use that.

Isn't it inverse distance squared? Page 25 and 105 of the patent?

[anikom15]

Yes, I understand that. But why? Why wouldn't the VDLP code then just do the interpolation then? Why pass off the responsibility to a shader rather than just embedding it into the VDLP code directly like everything else?

Simply because I don’t know how to implement it in the Opera code. I’m not familiar with the codebase. The shader is ready now.

Isn't it inverse distance squared? Page 25 and 105 of the patent?

It just refers to it as distance weighted but doesn’t specify beyond that. What you are referring to is Euclidian distance weighting and I have implemented that.

[trapexit]

Simply because I don’t know how to implement it in the Opera code. I’m not familiar with the codebase. The shader is ready now.

OK... but you're effectively asking me to do the work for you then and if I'm going to replumb the entire render pipeline to support VH values I may as well add the interpolation step. And as I said I'm not even positive games leveraged the feature.

[anikom15]

Simply because I don’t know how to implement it in the Opera code. I’m not familiar with the codebase. The shader is ready now.

OK... but you're effectively asking me to do the work for you then and if I'm going to replumb the entire render pipeline to support VH values I may as well add the interpolation step. And as I said I'm not even positive games leveraged the feature.

That’s right. I had no understanding of what level the VH bits were currently emulated (that is, if they were embedded in 16-bit color data before CLUT conversion). If they are not emulated at all, then somebody would still need to do that.