Guest User

vdp1 performance improvements

a guest
Jul 3rd, 2026
298
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 2.33 KB | None | 0 0
  1. Turns out that even though the slave had some room, making the CPU finish earlier was of no help in this case since I had to wait for the frame buffer swap before sending the new polygon data and launching the plotter. So my only option to bring the frame rate up was to improve VDP1 performance.
  2.  
  3. -Morphing levels were moved closer to the camera, that forces collapsed faces to be closer too, and each collapse level brings a new collapse texture. Effectively what I’m doing is triggering a new mip-mapping level closer, and Saturn being a forward mapper iterates through texels (instead of the screen buffer scanlines) which makes texture sizes have a significant impact.
  4.  
  5. -The previous step causes the CPU to process less vertices, so I could expend more time being more aggressive when reordering faces to try to make sure the first vertex is always on screen (having the plotter start rendering a quad which has the first vertex outside the screen can have significant performant on Saturn, but it isn’t as easy as rotating the quad, since Saturn doesn’t have UVs the rotating possibilities are limited)
  6.  
  7. -I’m also now discarding polygons in subdivision that only contain a few pixels inside the screen. Visually this is barely noticeable but polygons near the clipping plane tend to be big and cause a significant performance drop.
  8.  
  9. -The Saturn version has CLUT fog (fog implemented through palette swaps), before when the distance was enough, I was just swapping palettes. Now also discard vertex coloring for those. Processing a polygon with gouraud is significantly more expensive for VDP1. That also means the polygons getting close to enter the “fog-area” will slowly merge their vertex colors to neutral.
  10.  
  11. -When importing the level, I check for polygons for which all vertices have the same colors, in such case I offset the palette by the vertex colors and store it in VDP2. You can store up to 128x16bit colors in VDP2 ram and reference them when creating a quad command in VDP1, but gouraud will be disable. In this case since all the vertices have the same color is no problem. I have memory left to store palettes in VDP1, but rendering those referencing VDP2 palettes was slightly faster on the GPU.
  12.  
  13. After all these changes, both the CPU and the GPU are less stressed, especially the CPU which opens up different possibilities for the future
  14.  
Advertisement
Add Comment
Please, Sign In to add comment