Month: November 2007

I didn’t thought it would be that hard to add this feature to my vdp1 rendering system …
Anyway, for those interested, the discussion regarding this matter started on this page.

Now for the good stuff : backgrounds aren’t plugged in as I haven’t finished my VDP2 cache yet, but the sprites are fully functionnal.

• Previous rendering :

• Current rendering :

Quite neat heh 🙂
Perspective correction won’t work in some particular cases (like non trapezoid quads), but it’s marginal. I’m trying to get info on how making it work in every possible quad configuration, but it’s getting really technical and mathematical, and I’m not that good at it :p

Now I’m moving back to my VDP2 cache 😉

I’ve always been worried about the way OpenGL renders the Saturn’s distorded polygons. As the Saturn doesn’t specify any Z coordinate (aka depth coordinate) when displaying a polygon, OpenGL has to approximate its value to apply a texture to it.
When the polygon is a regular quadrangle (ie a square, rectangle, etc. ), the texture coordinates and the polygon ones are identicals, so OpenGL texture mapping is correct. In the case of a distorded quadrangle, only half of the texture coordinates are identical to the polygon coordinates, and the texture seems to be mapped on the polygon as 2 different triangles. (OpenGL always splits quadrangles into 2 triangles as modern graphic cards only work with triangles)

Maybe a graphical example will be better to grasp the idea :

• original texture / texture coordinates (will be used to map the texture to the polygon)

  /

• texture coordinates + regular quadrangle coordinates (identical to the texture coordinates) = correct texture mapping on the quad

+ =

 

• texture coordinates + distorded quadrangle coordinates(different from the texture coordinates) = incorrect texture mapping on the quad

+  = 

So I did some research, I wasn’t really sure that this problem could be solved without using a software renderer, but I was wrong. Using the texture projective space allows to change the way OpenGL maps the texture coordinates to the quad coordinates, rendering neatly distorded quads (I won’t enter in the details :p )

Here is a sample. I won’t use the same example as above as I haven’t yet implemented it in the VDP1 renderer, but the following screenshots were done through a test renderer in the emu. The left one is rendered like it was done so far, and the right one using the above technique. Both use a 4*4 black and white checkerboard as texture.

Ok. After some more testing, I have to face it : my cache isn’t that good. When the cache is used at full capacity (ie nothing is read from the Saturn memory, everything is already in the vector and cells are just displayed to the framebuffer, I only have a 0.5 fps increase …

So I did some more thinking.
The cache is organized like that :

• one map storing 8*8 pixels textures (one texture from the map can be used by one or more cells)
• one vector storing cells (up to 4096 by page), each cell being linked to a texture in the map

Currently the cache detects when a cell has changed in the Saturn memory, reloading it if necessary. So when the framebuffer is filled with vector data, each cell is displayed.
Here’s the catch : this method isn’t using the graphic card memory to store texture data. So every cell displayed is loaded in memory, displayed then discarded. That costs a lot performance wise …

So I’ve decided to do it another way :

• the map and vector contents will stay the same as before
• display to the framebuffer won’t be done directly : instead 512*512 pixels textures will be defined, filled with cell data, and stored into the graphic card memory. In that case a whole page (4096 cells) will be cached at one time, and reused at will.

I need to be careful not to saturate the graphic card memory, but I expect a huge perf increase 🙂

And as a nice bonus, I can this way handle per dot and per cell priority, without much effort 😉

Now that’s the theory. I hope that I won’t be disapointed by the results …