So, this is how I see it working:
- Run linegens #1 and #2 until next Y_stop
- If fill enabled and empty pixels between the two lines, use linegen#3 to draw a raster line between the two points
- If #2 has reached the end, reset it to draw from second point to the last point
- Has #1 reached the end? No - loop back to No.1 above, otherwise triangle is complete
I realise it's a compressed version of what's going on in geo.bas, it's more of an overview than anything else as it raises a big question in my mind; namely, point number 3. It's going to be expensive to have another set of 12-bit X/Y coordinate registers to pipe X[1]Y[1],X[2]Y[2] into them to feed linegen#2, then I'll lose a clock cycle when linegen#2 completes the second line and switches over to the third line, as the new coordinates are clocked into its registers. Or maybe it's not expensive at all and it's a better option than having another linegen? ![Confused :-//](https://www.eevblog.com/forum/Smileys/default/confused0024.gif.pagespeed.ce.5xOqKkq0Co.gif)
Close, as in do not worry about the extra 2 clock cycles as linegen swaps from xy[0]-xy[1] to xy[1]-xy[2].
Ok, we have 3 coordinates. xy[0,1,2].
For now, we will always assume xy[0] has the lowest Y coordinate and, xy[2] has the highest Y coordinate.
This means our master first linegen #1 will run A-B from xy[0] to xy[2].
For now, hard wire these in.
Our second linegen #2 will run A-B from xy[0] to xy[1].
Once it has reached xy[1], then, it will run A-B from xy[1] to xy[2].
For now, hard wire linegen #2 A-B from xy[0] to xy[1].
The xy outputs of the first linegen #1 output coordinates will feed the third linegen #3's A coordinates while the xy outputs of the second linegen #2 coordinates will feed the third linegen #3's B coordinates input.
The third linegen #3's output coordinates will now drive the pixel_cmd_ready and the actual plotting xy coordinates.
Procedure order:
1. Wireup the basics.
2. Only get linegen #1 to draw a line like now, except, the 'line_dat_rdy' will now be driving the 'pass_thru_a' on the linegen #3 and you should be able to still simulate and draw lines on the screen, except the line will now go from xy[0] to xy[2], not xy[0] to xy[1]. (YStop disabled.)
3. Next, when calling the line, start linegen #1 and let it draw waiting for the next Y step, then, start linegen #2 and let it draw waiting for the next Y step, then go back to linegen #1, then #2 and cycle until linegen #2 is finished, then let linegen #1 finish it's line. This will construct only 2 faces of the triangle.
4. Next, when linegen #2 ends, swap and re-run it's coordinates so that it begins again A-B now from xy[1] to xy[2]. Then once setup, let it run until it has a matching Y coordinate and now continue cycling linegens #1 & #2 until both finish their lines. If you have completed this process properly, you should be rendering an outline of a triangle. Test a few triangles on the Z80, following the rule that the Y in xy[0] is the smallest Y of the 3 coordinates and the Y in xy[2] has the largest coordinates.
BONUS:
Then worry about enabling the fill....
5. Fill. If the fill bit is in the draw command is enabled, the current linegen loop:
Until linegens #1,#2 end, loop (y_wait #1,y_wait #2)
Will now change to:
Until linegens #1,#2 end, loop (y_wait #1,y_wait #2, run linegen #3 from A-B until linegen #3 ends)
Running this should now render filled triangles.
If you haven't noticed yet, because of the wiring, just by altering the sequence rules you can render a single line, or by changing the coordinates feeding linegen #1 & #2, you can render boxes, filled boxes, or any 4 sided polygons. But not yet. This comes after:
Then worry about sorting the coordinates to the 3 triangles in the geometry unit. as the coordinate selection process for linegen #1 with sequence order will be built into that coordinate selection logic based on which geometry shape has been selected meaning this processing block could generate any draw function/shape except ellipses.