Marzac / le3d

A straightforward and easy to use 3D software renderer for real-time retro graphics.
https://marzac.github.io/le3d/
MIT License
60 stars 6 forks source link

Swapping frames in rasterizer #34

Closed m0ppers closed 6 years ago

m0ppers commented 6 years ago

As I am now going for the direct hardware framebuffer for the vampire stuff I need to exchange the framedata in the rasterizer somehow. I simply pointed frame->data to my new buffer and thought I was done but apparently there is also the pixels pointer which is what is being used in the result and in the filling methods.

I must admit I don't really get its point. the first row and last row in the pixeldata seem to be unused? ( frame.height + 2). This is also super strange to handle from the outside:

My main code:

    LeBitmap off1;
    off1.allocate(WIDTH, HEIGHT + 2);
    LeBitmap off2;
    off2.allocate(WIDTH, HEIGHT + 2);

To me the pixels thing seems superfluous? What does it do?

my current workaround is a resetPixels() method that adjusts the pixels pointer to the new framedata.

Marzac commented 6 years ago

This is a weird optimisation connected with frustrum clipping.

The idea behind is that all triangles are cut to fit the frustrum, as early as possible, in the rendering pipeline. The rasterizer then assumes NO triangle passed has pixels outside the frame buffer. Therefore there are absolutely NO memory boundary checks when filling triangles, making algorithms simpler and more efficient.

However, the 3D frustrum is computed using floats and, due to rounding issues, sometimes it might round to the next pixel (outside the frame buffer). This is not a problem using the 2D frustrum ATM. There are two memory guards lines to handle that (above and below the picture).

Marzac commented 6 years ago

I would suggest, use the 2D frustrum right now. I will have a real look at the 3D frustrum to guaranty that the rounding works all the time so that we can drop these memory guard lines and make it easier to directly access the hardware buffer.

m0ppers commented 6 years ago

ah that makes sense.

Marzac commented 6 years ago

I am writing a new 3D frustrum clipper more efficient and avoiding these problems. Comes in version 1.8.

Marzac commented 6 years ago

Yes I could avoid the extra lines.

Marzac commented 6 years ago

The versions from 1.75 will not need the extra lines anymore. I close this issue.