Re: Post-processing hook for vertex setup code

Am Mo, den 20.12.2004 schrieb Keith Whitwell um 16:54: [snip] Hi Felix, Your patch looks good to me. If you're looking for ways to avoid the indirect function call, probably the way to do it is to somehow try and get onto the DO_FALLBACK path. This is difficult for PTEX vertices as

Re: Post-processing hook for vertex setup code

Hi Keith, I'm attaching my current solution for the Savage driver. I'm going to commit this later today. It doesn't need any modifications of the common TNL code. It is probably not the most efficient solution though, since it requires an indirect function call for each emitted vertex. That said,

Re: DRI and framebuffer

Am Sa, den 18.12.2004 schrieb Tomas Carnecky um 14:54: Tomas Carnecky wrote: Hi, Can I control a graphics card _completely_ with DRI? I mean allocate the framebuffer, switch between modes etc. Or do I need some kind of helper code that does these things (like fbdev or the Xserver)?

Re: DRI and framebuffer

Am So, den 19.12.2004 schrieb Tomas Carnecky um 15:32: Felix Kühling wrote: Am Sa, den 18.12.2004 schrieb Tomas Carnecky um 14:54: Most (all?) supported hardware doesn't support multiple clipping rectangles in hardware, so the driver iterates over them and draws all primitives once in

Re: Post-processing hook for vertex setup code

Am Fr, den 17.12.2004 schrieb Keith Whitwell um 22:59: Felix Kühling wrote: Hi, I'm trying to get projective textures working on hardware that doesn't support homogenous texture coordinates with the new vertex setup code (t_vertex.[ch]). The problem with this is that the W coordinate