Ian wrote:Because the nametable is packed like
The data is actually arranged in 32-bit chunks in little endian format, so that tiles 0, 1, 2, and 3 will be stored as 1, 0, 3, 2
I wonder if the tilegen is just loading odd numbered tiles. So the odd number gives you the data for the even number.
If you apply this logic drawing works pretty much normally ..
But in the case of the rolling start the because the adjacent tile is actually from a different layer .. perhaps it loads that instead of the start of the secondary layer. I can't think of any other reason for this bug :p
If the tile name table is arranged like that then it makes even more sense for tiles to be loaded in pairs and not individually.
I reckon what the real Model 3 tilegen chip is doing is using the mask table and the scrolling table/registers to determine the 64 tiles (or 32 tile pairs) it should load for each line. Suppose that the "ROLLING START" banner is scrolled left by 264 pixels; the calculated mask for the non-patched ROM would result in drawing 256 pixels from the plane A window layer (layer A'), followed by 256 pixels from the plane A background layer (layer A) which is blank. The tilegen calculates an offset of 16 tile pairs (264 / 16 = 16.5, rounded down to 16), so it would load tiles #33 to #64 from the window layer and would not load tile #1 at all; instead it would load tiles #33 and #34 from the background layer, followed by #35 and #36 and so on up to tiles #63 and #64.
Because there is a further 8-pixel offset not yet accounted for, the tilegen has to scroll left by another 8 pixels which means that tile #33 from the window layer is not drawn (as it would be outside the display area) and it draws tiles #34 to #64 - so far 248 pixels have been drawn. It then draws tile #33 from the background layer as this is the next tile in the list, even though the mask specifies that it should switch from the window layer to the background layer 8 pixels later. After drawing tile #33 from the background layer it checks the mask, reloads the scrolling value and then draws tile #33 AGAIN before drawing the rest of the tiles as normal.
This is my best guess as to how the scrolling glitch does not occur on the actual Model 3 tilegen chip. If no one else can come up with a better theory, we basically have three choices from this point:
1. Leave the tilegen code alone and keep the patch that I made; not a particularly elegant solution but it works.
2. Remove the patch and reimplement the tilegen code to follow the behavior described above; we're basically guessing that this is how the real hardware works. (Need to test to make sure it doesn't break other games.)
3. Run a test on real hardware to check if my theory is correct; making the last four tiles in each line of the plane A window layer non-blank would be enough to verify.
