-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wednesday 28 April 2004 20:21, Lionel Ulmer wrote:
> > That seems really overkill. It's OK to define some symbols ourselves
> > when they have well-known values, but I don't think shipping the full
> > headers is really necessary; and I don't see ho
> There should only be three headers. In mingw w32api they ship
> glext.h,gl.h and glu.h in a GL subdirectory. Is anything else needed
> for Wine?
Well, in the X11 world, there are also glx.h and glxext.h (the latter needed
if we want to use GLX extensions).
Lionel
--
L
Hello,
--- Alexandre Julliard <[EMAIL PROTECTED]> wrote:
> That seems really overkill. It's OK to define some symbols ourselves
> when they have well-known values, but I don't think shipping the full
> headers is really necessary; and I don't see how it would solve
> issues
> like the above anyway
> That seems really overkill. It's OK to define some symbols ourselves
> when they have well-known values, but I don't think shipping the full
> headers is really necessary; and I don't see how it would solve issues
> like the above anyway.
Well, the more 'recent' extensions we will use, the more
Lionel Ulmer <[EMAIL PROTECTED]> writes:
>> I could only find glCompressedTexImage2DARB in my glext.h
>> (SGI OpenGL 1.2.1). Any clues?
>
> Alexandre,
>
> Would you accept a patch to provide our own OpenGL headers in the Wine
> source tree ? From what I know, their licensing is pretty relaxed (I
> I could only find glCompressedTexImage2DARB in my glext.h
> (SGI OpenGL 1.2.1). Any clues?
Alexandre,
Would you accept a patch to provide our own OpenGL headers in the Wine
source tree ? From what I know, their licensing is pretty relaxed (I can
check though) and it would prevent all the myria
Hi,
this is with current CVS:
../../tools/winegcc/winegcc -B../../tools/winebuild -shared
../../../src/dlls/d3d8/d3d8.specbasetexture.o cubetexture.o d3d8_main.o device.o
directx.o drawprim.o indexbuffer.o resource.o shader.o stateblock.o surface.o
swapchain.o texture.o utils.o vertexbuffe
