December 2005 - Wine-Devel - list.winehq.org

Re: DirectDraw over Direct3D

by Lionel Ulmer

> How about moving the current 2D code to WineD3D, and making DDraw running over > WineD3D in any case. Then WineD3D could decide wether to use plain X11, DGA > or OpenGL for 2D rendering. :) That basically bows down to have WineD3D completely replace the 'HAL' architecture which was introduced by the TG merge. Which is kinda an idea that I like :-) > Maybe we should have a close look at the details of such a thing. I do not > really recommend a ad-hoc attemt, as d3d7->WineD3D was nearly too much. Well, we can first stabilize D3D7 => WineD3D (which will already be quite a lot of work to first do and then polish) and then see if we move the 2D part too. And then we will need to rename it to something else ... if not merge it integrally into the X11DRV so that other DLLs (like the new Vista ones :-) ) would be able to do 3D accelerations :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/

Dec. 5, 2005

Re: DirectDraw over Direct3D

by Peter Beutner

Lionel Ulmer schrieb: > On Sun, Dec 04, 2005 at 07:27:29PM -0700, Jesse Allen wrote: >>This patch seems similar to glSDL where it wraps SDL's 2d API to >>OpenGL. The good thing about this it can provide acceleration and not >>require root like DGA. The bad thing with this idea is that it can't >>be used on older video cards or even some newer ones that lack proper >>direct rendering. > > > The problem is not direct rendering, it's more 'basic' OpenGL acceleration. > > >>Am I correct that even when just doing depth >>conversions, without direct rendering it will still be slow? > > > If you have accelerated OpenGL rendering but without direct access, I think > that it should still be faster than the current method (as you would 1) move > less data over the GPU bus and 2) do less CPU computation on a big amount of > data). Isn't indirect rendering always unaccelerated, i.e. done in software?

Dec. 5, 2005

Re: wglGetPixelFormatAttribivARB unexpected RenderType(100)

by Raphael

On Monday 05 December 2005 19:36, Toan T Nguyen wrote: > Thanks very much. It works. There's a small probelm worth mentioning > however: Q2E requires 32 color bits, 24bits depth, 8bits stencils. The > ATI binary driver supports 24bits only. In wine-0.9.2, somehow > wglGetPixelFormat returns 32 color bits but the current patch returns > 24 only. I easily modified q2e to accept both 24bits and 32bits in > Linux. Other programs might not be happy. WGL_COLOR_BITS_ARB cannot be 32 (was a bug i have corrected recently) see http://www.nvidia.com/dev_content/nvopenglspecs/WGL_ARB_pixel_format.txt WGL_COLOR_BITS_ARB * The number of color bitplanes in each color buffer. For RGBA * pixel types, it is the size of the color buffer, excluding the * alpha bitplanes. For color-index pixels, it is the size of the * color index buffer. So for 32 bits FBConfig, it should be 24 (8 bits per RGB channels) + 8 for Alpha channel If Q2E expect 32 bits for WGL_COLOR_BITS_ARB its a bug :) And 24 bits limitation is a X limitation (X display cannot support alpha-channel) not an ATI limitation. Anyway, 24 bits displays usually support 32 bits using GLX :) > Toan Regards, Raphael

Dec. 5, 2005

Re: DirectDraw over Direct3D

by Stefan Dösinger

Am Montag, 5. Dezember 2005 21:10 schrieb Lionel Ulmer: > On Mon, Dec 05, 2005 at 08:17:38AM +0100, Stefan Dösinger wrote: > > I hope I can come up with a patch for testing this week, then we can have > > a look ;) > > I think that to merge Roderick's and your patch, the best would be to > directly hook WineD3D even at the 2D level and not have DDraw hook DDraw's > D3D which then goes into WineD3D. I thought of the same thing, as DDraw -> D3D7 -> WineD3D -> OpenGL is a quite long chain. I abadonned it as too much work at first, but it's surely worth considering. > This way we would have an unified DDraw. > > Of course, then the problem remains of what to do with older cards :-) How about moving the current 2D code to WineD3D, and making DDraw running over WineD3D in any case. Then WineD3D could decide wether to use plain X11, DGA or OpenGL for 2D rendering. :) Maybe we should have a close look at the details of such a thing. I do not really recommend a ad-hoc attemt, as d3d7->WineD3D was nearly too much. Stefan

Dec. 5, 2005

Re: Implement Old Names Option

by Robert Shearman

Dimi Paun wrote: >From: "Robert Shearman" <rob(a)codeweavers.com> > > >>Implement '-o' option. This is equivalent to MIDLs '/oldnames' option. >> >> > >Not a good choice, '-o' is used for output typically. >How about --oldnames? > I've forwarded you message on to Eric Kohl. I'll let him comment on it since he is the one being most active on widl these days. In the future could you CC him on any comments on the patches I've sent on his behalf. -- Rob Shearman

Dec. 5, 2005

Re: Missing WGL function declarations in wingdi.h

by Lionel Ulmer

On Tue, Nov 29, 2005 at 05:39:13AM +0000, Aric Cyr wrote: > Well I am only working on removing glX calls from wined3d and replacing them > with wgl calls so I'd rather not impact the GL code if possible. At first I > didn't quite understand your question, so let me see if I got this right. > Currently wined3d directly links to libGL.so (via EXTRALIBS in the Makefile). > So if I wanted to use opengl32.dll (for wgl), and I added it to IMPORTS it would > override the libGL.so calls? Well, this is the big question. I think we should ask Alexandre what happens in the Wine build system if a symbol is exported both by a Win32 DLL (here OpenGL32.DLL) and a Linux ELF DLL (here libGL.so) and a Wine DLL requires to be linked to both. In my opinion I would have both GLX and WGL code co-exist... I really fear that to make some game happy in WGL, we would 'cheat' and report some stuff which is not exactly aligned with what the GPU really supports. Which means that WineD3D will not be able to trust what WGL reports as it may be tweaked. Finally, if we get some 'GLX-only' extensions (maybe threading related - one can always hope :-) ), how could one support that using WGL ? Add our own fake extensions to WGL and 'thunk them' ? Lionel -- Lionel Ulmer - http://www.bbrox.org/

Dec. 5, 2005

Re: DirectDraw over Direct3D

by Lionel Ulmer

On Sun, Dec 04, 2005 at 07:27:29PM -0700, Jesse Allen wrote: > Is Starcraft really that slow? How does this compare with using DGA? Nothing can beat DGA (actually DGA2 as you would need depth change to go to 8 bit colours to run StarCraft) in raw speed as it is the method which does copy the less memory over. > This patch seems similar to glSDL where it wraps SDL's 2d API to > OpenGL. The good thing about this it can provide acceleration and not > require root like DGA. The bad thing with this idea is that it can't > be used on older video cards or even some newer ones that lack proper > direct rendering. The problem is not direct rendering, it's more 'basic' OpenGL acceleration. > Am I correct that even when just doing depth > conversions, without direct rendering it will still be slow? If you have accelerated OpenGL rendering but without direct access, I think that it should still be faster than the current method (as you would 1) move less data over the GPU bus and 2) do less CPU computation on a big amount of data). Lionel -- Lionel Ulmer - http://www.bbrox.org/

Dec. 5, 2005

Re: DirectDraw over Direct3D

by Lionel Ulmer

On Mon, Dec 05, 2005 at 08:17:38AM +0100, Stefan Dösinger wrote: > I hope I can come up with a patch for testing this week, then we can have a > look ;) I think that to merge Roderick's and your patch, the best would be to directly hook WineD3D even at the 2D level and not have DDraw hook DDraw's D3D which then goes into WineD3D. This way we would have an unified DDraw. Of course, then the problem remains of what to do with older cards :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/

Dec. 5, 2005

Re: advapi32: RegCreateKeyEx fix.

by James Hawkins

On 12/5/05, Rein Klazes <wijn(a)wanadoo.nl> wrote: > > On Win9x,ME RegCreateKeyEx ignores the backslash character if the subkey > begins with one. With a regression test. > Note that I'm not against this being committed, but another test you could add is for the comment, /* win9x,ME ignores one (and only one) beginning backslash */ the (and only one) part. You could use the same test as the one you added, but with two backslashes prepended and see if it fails. I haven't tested this myself (I only have > NT) but I'm curious if only one beginning backslash is ignored. -- James Hawkins

Dec. 5, 2005

Re: wglGetPixelFormatAttribivARB unexpected RenderType(100)

by Toan T Nguyen

Thanks very much. It works. There's a small probelm worth mentioning however: Q2E requires 32 color bits, 24bits depth, 8bits stencils. The ATI binary driver supports 24bits only. In wine-0.9.2, somehow wglGetPixelFormat returns 32 color bits but the current patch returns 24 only. I easily modified q2e to accept both 24bits and 32bits in Linux. Other programs might not be happy. Toan On 12/5/05, Raphael <fenix(a)club-internet.fr> wrote: > On Monday 05 December 2005 04:41, Toan T Nguyen wrote: > > Here they are. > > > > On 12/4/05, Raphael <fenix(a)club-internet.fr> wrote: > > > On Saturday 03 December 2005 09:20, Toan T Nguyen wrote: > > > > FYI, here is the code in question: > > > > > > > > http://cvs.sourceforge.net/viewcvs.py/q2e/q2e/source/win32/glw_win.c?re > > > >v=1. 13&view=auto > > > > > > > > The function where pixelFormat is initialized is GLW_ChoosePixelFormat. > > > > > > > > Toan > > > > > > Hi, > > > > > > behavior seems strange to me > > > > > > can you provide me output of gxlinfo > > > and output of (using patch) > > > WINEDEBUG="+opengl" q2.... > > > > > > Thx > > > > > > Regards, > > > Raphael > > Thx > > Can you retry with this patch ? > > Thx > > Regards, > Raphael > > >

Dec. 5, 2005