Since TinyGL is an implementation of openGL the most important category of draw call falls into the category of rasterization: that is, when vertices are issued inside tinyGL's state machine they are then transformed into screen buffer coordinates and then rasterized into triangles or rendered as lines.
However, since 2D blitting is implemented with a different code path we should regard this as a second category.
So we end up having two categories of draw calls: rasterization and blitting; those categories contain different cases though, so they should be separated in types:
Rasterization can either be a triangle rendering draw call or a line rendering draw call, whereas Blitting can occur on the screen buffer or the z buffer.
I will implement those two different Categories as two subclasses of DrawCall but I will differentiate the logic behind the types inside the implementation of those two classes instead of creating more indirection (as they share 90% of the code and only a few things are to be implemented differently between types inside the same category).
As this task is quite complex and elaborate I decided to split everything in 4 sub tasks that will help me track my progress and make sure that everything is working on a step by step basis:
- Implementing a system that store and defers draw calls instances until the "end of frame" marker function has been called.
- Implement a system that detects which part of the screen is affected by each draw call and shows a rectangle on the screen.
- Implement the logic behind draw calls that allows the caller to specify a clipping rectangle for that specific instance.
- Implement the logic that detects the difference between draw calls and performs clipping on them.
The next post will cover the implementation of those DrawCalls subclasses more in depth so stay tuned if you're interested in this!
Your point 2 has an interesting problem though, as you'll be touching the screen, which is also where the data is going, how do you plan to do this? Double-buffering for the time being, and doing extra writes to the screen buffer (otherwise you'll quite fast end up with the entire screen covered in pieces of those rects.
ReplyDeleteCould you clearify what you meant in 3 and 4, specifically by the word "clipping".?
I don't see much of a problem, since calls are deferred you just perform all the drawcalls, store rectangles somewhere and then render those after the screen.
ReplyDeleteClipping means rendering only a part of what the drawcall is supposed to render on screen, basically just rendering a portion of it (the one that's affected by the dirty rects)
Ok, so what do you mean exactly by "difference between draw calls".
ReplyDeleteSecondly, how do you plan to avoid overlapping rects?
The difference would be what changed from the two sequences of draw calls (previous and current frame)
ReplyDeleteAs for overlapping rects I have two solutions in mind: either merge them or try to sort the drawcalls in order to avoid conflicts