On Sunday 20 March 2005 23:00, Daniel Phillips wrote: > On Saturday 19 March 2005 17:22, Timothy Miller wrote: > > ...On the structure of rendering commands: > > > > The first word contains a command number and a set of bits that > > indicate the presence of an optional parameter. > > Some commands will repeat many times with the same format, so we might > want to have a separate command to specify the format. I'm thinking > mainly about what should be the most common command, "draw trapezoid". > If there is plenty of slack space in the first word anyway, this is > moot, but why don't we try to fully define the trapezoid command and > see how it looks? > > We noticed a while back that trapezoid commands are bulkier than > triangle commands because we have to spell out all the gradients > instead of deriving them from vertices. Also, we need to give the > parameters twice for at least one of the triangle vertices because the > top of the trapezoid is truncated to a scan line. Finally, we have > nearly two trapezoids on average for each triangle. > > The last point is painful. But we can do something about it, we can > have a "continue trapezoid" command that only supplies the gradients > that change in the second trapezoid of a triangle. This doesn't have > to be a separate command, it can be an optional field-of-fields. There > are two flavors, left-knee and right-knee. In the right-knee case the > only thing that changes is dX2/dy; in the left-knee case every dy > changes.
I vote for an explicit "continue trapezoid" command, or an equivalent mechanism that allows an arbitrary number of continuation trapezoids. The rationale is that this allows us to render some quads (and by extension, polygons) as three trapezoids instead of splitting them up into two triangles and ending up with four trapezoids. The "continue trapezoid" command or command section would come in two flavours: One that only changes X2y, one that changes X1y and all remaining *dy values, and one that changes both (again, think quads, where you can have left and right knee on the same scanline). The rest sounds pretty reasonable. I should get my model driver up to speed so we can figure out how expensive all this will be on the CPU. I'll probably find the time to do this in the next week. cu, Nicolai
pgp2S4SuUBn0x.pgp
Description: PGP signature
_______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
