Closed m0ppers closed 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).
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.
ah that makes sense.
I am writing a new 3D frustrum clipper more efficient and avoiding these problems. Comes in version 1.8.
Yes I could avoid the extra lines.
The versions from 1.75 will not need the extra lines anymore. I close this issue.
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:
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.