- Wine-Devel - list.winehq.org

Directx 9
by Ann and Jason Edmeades Jan. 8, 2005

Jan. 8, 2005

Hiya, FYI I've spent the last couple of months putting together a directx 8 level support into wined3d and calling it from d3d9 such that I can also change d3d8 easily to use the new code. This is mostly complete other than the texture support and the shader support plus moving some functions / stubs into the common code. If you have any directx 8/9 questions feel free to email me directly, put questions on wine-devel or perhaps even the wined3d (very, very quiet - http://www.bbrox.org/mailman/listinfo/wine-d3d) mailing list (Lionel's). You really are welcome, and I'll try to answer any questions I can. I wouldn't spent too much time trying to move existing functionality between d3d8 to wined3d unless you really want to as I am trying to get this move completed asap. I really don't want to discourage any d3d assistance, its just I know where I am and what I have left to do. I have generally been doing a patch and getting it committed both due to lack to time, but also to avoid potential rework of multiple patches. I really hope to get most of the non-shader support done quite quickly once the 20 patch goes in (Christmas and FarCry got in the way, and I had some teething problems with the render target support which delayed it!). Next will be the texture support and that should be quick as it is relatively trivial to move across. >As soon as I'm happy with how wine's and directX work >I can stop duplicating what you've done and start >moving onto a more co-operative development... Sounds good - one thing wine has suffered from is a lack of people doing the directx support! Note that Raphael (copied on this note) has some outstanding patches he has put off while I do the move to support hardware vertex buffers so the drawstridedslow case is driven less frequently, but that's the only outstanding work I know about. > or moving DirectX8 over to using WineD3d. I have a version locally where I have changed d3d8 up to about patch 13. I can send it to you if it helps - Unfortunately I think the swap to wined3d will have to be one big patch, I don't think there is a way to move d3d8 over slowly, as you have to move the state block code in one go, the resource8 subclasses in one go etc... >I've merged all the creation surface code into a >single createSurface function that is called with >different parameters/flags to create a backbuffer, >PlainOffscreenSurface or rendertarget etc... Sounds fine - The problem I had with the latest patch was purely being able to add the support for getfrontbuffer etc which needed to return d3d8 or d3d9 objects, but the initial crates being done in the wined3d layer. A single callback sounds useful, as I know I'll have to do something similar for stencildepth surfaces (nothing else is created purely from the wined3d layer, so I don't think others need the same). FWIW I do the same, ie find demos on the web with source code, and then try to get them working. That's how most of the d3d8 support came about as it's a lot easier making a demo work than finding why there's a small amount of corruption for a particular game. I wouldn't claim to be a directx nor opengl expert - its all been a learning experience as I go! Maybe we should collect some useful test program links! If there's any d3d8/9 programmers out there, there's definitely a fun project to do to produce test programs for wine. They cant be automated (I think!) but it would be useful to be able to visually see the effect differences of all the render states, the texture states, prove the shader support works in both hw and sw vertex and pixel code etc etc. Jason

1 0

Re: [LostWages] Resurrection of the AddRef and Release code cleanup.
by James Hawkins Jan. 8, 2005

Jan. 8, 2005

On Sat, 08 Jan 2005 16:00:38 +0100, Paul Vriens <Paul.Vriens(a)xs4all.nl> wrote: > Hi, > > this Project was apparently not finished. > > Changelog: > make the AddRef and Release code cleanup active again. > > Cheers, > > Paul Vriens > It would be nice to add back in the two other workers (me and Joris). -- James Hawkins

1 0

Re: [dx9-20] RenderTarget support
by Oliver Stieber Jan. 8, 2005

Jan. 8, 2005

--- Ann and Jason Edmeades <us(a)the-edmeades.demon.co.uk> wrote: > This clears out the next blocking part of the d3d9 / > wined3d support and has > been a real pain to implement. I think I've got it > right now, and it adds > support for render targets but more importantly the > beginnings of a front > and back buffer which lots of the code relied upon. > > Unfortunately I couldn't get this next step any > smaller than the patch > attached.... > > Major areas still to go - textures and pixel / > vertex shader support. I'm > moving onto the textures next... > > Changelog > > Add render target support, and ensure there is a > front and back buffer > created during device creation > > Jason > > Hi, I've just done more-or-less exactly the same this weekend with a couple of differences. I've merged all the creation surface code into a single createSurface function that is called with different parameters/flags to create a backbuffer, PlainOffscreenSurface or rendertarget etc... This should mean that you only require one call-back function for CreateDevice in WineD3D. I'll merge your patch with what I've got and see how it goes. As soon as I'm happy with how wine's and directX work I can stop duplicating what you've done and start moving onto a more co-operative development, or moving DirectX8 over to using WineD3d. So far I can run Pirates! and a few of the demos from http://www.codesampler.com/dx9src.htm, but without textures. Pirates uses DirectX 9c but doesn't do anything too fancy and runs without crashing so it seems good for testing. Many of the demos at http://www.codesampler.com/dx9src.htm have OpenGL versions and since I don't know OpenGL or DirectX (but can hack a good Dos demo) it seemed a good place to start. ___________________________________________________________ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com

1 0

directX 9.
by Oliver Stieber Jan. 8, 2005

Jan. 8, 2005

Hi, I've been having a look at DirectX 9 over the weekend as a bit of a learning excersize. So far I've managed to get enough implemented in d3d9 to run Pirates! [without textured polygons] and have stated moving everything over to wined3d so that the textures will work. Unfortunatly I've become stuck assigning a DirectX 9 parent to a surface created in wined3d. Can anybody help? ___________________________________________________________ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com

1 0

Re: Native unix style paths in wine common dialogs
by Dimitrie O. Paun Jan. 8, 2005

Jan. 8, 2005

On Tue, Jan 04, 2005 at 11:22:00AM -0500, Dan Notestein wrote: > This patch allows winelib to be conditionally compiled with > USE_NATIVE_UNIX_PATHS macro. Enabling this will cause > the common dialogs to display using unix paths instead of drive > letters. This would be much better as a registry setting, not a compile time option. -- Dimi.

3 5

Re: windows/clipboard.c: Get rid of W->A calls
by Dmitry Timoshkov Jan. 8, 2005

Jan. 8, 2005

"Jacek Caban" <jack(a)itma.pwr.wroc.pl> wrote: > @@ -310,15 +335,24 @@ static void intern_atoms(void) > names = HeapAlloc( GetProcessHeap(), 0, count * sizeof(*names) ); > atoms = HeapAlloc( GetProcessHeap(), 0, count * sizeof(*atoms) ); > > - for (format = ClipFormats, i = 0; format; format = format->NextFormat) > - if (!format->drvData) names[i++] = format->Name; > + for (format = ClipFormats, i = 0; format; format = format->NextFormat) { > + if (!format->drvData) { > + len = WideCharToMultiByte(CP_ACP, 0, format->Name, -1, NULL, -1, 0, 0); > + names[i] = HeapAlloc(GetProcessHeap(), 0, len*sizeof(WCHAR)); > + WideCharToMultiByte(CP_ACP, 0, format->Name, -1, names[i++], len, 0, 0); You have to use CP_UNIXCP to convert unicode strings in order to pass them to the X11/unix system (here and everywhere else). -- Dmitry.

1 0

Re: windows/winproc.c: Get rid of HEAP_strdupWtoA calls
by Dmitry Timoshkov Jan. 8, 2005

Jan. 8, 2005

"Jacek Caban" <jack(a)itma.pwr.wroc.pl> wrote: > @@ -1010,9 +1009,15 @@ static INT WINPROC_MapMsg32WTo32A( HWND > case LB_DIR: > case LB_ADDFILE: > case EM_REPLACESEL: > - if(!*plparam) return 0; > - *plparam = (LPARAM)HEAP_strdupWtoA( GetProcessHeap(), 0, (LPCWSTR)*plparam ); > - return (*plparam ? 1 : -1); > + if(*plparam) { > + LPSTR buf; > + int len = WideCharToMultiByte(CP_ACP, 0, (LPWSTR)*plparam, -1, NULL, 0, 0, 0); > + buf = HeapAlloc(GetProcessHeap(), 0, len*sizeof(CHAR)); > + WideCharToMultiByte(CP_ACP, 0, (LPWSTR)*plparam, -1, buf, len, 0, 0); > + *plparam = (LPARAM)buf; > + return 1; > + } > + return 0; It would be helpful to keep the test in the case of a buffer allocation failure here and everywhere else (and perhaps add the missing tests). -- Dmitry.

1 0

Re: USER32: GetScrollBarInfo
by Alexandre Julliard Jan. 8, 2005

Jan. 8, 2005

Vitaly Lipatov <lav(a)etersoft.ru> writes: > --- scroll.c 8 Dec 2004 18:06:15 -0000 1.3 > +++ dlls/user/scroll.c 4 Jan 2005 14:27:08 -0000 > @@ -27,7 +27,7 @@ > * the specification mentioned above. > * If you discover missing features, or bugs, please note them below. > * > - * TODO: > + * TODO: needs check follow realized functions: > * - GetScrollBarInfo > * - SBM_GETSCROLLBARINFO > * - SCROLLBARINFO > @@ -1424,10 +1461,12 @@ > case SBM_GETSCROLLINFO: > return SCROLL_GetScrollInfo(hwnd, SB_CTL, (SCROLLINFO *)lParam); > > + case SBM_GETSCROLLBARINFO: > + return GetScrollBarInfo(hwnd, SB_CTL, (SCROLLBARINFO *)lParam); You have to do that the other way around, GetScrollBarInfo should send a SBM_GETSCROLLBARINFO message, similar to what GetScrollInfo does. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: wine/ include/Makefile.in dlls/user/user32.spe ... (CVS compile fix)
by Mike McCormack Jan. 7, 2005

Jan. 7, 2005

This patch adds GetScrollBarInfo to user32.spec, but adds no implementation... Here's a temporary fix for those wondering why the CVS won't compile until the rest of Vitaly's scrollbar patch is committed. Mike Alexandre Julliard wrote: > ChangeSet ID: 15265 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 2005/01/07 11:15:30 > > Modified files: > include : Makefile.in > dlls/user : user32.spec misc.c > Added files: > include : winnls32.h > > Log message: > Diego Pettenò <flameeyes(a)users.berlios.de> > Added stub implementation for WINNLS* functions. > > Patch: http://cvs.winehq.org/patch.py?id=15265 > > Old revision New revision Changes Path > 1.151 1.152 +1 -0 wine/include/Makefile.in > 1.92 1.93 +4 -4 wine/dlls/user/user32.spec > 1.19 1.20 +34 -3 wine/dlls/user/misc.c > Added 1.1 +0 -0 wine/include/winnls32.h ? dlls/user/timer.c ? dlls/user/tests/child.c ? dlls/user/tests/child.ok ? dlls/user/tests/timer.c ? dlls/user/tests/timer.ok Index: dlls/user/painting.c =================================================================== RCS file: /home/wine/wine/dlls/user/painting.c,v retrieving revision 1.16 diff -u -r1.16 painting.c --- dlls/user/painting.c 4 Jan 2005 12:11:09 -0000 1.16 +++ dlls/user/painting.c 8 Jan 2005 02:53:48 -0000 @@ -570,3 +570,10 @@ } return ret; } + +BOOL WINAPI SetLayeredWindowAttributes(HWND hwnd, COLORREF crKey, + BYTE bAlpha, DWORD dwFlags) +{ + FIXME("%p %08lx %02x %08lx\n", hwnd, crKey, bAlpha, dwFlags); + return TRUE; +} Index: dlls/user/user32.spec =================================================================== RCS file: /home/wine/wine/dlls/user/user32.spec,v retrieving revision 1.93 diff -u -r1.93 user32.spec --- dlls/user/user32.spec 7 Jan 2005 17:15:30 -0000 1.93 +++ dlls/user/user32.spec 8 Jan 2005 02:53:49 -0000 @@ -294,7 +294,7 @@ @ stdcall GetPropA(long str) @ stdcall GetPropW(long wstr) @ stdcall GetQueueStatus(long) -@ stdcall GetScrollBarInfo(long long ptr) +#@ stdcall GetScrollBarInfo(long long ptr) @ stdcall GetScrollInfo(long long ptr) @ stdcall GetScrollPos(long long) @ stdcall GetScrollRange(long long ptr ptr) @@ -521,6 +521,7 @@ @ stdcall SetInternalWindowPos(long long ptr ptr) @ stdcall SetKeyboardState(ptr) @ stdcall SetLastErrorEx(long long) +@ stdcall SetLayeredWindowAttributes(long long long long) @ stdcall SetLogonNotifyWindow(long long) @ stdcall SetMenu(long long) @ stdcall SetMenuContextHelpId(long long) Index: dlls/user/tests/win.c =================================================================== RCS file: /home/wine/wine/dlls/user/tests/win.c,v retrieving revision 1.39 diff -u -r1.39 win.c --- dlls/user/tests/win.c 27 Dec 2004 17:26:37 -0000 1.39 +++ dlls/user/tests/win.c 8 Jan 2005 02:53:49 -0000 @@ -2114,6 +2114,82 @@ ok( !ret, "message %04x available\n", msg.message); } +static void test_child_window() +{ + WNDCLASSA cls,child_cls; + char className[] = "parentclass"; /* To make sure className >= 0x10000 */ + char winName[] = "parent window"; + char childclassName[] = "childclass"; /* To make sure className >= 0x10000 */ + char childwinName[] = "child window"; + HWND hWnd, hChild; + HINSTANCE hInstance = GetModuleHandleA( NULL ); + + cls.style = CS_HREDRAW | CS_VREDRAW | CS_GLOBALCLASS; + cls.lpfnWndProc = DefWindowProcA; + cls.cbClsExtra = 0; + cls.cbWndExtra = 0; + cls.hInstance = 0; + cls.hIcon = LoadIconA (0, (LPSTR)IDI_APPLICATION); + cls.hCursor = LoadCursorA (0, (LPSTR)IDC_ARROW); + cls.hbrBackground = GetStockObject (WHITE_BRUSH); + cls.lpszMenuName = 0; + cls.lpszClassName = className; + + ok (RegisterClassA (&cls), "unable to register class") ; + + hWnd = CreateWindowA (className, winName, + WS_OVERLAPPEDWINDOW , + CW_USEDEFAULT, CW_USEDEFAULT, 300, 300, 0, + 0, + hInstance, 0); + + ok(hWnd != 0, "Couldn't create parent window"); + + child_cls.style = CS_HREDRAW | CS_VREDRAW | CS_GLOBALCLASS; + child_cls.lpfnWndProc = DefWindowProcA; + child_cls.cbClsExtra = 0; + child_cls.cbWndExtra = 0; + child_cls.hInstance = 0; + child_cls.hIcon = LoadIconA (0, (LPSTR)IDI_APPLICATION); + child_cls.hCursor = LoadCursorA (0, (LPSTR)IDC_ARROW); + child_cls.hbrBackground = GetStockObject (GRAY_BRUSH); + child_cls.lpszMenuName = 0; + child_cls.lpszClassName = childclassName; + + ok (RegisterClassA (&child_cls) , "unable to register child class"); + + /* NOTE: WS_POPUP should override WS_CHILD */ + + hChild = CreateWindowExA ( + 0, childclassName, childwinName, + WS_POPUP | WS_CHILD | WS_CLIPCHILDREN, + 50, 50, 50, 100, hWnd, + 0, hInstance, 0); + + ok(hChild != 0, "Couldn't create child window"); + + ok(!SetActiveWindow(hChild), + "Can activate without parent window"); + + ok(GetAncestor(hChild, GA_PARENT) == GetDesktopWindow(), + "ancestor is not the desktop window"); + + ShowWindow (hWnd, SW_SHOW); + UpdateWindow (hWnd); + + ok(SetActiveWindow(hChild) != 0, + "Can't activate window with parent active"); + + ShowWindow (hChild, SW_SHOW); + UpdateWindow (hChild); + + ok(SetActiveWindow(hChild) != 0, + "Can't activate window with parent active"); + + DestroyWindow(hChild); + DestroyWindow(hWnd); +} + static void test_mouse_input(HWND hwnd) { RECT rc; @@ -2179,6 +2255,8 @@ START_TEST(win) { + test_child_window(); + pGetAncestor = (void *)GetProcAddress( GetModuleHandleA("user32.dll"), "GetAncestor" ); pGetWindowInfo = (void *)GetProcAddress( GetModuleHandleA("user32.dll"), "GetWindowInfo" );

1 0

Re: wineloader: call wineprefixcreate with explicit WINEPREFIX
by Tobias Burnus Jan. 7, 2005

Jan. 7, 2005

Hello, Crestez Leonard wrote: > +if [ -z $WINEPREFIX ] > +then While my bash accepts this, Tru64 UNIX's POSIX shell does not. Please use "$WINEPREFIX" instead. Tobias

2 1