August 2004 - Wine-Devel - list.winehq.org

msvideo 16bit codec question

by Mike Hearn

Hey Mike, I've been trying to make Maxis Marble Drop work in my non-connected spare time in the evenings, and the intro video doesn't render right. Examination of the code revealed that it had been patched to output pixel blocks in the right direction for the 8 bit decoder but the 16 bit decoder hadn't been modified. So, I copied across the changes to the 16 bit decoder as well, unfortunately it doesn't work. Something is going wrong, and the codec trashes the heap arena, so I'm guessing there's something in the maths that is different for 16 bit videos than 8 bit. Got any ideas? thanks -mike

Aug. 7, 2004

Re: DOOM 3 misses some opengl32 wgl* and Cg functions

by Mike Hearn

Have I missed something here - I thought there was a native version of DOOM 3 for Linux?

Aug. 7, 2004

Re: wine debugger

by Mike Hearn

Unfortunately since to the move to the dbghelp DLL winedbg has been rather unstable. One thing you can do is attach to the debugger with regular gdb, and when it crashes see if you can figure out what's going wrong. On Sun, 01 Aug 2004 17:10:42 +0200, Chipzz wrote: > Hi all, > > for some reason, the wine debugger just doesn't seem to work for me. > > wine: Unhandled exception (thread 000f), starting debugger... > fixme:console:SetConsoleCtrlHandler (0x405ae990,1) - no error checking or testing yet > WineDbg starting on pid 0xe > In 32 bit mode. > Wine-dbg>bt > Backtrace: > =>1 0x40107b08 __read+0x28 in libc.so.6 (0x40032c54) > 2 0x401cc022 > Exception c0000005 > > The backtrace it shows appears to be from the debugger itself, not from > the program? Or am I wrong in assuming this? I am getting this same > backtrace for each and every program... > Also, the ctrl-c key doesn't work as advertised (just does nothing). > > Wine is wine cvs from 07/31, gdb is 6.1-3 from debian unstable. > > Anyone got some pointers? > > kr, > > Chipzz AKA > Jan Van Buggenhout

Aug. 7, 2004

Re: DOOM 3 misses some opengl32 wgl* and Cg functions

by Shachar Shemesh

Ove Kaaven wrote: >>BTW, DOOM 3 crashes at program start in Cedega, you made it better! >> >> > >here's a howto from someone who did make it start with Cedega CVS: > >http://www.linux-militia.net/howtos/doom3/doom3.html > >Since there's some level of pbuffer support in Cedega, it might provide >better graphics. > > http://linux.israel.net/linuxgames/modules.php?name=News&file=article&sid=55 Translated into English: War games: Yes, it's true, Wine can run the new DOOM3 Several days ago I installed Mandrake 9.2 and was very impressed with Wine. This little program really does wonders. So i said to myself "it can run small Windows apps, but there is no way it can run Doom 3". I did this: cd /mnt/win_f/Doom3 and wrote "wine Doom3.exe", and what did my eyes see? Yes, it is Doom3 running on my computer!!! And with pretty nice graphics Linux should not be ashamed of, to boost! Only one little detail - the in games movies won't work. It probably has something to do with Windows' Direct X. So there you have it. I hope that it will work for you as it has for me!!!! There is also a screen shot there. So, if you want me to relay any questions to the user regarding how he did it? :-) -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/

Aug. 7, 2004

Re: DOOM 3 misses some opengl32 wgl* and Cg functions

by Ove Kaaven

fre, 06.08.2004 kl. 23.58 skrev Lionel Ulmer: > > Couldn't find proc address for: wglSwapIntervalEXT > > I do not know any equivalent GLX extension for this. GLX_SGI_swap_control is almost equivalent, it just doesn't have a query function. It's probably not critical functionality though. > > Couldn't find proc address for: wglBindTexImageARB > > Couldn't find proc address for: wglReleaseTexImageARB > > Would need to study what these are for and if there is an equivalent GLX > extension. Sounds like WGL_ARB_render_texture. No GLX equivalent yet. It's possible to fall back to ordinary glCopyTexImage stuff, which I suspect the game should be smart enough to do if it can't find these. > > GL_ARB_texture_non_power_of_two not found > > What kind of NVIDIA card do you have ? Wine should report all extensions > reported by the Linux card to the Windows application. nvidia just doesn't seem to support this on the cards we have here either. They just have GL_NV_texture_rectangle. The game could probably fall back to this too if ARB_texture_non_power_of_two doesn't exist. > > Almost all computer terminals in the game show static black & white noise > > (instead of some animated computer screen image). > > I suppose this is where NP2 textures are used. No idea why the fallback dose > not work. Or perhaps where pbuffers are used. And since the original poster said: > BTW, DOOM 3 crashes at program start in Cedega, you made it better! here's a howto from someone who did make it start with Cedega CVS: http://www.linux-militia.net/howtos/doom3/doom3.html Since there's some level of pbuffer support in Cedega, it might provide better graphics.

Aug. 7, 2004

Re: DOOM 3 misses some opengl32 wgl* and Cg functions

by Lionel Ulmer

> Couldn't find proc address for: wglSwapIntervalEXT I do not know any equivalent GLX extension for this. > Couldn't find proc address for: wglGetPixelFormatAttribivARB > Couldn't find proc address for: wglGetPixelFormatAttribfvARB > Couldn't find proc address for: wglChoosePixelFormatARB > Couldn't find proc address for: wglCreatePbufferARB > Couldn't find proc address for: wglGetPbufferDCARB > Couldn't find proc address for: wglReleasePbufferDCARB > Couldn't find proc address for: wglDestroyPbufferARB > Couldn't find proc address for: wglQueryPbufferARB > Couldn't find proc address for: wglSetPbufferAttribARB This is part of one of my 'todo' project: adding support for PBuffers in the WineHQ tree (I once started to study both the GLX and WGL extension set to see how it could be done). Now that I know one 'high profile' application that needs them, maybe it will motivate me more :-) > Couldn't find proc address for: wglBindTexImageARB > Couldn't find proc address for: wglReleaseTexImageARB Would need to study what these are for and if there is an equivalent GLX extension. > GL_ARB_texture_non_power_of_two not found What kind of NVIDIA card do you have ? Wine should report all extensions reported by the Linux card to the Windows application. This means that if your card supports NP2 textures in Linux it should also in Windows. An output of the 'glxinfo' would be nice (see below). > GL_ATI_fragment_shader not found (this is expected, I have a nvidia card) > Cg not available. I would need to study if 'native' Cg works in Wine. > Almost all computer terminals in the game show static black & white noise > (instead of some animated computer screen image). I suppose this is where NP2 textures are used. No idea why the fallback dose not work. > I suspect, that this has something to do with the missing 'Cg' support in > Wine (DOOM3 cannot find cg.dll & cgGL.dll). Did you try to install the native versions using Wine (I have no idea how NVIDIA packages the Cg libraries though) ? Anyway, it would be nice to have a Bugzilla bug-report to track this (at least as long as the demo is not out so that I could debug it myself :-) ). What would be needed is the output of 'glxinfo' as said before and a +opengl log of the application (the terminal problem will be hard to track this way though). Lionel -- Lionel Ulmer - http://www.bbrox.org/

Aug. 6, 2004

DOOM 3 misses some opengl32 wgl* and Cg functions

by Dr. Uwe Girlich

Hello all! I just tested out DOOM 3 (no-cd-cracked version) with the current Wine (CVS from 1 hour ago) and found the following problems on the game console: Couldn't find proc address for: wglSwapIntervalEXT Couldn't find proc address for: wglGetPixelFormatAttribivARB Couldn't find proc address for: wglGetPixelFormatAttribfvARB Couldn't find proc address for: wglChoosePixelFormatARB Couldn't find proc address for: wglCreatePbufferARB Couldn't find proc address for: wglGetPbufferDCARB Couldn't find proc address for: wglReleasePbufferDCARB Couldn't find proc address for: wglDestroyPbufferARB Couldn't find proc address for: wglQueryPbufferARB Couldn't find proc address for: wglBindTexImageARB Couldn't find proc address for: wglReleaseTexImageARB Couldn't find proc address for: wglSetPbufferAttribARB GL_ARB_texture_non_power_of_two not found GL_ATI_fragment_shader not found (this is expected, I have a nvidia card) Cg not available. Are these wgl* function difficult to implement? Almost all computer terminals in the game show static black & white noise (instead of some animated computer screen image). I suspect, that this has something to do with the missing 'Cg' support in Wine (DOOM3 cannot find cg.dll & cgGL.dll). On the other hand, the rendering paths (r_renderer nv10, nv20, arb, and arb2) are all more or less working (besides the noise and the too bright lighting in nv10). BTW, DOOM 3 crashes at program start in Cedega, you made it better! Bye, Uwe

Aug. 6, 2004

Re: winedos: TSR (was MCB implementation)

by Alexandre Julliard

markus.amsler(a)oribi.org writes: > Now, what should happen, if you start a TSR programm in a win32 shell (like > wcmd,Reactos cmd.exe or Windows cmd.exe)? Spawn FreeCOM, implement TSR somehow > in win32 (shell or ntdll) or no TSR support in win32 shells? No, TSR support doesn't make sense in Win32. What do you need it for? -- Alexandre Julliard julliard(a)winehq.org

Aug. 6, 2004

Re: Do more tests in non-interactive mode (resubmit)

by Alexandre Julliard

Francois Gouget <fgouget(a)codeweavers.com> writes: > This way we exercise almost as much of the API as in interactive mode > without disturbing users, and the tests still run fast. The slowest one > is the winmm test which takes 16 seconds on my machine which supports > all the tested sound formats (but has only one sound card). Given that > winetest's timeout is two minutes this gives a wide margin. The capture test takes about 80 seconds here with the ALSA driver, which is a bit long. It also fails with the OSS driver: capture.c:128: Test failed: WaitForSingleObject failed for header capture.c:129: Test failed: WHDR_DONE not set in frag.dwFlags capture.c:130: Test failed: frag.dwBytesRecorded=512, should be 800 capture.c:128: Test failed: WaitForSingleObject failed for header capture.c:129: Test failed: WHDR_DONE not set in frag.dwFlags capture.c:130: Test failed: frag.dwBytesRecorded=512, should be 800 capture.c:128: Test failed: WaitForSingleObject failed for header capture.c:129: Test failed: WHDR_DONE not set in frag.dwFlags capture.c:130: Test failed: frag.dwBytesRecorded=512, should be 800 capture.c:128: Test failed: WaitForSingleObject failed for header capture.c:129: Test failed: WHDR_DONE not set in frag.dwFlags capture.c:130: Test failed: frag.dwBytesRecorded=1024, should be 1600 capture.c:128: Test failed: WaitForSingleObject failed for header capture.c:129: Test failed: WHDR_DONE not set in frag.dwFlags etc. Also the wave test makes a lot of noise here, both with ALSA and OSS drivers. -- Alexandre Julliard julliard(a)winehq.org

Aug. 6, 2004

FW: FW: WM_NEXTDLGCTL changes the default button ID and does not rest ore default control identifier

by Krishna Murthy

Alexandre, I am resending this patch. There exists a defect 2388. Also confirmed that it fixes one of the Katia's defect found. Please let us know about your thoughts. Thanks, Krishna -----Original Message----- From: Krishna Murthy Sent: Tuesday, June 22, 2004 2:56 PM To: 'Alexandre Julliard'; Krishna Murthy Cc: wine-devel(a)winehq.org Subject: RE: FW: WM_NEXTDLGCTL changes the default button ID and does not rest ore default control identifier Alexandre, Please find attached modified patch. The method DEFDLG_SetDefButton() now accepts the BOOL bSetDefID parameter to adapt for both DM_SETDEFID and WM_NEXTDLGCTL. Thanks, Krishna -----Original Message----- From: Alexandre Julliard [mailto:julliard(a)winehq.org] Sent: Friday, June 18, 2004 10:30 AM To: Krishna Murthy Cc: wine-devel(a)winehq.org Subject: Re: FW: WM_NEXTDLGCTL changes the default button ID and does not rest ore default control identifier Krishna Murthy <Krishna.Murthy(a)guptaworldwide.com> writes: > No, it is required. The DEFDLG_SetDefButton() is also called from > message DM_SETDEFID. In this case idResult should set to the default > button ID passed. And the current logic of DEFDLG_SetDefButton() does > what is required for DM_SETDEFID. Well, of course you'd need to adapt the DM_SETDEFID handling to the change. I think that's better than sending duplicate messages. -- Alexandre Julliard julliard(a)winehq.org

Aug. 6, 2004