FPGAzumSpass
patreon
RDP progress
🕑 Added 2023-08-26 06:37:52 +0000 UTCHi everyone,
after working on the RDP for 10 more days, I want to use this post to tell you more on the recent changes and the technical side of them.
First, let's look at the overview of the RDP and the status in the core:
Improvements have been made mostly for:
- Texturing (including perspective correction and transparency)
- Z-Buffer
- Copy mode
To give you a better idea what the changes really mean, I picked some comparison screenshots.
Perspective correction:
If you looks at the ground texture, you can tell that in the right image it's completly off. This is, because the texture is in 2D space and accessed by x/y coordinates. These coordinates however have to map to 3D space. This would be done for example with affine transformation like the PS1 does it. The big downside is, that it doesn't work well with large polygons, as the calculation error increases in the distance.
For the PS1, developers took care and reduced the polygon size. As the N64 has fixed hardware in the RDP to calculate this perspective correction, developers did not took care. In fact, it's even better to not break big polygons down, to reduce the overhead cost. But the result is that the image without the perspective correction can look very strange.
Z-Buffer
The second big change was the implementation of the Z-Buffer. If you imagine the screen pixels with X and Y coordinates, you could also imagine that the screen is not flat, but would have depth. So for each of the pixels to be calculated, you cannot only determine a X and Y position on the screen, but also a Z position as distance from the camera.
When the pixel is stored in the framebuffer, the Z position is stored in a different block of memory called Z-Buffer. Compared to the framebuffer, which exists multiple times for dual or triple buffer output, the z-Buffer is only required once, as it is only used to calculate the most recent image.
Imagine rendering the image above: you might start with the castle in the background, then draw the water on top, then the ground and Mario as last object. But what happens if you draw the water after the ground? You can see the result in the right image: the water will be above the ground, which is obviously wrong.
With the Z-Buffer this is no issue at all: you draw the ground and when it is drawn, each pixel that makes up the ground will store it's Z position in the Z-Buffer. When the water is drawn later, it will calculate the Z position of it's own pixel and compare it with the Z-Position of the already stored pixel. Only if the new Z position is smaller, it will be drawn at all, because then it is nearer to the camera.
Copy mode:
The copy mode is a special feature of the RDP that allows to write up to 64 Bit of data from the Texture RAM per clock cycle into the framebuffer. Usually rendering only allows to draw 1pixel per clock cycle, so for most cases this would be 16 Bit per cycle for the most often used 5/5/5 color mode.
But because ithe copy mode handles multiple pixels at once, it cannot use most of the rendering pipeline, so there will be no Z-Buffer or Color Blending for example. Therefore this mode is mostly used to draw 2D elements that don't need to be resized or rotated.
Texture modes:
The RDP does offer plenty of Texture modes:
- RGB color: red, green and blue color values
- YUV color: alternative color scheme, not much used
- Palette mode RGB: uses the texture value for a second lookup to a color table with 16 Bit colors
- Palette mode Gray: uses the texture value for a second lookup to a color table with Grayscale
- IA: different Grayscale for Color and Alpha
- I: same Grayscale for both Color and Alpha
Each of the Texture modes can be used with 4, 8, 16 or 32Bit tiles. So in total there are 24 combinations, with 10 out these 24 being not documentated and not recommended for use.
The current core now implement 13 of the 14 official texture modes, with only YUV missing.
Texture bugs:
As you can imagine with so many different modes, there are plenty of cases to be covered. I fixed some obvious bugs that have shown up, but the overall progress of completion still has to be proven.
Alpha blending:
The RDP offers several possibilites for handling semi- or completly transparent objects, either through the color combiner, alpha combiner, color or alpha blender, subpixel coverage or even z-Buffer.
Some of those paths were missing and some are still be missing, but for the majority of games it seems to work now.
I attached a new test core to this post which you can try. The improvements compared to the last one are very significant so give it a try if you like.
Have fun!
Comments
Tetra
The progress here is insane! Thank you for letting us take a ride with you along the way, Testing this is insanely fun to me, idk why, but seeing each update here or on discord is amazing.
Shouldn't be. The information for AA is already stored, but isn't yet processed in the video out module.
You are amazing!! These posts are so informative. I was wondering about N64 anti-aliasing. Is this a difficult thing to do on the DE-10Nano?
