other parameters like diffuse_funcs sounds sane here,
> although some extra care is needed to keep working without
> GL_ARB_multitexture support.
> Also I strongly recommend writing a test here. Generally, fixed
> function attributes with non-standard data types are spooky on
>
Am Dienstag, 19. Juni 2007 18:46 schrieb H. Verbeet:
> On 19/06/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> > Am Dienstag, 19. Juni 2007 15:44 schrieb H. Verbeet:
> > > Not specific to this patch, but will you remove the fvf field from the
> > > stateblock as well?
> >
> > I am thinking about
On 19/06/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
Am Dienstag, 19. Juni 2007 15:44 schrieb H. Verbeet:
> Not specific to this patch, but will you remove the fvf field from the
> stateblock as well?
I am thinking about that, but currently it has to be known to wined3d for
reporting the prope
Am Dienstag, 19. Juni 2007 15:44 schrieb H. Verbeet:
> Not specific to this patch, but will you remove the fvf field from the
> stateblock as well?
I am thinking about that, but currently it has to be known to wined3d for
reporting the proper fvf on GetFVF with state recording. A future patch coul
Not specific to this patch, but will you remove the fvf field from the
stateblock as well?
On 14/01/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> How about something like R2VB?
I think we can implement R2VB if we want it(it is an ATI hack) by just setting
a VBO as a render target. The extensions imply that this is supposed to work,
although the performance isn't guaranted to be opti
Am Freitag 12 Januar 2007 20:06 schrieb Christoph Bumiller:
> Stefan Dösinger wrote:
> > We will need software shaders for a correct implementation of
> > IWineD3DDevice::ProcessVertices. It supports Vertex shaders, but I
> > don't really think OpenGL feedback mode is what we want here.
> >
> > May
Am Samstag 13 Januar 2007 21:37 schrieb H. Verbeet:
> On 12/01/07, Christoph Bumiller <[EMAIL PROTECTED]> wrote:
> > Stefan Dösinger wrote:
> > > We will need software shaders for a correct implementation of
> > > IWineD3DDevice::ProcessVertices. It supports Vertex shaders, but I
> > > don't really
On 12/01/07, Christoph Bumiller <[EMAIL PROTECTED]> wrote:
Stefan Dösinger wrote:
> We will need software shaders for a correct implementation of
> IWineD3DDevice::ProcessVertices. It supports Vertex shaders, but I
> don't really think OpenGL feedback mode is what we want here.
>
> Maybe we shoul
Stefan Dösinger wrote:
We will need software shaders for a correct implementation of
IWineD3DDevice::ProcessVertices. It supports Vertex shaders, but I
don't really think OpenGL feedback mode is what we want here.
Maybe we should remove it for now, but keep the code somewhere(in the
wiki maybe).
up things, all of software shaders should
be removed.
There's tons of code in drawprim and *shader.c, which is disabled,
doesn't work, and isn't on the right track if you ask me. None of the
changes to make the shader parser 3.0 compliant are used in the disabled
paths. There'
things, all of software shaders should
> be removed.
>
> There's tons of code in drawprim and *shader.c, which is disabled,
> doesn't work, and isn't on the right track if you ask me. None of the
> changes to make the shader parser 3.0 compliant are used in the disabled
>
Stefan Dösinger wrote:
Now that almost everything is gone from drawPrimitiveDrawStrided we don't need
a subfunction for calling drawStridedSlow/Fast any longer
I think while we're cleaning up things, all of software shaders should
be removed.
There's tons of code
Does this reset the currently used program to 0 when fixed function is
supposed to be used again?
I think we should just do glUseProgramObjectARB(programId), since when
fixed function is supposed to be used the program id will be 0. That
also mean you don't have to do an explicit glUseProgramObje
14 matches
Mail list logo
