Hi, I just wanted to apologize for the breaks caused by all the d3d8 commits. The gl headers are a real nightmare, and whereas we would have caught the problems over time, instead we get them all in one go. Just a question - What is the general feeling about us having our own gl headers. Our basic aim is to query support before using it, but we need to be able to compile in higher support than available on the build machine. I would initially see something as simple as a /include/wine/winegl.h, and we put all definitions in there (even if they would have come from glext, glx, glxext etc). To start with, it would only be used for d3d8 but probably ddraw support is easy. Comments? Jason
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le Vendredi 06 Juin 2003 00:18, Ann and Jason Edmeades a écrit :
Hi,
I just wanted to apologize for the breaks caused by all the d3d8 commits. The gl headers are a real nightmare, and whereas we would have caught the problems over time, instead we get them all in one go.
Well, i haven't fixed all in one pass (as seen by patch 49) ;( i believe its better now with last one
Just a question - What is the general feeling about us having our own gl headers. Our basic aim is to query support before using it, but we need to be able to compile in higher support than available on the build machine. I would initially see something as simple as a /include/wine/winegl.h, and we put all definitions in there (even if they would have come from glext, glx, glxext etc). To start with, it would only be used for d3d8 but probably ddraw support is easy.
well, better ;) my goal is to detect and active all capabilities on runtime and never bother again about declared/defined caps from gl headers (gl,glext,glx). For this we need an header where all defines and functions pointers are declared (as seen in d3dcore_gl.h)
Comments? Jason
Raphael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE+3/hkp7NA3AmQTU4RAu/uAJsGMt3tSEvB+i96aTPJiCWHzvSEAwCfff4P owtFTYfCx1iBheBjdXsbgjU= =DuHI -----END PGP SIGNATURE-----
well, better ;) my goal is to detect and active all capabilities on runtime and never bother again about declared/defined caps from gl headers (gl,glext,glx). For this we need an header where all defines and functions pointers are declared (as seen in d3dcore_gl.h)
As said in another mail, I agree for glext.h but not for GL.h. Or if we go that way, why not ship a 'valid' set of gl.h / glext.h / glxext.h that are known to work instead of redoing all the constants ? For example, we know that Raphael has a configuration where his tree builds... Well, let him ship his .hs in Wine :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
As said in another mail, I agree for glext.h but not for GL.h. Or if we go that way, why not ship a 'valid' set of gl.h / glext.h / glxext.h that are known to work instead of redoing all the constants ?
Curiously, why glext and not gl? I'd be more for shipping all 3 if required or merging them all into one wine header. Could we not just be causing ourselves the same problem further down the line otherwise?
For example, we know that Raphael has a configuration where his tree builds... Well, let him ship his .hs in Wine :-)
Perhaps they are copyright nvidia? :-) Jason
Curiously, why glext and not gl? I'd be more for shipping all 3 if required or merging them all into one wine header. Could we not just be causing ourselves the same problem further down the line otherwise?
It's just because we never had any problems until now with the standard GL headers... I.e. before we started playing with extensions in D3D / D3D8, we never had any build problems (basically, we detected GL as not supported in configure if the gl.h was too old / bad). So it was just to limit the number of code we add to Wine and the possible error that will happen to create hundreds of #defines / prototypes.
Perhaps they are copyright nvidia? :-)
AFAICR, NVIDIA only ships gl.h and glx.h files. You need to get glext.h and glxext.h yourself. And these we can generate ourselves from the GL extension registry :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
my goal is to detect and active all capabilities on runtime and never bother again about declared/defined caps from gl headers (gl,glext,glx). For this we need an header where all defines and functions pointers are declared (as seen in d3dcore_gl.h)
I completely agree, as it means packagers dont have to worry about the levels on their machines compared to the people running it. My only comment is whether d3dcore_gl.h is the right place for it, as putting it in something like \include\wine\winegl.h would mean the definitions can be reused by ddraw, and the opengl dlls in the same way. Jason
their machines compared to the people running it. My only comment is whether d3dcore_gl.h is the right place for it, as putting it in something like \include\wine\winegl.h would mean the definitions can be reused by ddraw, and the opengl dlls in the same way.
Wine's OpenGL DLL does not need any #defines. We actually do not do any (for now that is) GL call that is not done by the Windows application itself. So all the enums are compiled in the Windows code, not in Wine. Of course, the day we will support WGL pbuffers using GLX PBuffers, we may have the same kind of issues, but never as bad as for D3D. Lionel -- Lionel Ulmer - http://www.bbrox.org/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le Vendredi 06 Juin 2003 11:25, Lionel Ulmer a écrit :
their machines compared to the people running it. My only comment is whether d3dcore_gl.h is the right place for it, as putting it in something like \include\wine\winegl.h would mean the definitions can be reused by ddraw, and the opengl dlls in the same way.
Wine's OpenGL DLL does not need any #defines. We actually do not do any (for now that is) GL call that is not done by the Windows application itself. So all the enums are compiled in the Windows code, not in Wine.
Right, but what about winelib applications who want to use some Windows specific OpenGL extensions (fore exemple render_to_texture) ?
Of course, the day we will support WGL pbuffers using GLX PBuffers, we may have the same kind of issues, but never as bad as for D3D.
Well, i have thought to begin implement it ;)
Lionel
Raphael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE+4Mxxp7NA3AmQTU4RAn4XAJ4rpKbpbmBQQ2EMrX8IjJRz/O6jWwCfcpvu 5go2dJ7V/vDqioAFOi0jY00= =B7Oa -----END PGP SIGNATURE-----
Right, but what about winelib applications who want to use some Windows specific OpenGL extensions (fore exemple render_to_texture) ?
Well, for the moment this is not supported... And anyway, these would depend on a 'wglext.h' or 'wgl.h' (no idea how it's done in Windows) which we would create from scrach anyway as it's not present in the Linux system headers.
Well, i have thought to begin implement it ;)
Feel free to do it :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi,
again about declared/defined caps from gl headers (gl,glext,glx). For this we need an header where all defines and functions pointers are declared (as seen in d3dcore_gl.h)
I completely agree, as it means packagers dont have to worry about the levels on their machines compared to the people running it. My only comment is whether d3dcore_gl.h is the right place for it, as putting it in something like \include\wine\winegl.h would mean the definitions can be reused by ddraw, and the opengl dlls in the same way.
i only can approve but not the include\wine\winegl.h idea, as if we do so this header will be installed on user installs and this header is only needed for the wine compilation.
Jason
Raphael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE+4M0Pp7NA3AmQTU4RAqGsAJoC+Ie/y92rgrB1R8JAqXnHFJ0WmQCfS9Xl OpmB75nn0y9cZA5Gbb+SE9M= =/xbZ -----END PGP SIGNATURE-----
participants (3)
-
Ann and Jason Edmeades -
Lionel Ulmer -
Raphaël Junqueira