Bart wrote:A 2px offset is not inconceivable. The tile generator is a separate chip after all and the mixing happens after the Real3D frame buffer is scanned out because the tile generator renders one display line at a time. Position synchronization is of course just controlled by the respective clock timing, and it's quite possible that the 2px shift might even have been unintentionally introduced early on and never rectified.
One thing I'm completely ignorant about is how anti-aliasing would have been implemented. Doesn't this require a larger frame buffer and then downsampling to the desired resolution? Model 3 is known to have definitely implemented anti-aliasing logic that was quite good for its time.
Ian wrote:But how does it draw under the 3D data? If you have translucent polys, they will need to be blended with the bottom layer. It must be able to draw directly into the frame buffer surely.
That's exactly what I've thought, considering the "frankenbuild" nature of Model3 and the rush to introducing to market, I've read in other forum that probably that Real3D was even unfinished/unpolished version of the Real3D Pro/1000, with missing feature, or experimental ones successively removed.
Ian wrote:Harry, I'll get around to pushing some of these changes, especially this one. I thought originally alignment could just have been off for subviewports, but it really seems it is for everything.
Not 100% sure what the best way of solving it is.
We could shift the 2D layer 1 pixel, and the 3D layer one pixel in the opposite direction, then scissor the outside so theres just an equal thin black line around the entire viewport. Also have to do that horrible, hack for gun/window pos
Users browsing this forum: No registered users and 2 guests