>This is done inside glide, mesa doesn't see it. I was wondering about
this for
>the mga driver - do you have the magic incantations to build the displaced
>vertices for the two triangles? I don't see any way to avoid taking
1/sqrt(area)
>to get the increments. It's the square root I'd like to avoid...
Fat line joining is rather non-trivial. I think the OpenGL spec has an
exact description of what is supposed to be done.
For textured single unit lines, I think just drawing from a surrounding one
unit box corner at each vertex would work fine, although even that might
have some artifacts with blending enabled.
>On the other hand, syncing is much much slower again. It'd be good to do
this
>once, in Mesa, with assembly where possible.
>
>
>> Related to that, but needing a bit more work, would be synthesizing pixel
>> and bitmap operations by uploading into a driver work texture, then using
>> texture mapped triangles to image.
>>
>> It would be nice for driver implementation to be able to just do textured
>> triangles and have all the other primitives synthesized automatically until
>> someone cares enough to pick out the functionality that can be more
>> directly accelerated.
>
>Are you talking about the read/write spans/pixels functions in dd.h?
No, the glDrawPixels / glBitmap paths. The matrox cards can handle almost
all of these with iload blits, but a lot of cards can't do anything but
dumb transfers on inline image loads, and again, the idea would be to make
it easy to bring up a driver for a new chip without any fall-over-dead
speed paths.
John Carmack
_______________________________________________
Mesa-dev maillist - [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev
