Now that, thanks to Brian, the textures are pretty much taken care of,
I'm moving into the TNL module for the C++ framework.
First, some definitions. "TnL" here is defined as the object [or module]
that handles all the geometric (vertex) data (as oppsed to the context
which handles the state). This date is supposed to be transformed,
clipped and litted and rasterized, but not all these tasks are performed
by the TnL object itself - actually they are dispatched to the hardware
as much and as soon as possible.
As a special note, the TnL receives vertices but, since usually many of
the vertice properties (color, normals, ...) don't change from one
vertice to the other, in the OpenGL you have one API for each property
(glCoord, glColor, etc.). Still, it's _whole_ vertices that it's
receiving.
My proposal for modelling the TnL module is to model it as a
producer-consumer. The producer exposes an API similar to OpenGL,
updates a "current vertex", and produces vertices from that current
vertice. The consumer receives those vertices. I.e., something like
this.
class Vertex; // Abstract vertex
class TnLConsumer {
void consume(Vertex *vertex);
};
class TnLProducer {
Vertex current;
TnLConsumer *consumer;
TnLProducer(TnLConsumer *_consumer) {
consumer=_consumer;
}
Color3(r, g, b) {
current.r = r; current.g = g; current.b = b;
}
Coord3(x, y, z) {
current.x = x; current.y = y; current.z = z;
produce();
}
produce() {
consumer->consume(¤t);
}
};
What's special about this is that usually there isn't just a single
producer for a certain driver, but potentially a myriad of them (each
specialized for a set of hardware vertex formats or a software vertex
format). The same goes for the consumer. The appropriate producer and
consumer is chosen by the context, during a glBegin() call.
The reason to seperate the consumer and producer and not merge them
together is that when using call lists the producer/consumer won't be
sending the vertices to the card but to memory instead. This is
accomplished by using another consumer/producer wich writes/reads the
hardware vertices from memory.
This can be implmented in C++ without touching the current Mesa code, by
wrappring the current TnL code. But if the idea is pleasing we could
move the C TnL interface to this model. This would allow code for direct
hardware vertex generation (as is done in Radeon embedded driver) to
coexist nicely with code that needs to do some of TCL operations by
software.
José Fonseca
-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb:
Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
