[Patch] 2D-3D Layer Alignment (part 1)

[HarryTuttle]

(Edited)

I've a 'gut feeling' that either the 2px shift is the intended behavior, or that some elements of the 2D layer (for example non-scrolling planes) are shifted. But here I'm just speculating...

[Bart]

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.

The fractional viewport coordinates have always struck me as bizarre, though. We even bother with implementing rounding logic? Why not just use integers? 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.

[HarryTuttle]

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.

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 Model3's Real3D was even unfinished/unpolished version of the Real3D Pro/1000, with missing features, or experimental ones successively removed.

That could be hinted, if I'm not mistaken, by the fact that some header nodes documented in SDK aren't even populated, or by the the presence of hi-specular lighting not mentioned in the official devguide.

[Ian]

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.

There's many ways to fudge anti-aliasing. OpenGL does pretty decent line anti-aliasing and you don't need a multisampled back buffer for that.
I know a few polys in scud are marked for edge smoothing.

Personally I am more puzzled about the tile generator. I get how it composites over the top of the video at the end. 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.

[HarryTuttle]

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.

Out of curiosity, where is such an example of 2D under transparent/translucent 3D ?

Update:

could it be, for example, the scrollfog layer on top of sky background in bass during the intro?

[Ian]

Frame buffer is like a bitmap. Normally when you start a frame you wipe it with a clear colour ie black. How do you draw under this? As for translucent the scroll fog colour is blended over the 2d background. See the sky is Sega bass fishing.

[Ian]

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.

I'd probably say the model3 basically was a real3d pro-1000. With just a bit of extra h/w added to turn it into an arcade. The sdk for the real3d pro-1000 is almost completely identical to the model3 gpu. The only possible exception I can think of, off the top of my head is fixed shading. The values in the sdk are explicitly clamp from 0-127, where as on the step 2 version of the model 3 we see -128 -> 127.

But yeah, it is a bit weird how things like specular are completely undocumented.

[Bart]

Tile generators operate at the scan frequency, so they can't be used with a frame buffer. Mixing logic between multiple tile and sprite generator chips was common, however. It's entirely possible that the frame buffer output signal was digital and tagged with some meta information indicating whether a pixel was "background" (clear) or not. I found the LinkedIn profile for one of the lead engineers on Model 3 and he wrote that he designed the pixel pipeline which "included logic for adding fog and illumination to background scroll pixels and blending with polygon pixels." Polygon pixels in this context almost certainly refers to the frame buffer, implying that there was some additional pathway for blending frame buffer output with the scroll layers emitted by the tile generator.

[Ian]

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

[HarryTuttle]

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

Ok

One day, however, we could have a post-process pass and try, with shaders, to emulate crt monitor and overscan a bit like the arcade so none will notice it...