Project progress: 85% to 90%

sub_C2D36 splits into multiple parts.

It looks like it analyses the polygon and works out what to plot, but it doesn't actually do the drawing - that seems to be sub_C2299, because if I make sub_C2299 an RTS, no polygons get drawn at all.

So let's rename:

• sub_C2D36 -> AnalysePolygon
• sub_C2299 -> DrawPolygonPixels

Can always rename, as always (the last one isn't great, but I need to distinguish it from the top level DrawPolygon).

Also, split off a few subroutines, which may or may not be right, but hey:

• sub_C2FCC
• sub_C3087
• C2D5D looks like a sub in own right, as it is only called from way below
• C2D93 = Part 2 of AnalysePolygon?

AnalysePolygon starts with code that sets polygonPoint to +4 with the polygon point numbers.

Already set up for object polygons, but for tile triangle and quadrilateral we have some maths to follow.

The tile corners are laid out in the drawing tables like this:

  offset x          offset x + 1

  offset 32 + x     offset 32 + x + 1

where x is xTileToDraw.

So EOR #32 flips between the two rows:

• + 1 moves left to right
• - 1 moves right to left
• + 32 + 1 moves from top-left to bottom-right

Might need to come back to this...

As this is complex, let's try it from the other end: DrawPolygonPixels.

This seems a bit simpler and contains a construct from Revs at the end - a construct that draws a horizontal line (it's a simplified version of the DRAW_BYTE macro from Revs).

So it looks like DrawPolygonPixels draws the polygon one pixel line at a time, using the left and right x-coordinates in L5A00 and L5B00 and working from the high to low y-coordinate in Y.

This might be easier to document, so let's try:

• L5A00 -> xPolygonLeft
• L5B00 -> xPolygonRight

Looks like tileAltitude is being reused, so add another label L0006.

Also L0004 and L0006 seem to contain y-coordinates of some kind, as they are combined and used to look up the screen row address.

And L0006 gets flipped in direction, so that high y is down the screen, and this is the opposite to the pitch angle direction.

So this is effectively the screen projection.

So L0004 and L0006 look like the pitch angle of the top and bottom of the polygon? But in terms of screen coordinates.

OK, so rename:

• L0004 -> yPolygonBottom
• L0006 -> yPolygonTop

These may be the wrong way around of course, but we can change that.

And the adding and dividing by 2 is finding the middle polygon pixel line?

Self-modifying code too! Lovely...

Looking at DrawPolygonPixels further, split it up into four parts.

L3E00 and L3E40 are indexed by the value of polygonColours+X.

i.e. %00eeff00 + %xx = %00eeffxx

(which fits, as %00111111 = 63 = &40).

So break the table up into bytes, and convert them into pixel bytes in binary as they are poked directly into screen memory.

Part 4 of DrawPolygonPixels is a bit like Revs and jumps into a string of fill instructions to draw a horizontal line, so this is pretty easy to document.

Though the calculation to find the offset into the unrolled loop is intriguing...

Part 1 of DrawPolygonPixels is almost done and converts polygon coordinates into screen coordinates (i.e. flipping the y-axis).

Polygons are not drawn if left > right, i.e. it's flipped horizontally.

Ditto if bufferYawRight bottom > top, i.e. it's flipped vertically.

Part 3 is the entry point, does some maths and possibly jumps up to part 2.

Looks like it's comparing x-coordinates from the polygon to L0035 and L0061, which are set up in the buffer config.

We discovered this about the buffer config earlier:

  L0036 = L0035 + L0061

and part 2 is subtracting L0035 from an x-coordinate and jumping to part 2 if the subtraction underflows.

So these are probably some kind of left, right and width coordinates for the buffer, so we can calculate whether the line fits into the buffer, or beyond the edges.

Time to experiment with the buffer variables!

• L0036 -> bufferYawRight
• L0035 -> bufferYawLeft
• L0061 -> bufferYawWidth

The last two could be the other way around, but I suspect Crammond would put the right and left values together.

I think we're dealing with yaw angles here and not x-coordinates, so rename:

• xPolygonRight -> polygonYawRight
• xPolygonLeft -> polygonYawLeft

This may not be right, but I think we're still in yaw angle territory for this process...

Documented part 3.

Getting there slowly, but it's complex stuff, and I'm not sure whether polygonYawRight does in fact contain yaw angles, or whether it's a pixel coordinate of some kind - I guess we'll have to leave that to when we go back to document AnalysePolygon properly.

Also, rename:

• DrawPolygonPixels -> DrawPolygonLines

It just feels a bit clearer.

>>> I have now broken through the 90% barrier <<<

Wow, 90% done? It's so close... especially as zero page accounts for 1.5% of the remaining 10% and that's really close to completion.