COD4 stopped working
So around the time that 0.9.54 came out I lost COD4 on both my desktop and laptop. In order for it to work you have to compile wine with the 3dmark patch, so I was using the git, but when that didn't work I tried 52 and 54 tarballs. Thing is I know it worked with the 52 git and with the 52 tarball it still doesn't work, I've tried reinstalling all the depends even... I've tried using a completely fresh prefix. I've tried downgrading my nvidiadrivers(169.09) to 07 and to 100.14.19 on my laptop(desktop has a 8800GT) and everything else I could think of. Below is the error log. tried versions 1.3, 1.4 and 1.5 of COD4 Desktop: gentoo 2.6.24-r1 amd64 athlon 3800 x2 8GBs DDR2-800 ram 8800GT (169.09 and 169.07) Laptop: gentoo 2.6.24 amd 64 turion 2.2GHz (think it's ML-40) 1GB ram(don't remember the specs) 7900GS (169.09, 169.07 and 100.14.19) [EMAIL PROTECTED]/.wine/COD4/drive_c/Program Files/Activision]$ WINEPREFIX=/home/system/.wine/COD4 /mnt/backup2/programs/games/wine-0.9.52/wine iw3mp.exe ALSA lib pcm.c:6617:(snd_pcm_slave_conf) unknown format unchanged ALSA lib pcm.c:6617:(snd_pcm_slave_conf) unknown format unchanged fixme:d3d:IWineD3DImpl_FillGLCaps OpenGL implementation supports 32 vertex samplers and 32 total samplers fixme:d3d:IWineD3DImpl_FillGLCaps Expected vertex samplers + MAX_TEXTURES(=8) combined_samplers fixme:win:EnumDisplayDevicesW ((null),0,0x32f91c,0x), stub! fixme:d3d:IWineD3DImpl_CheckDeviceMultiSampleType Quality levels unsupported at present fixme:d3d:CreateContext GL_INVALID_OPERATION (0x502) from glTexEnvi(GL_TEXTURE_SHADER_NV, GL_PREVIOUS_TEXTURE_INPUT_NV, ... @ context.c / 384 fixme:d3d:CreateContext GL_INVALID_OPERATION (0x502) from glTexEnvi(GL_TEXTURE_SHADER_NV, GL_PREVIOUS_TEXTURE_INPUT_NV, ... @ context.c / 384 fixme:d3d:CreateContext GL_INVALID_OPERATION (0x502) from glTexEnvi(GL_TEXTURE_SHADER_NV, GL_PREVIOUS_TEXTURE_INPUT_NV, ... @ context.c / 384 fixme:d3d:CreateContext GL_INVALID_OPERATION (0x502) from glTexEnvi(GL_TEXTURE_SHADER_NV, GL_PREVIOUS_TEXTURE_INPUT_NV, ... @ context.c / 384 fixme:d3d:CreateContext GL_INVALID_OPERATION (0x502) from glTexEnvi(GL_TEXTURE_SHADER_NV, GL_PREVIOUS_TEXTURE_INPUT_NV, ... @ context.c / 384 fixme:d3d:CreateContext GL_INVALID_OPERATION (0x502) from glTexEnvi(GL_TEXTURE_SHADER_NV, GL_PREVIOUS_TEXTURE_INPUT_NV, ... @ context.c / 384 fixme:d3d:CreateContext GL_INVALID_OPERATION (0x502) from glTexEnvi(GL_TEXTURE_SHADER_NV, GL_PREVIOUS_TEXTURE_INPUT_NV, ... @ context.c / 384 fixme:d3d:CreateContext GL_INVALID_OPERATION (0x502) from glTexEnvi(GL_TEXTURE_SHADER_NV, GL_PREVIOUS_TEXTURE_INPUT_NV, ... @ context.c / 384 fixme:d3d:IWineD3DVolumeImpl_LockBox (0x17fd3aa8) : pBox=(nil) stub fixme:d3d_surface:flush_to_framebuffer_drawpixels GL_INVALID_VALUE (0x501) from glDrawPixels @ surface.c / 1088 fixme:d3d:state_separateblend (WINED3DRS_SEPARATEALPHABLENDENABLE,1) not yet implemented fixme:d3d:tex_bumpenvmat GL_INVALID_OPERATION (0x502) from glTexEnvfv(GL_TEXTURE_SHADER_NV, GL_OFFSET_TEXTURE_MATRIX_NV, mat) @ state.c / 2531 fixme:d3d:tex_bumpenvmat GL_INVALID_OPERATION (0x502) from glTexEnvfv(GL_TEXTURE_SHADER_NV, GL_OFFSET_TEXTURE_MATRIX_NV, mat) @ state.c / 2531 fixme:d3d:tex_bumpenvmat GL_INVALID_OPERATION (0x502) from glTexEnvfv(GL_TEXTURE_SHADER_NV, GL_OFFSET_TEXTURE_MATRIX_NV, mat) @ state.c / 2531 fixme:d3d:tex_bumpenvmat GL_INVALID_OPERATION (0x502) from glTexEnvfv(GL_TEXTURE_SHADER_NV, GL_OFFSET_TEXTURE_MATRIX_NV, mat) @ state.c / 2531 fixme:d3d:CreateContext GL_INVALID_OPERATION (0x502) from glTexEnvi(GL_TEXTURE_SHADER_NV, GL_PREVIOUS_TEXTURE_INPUT_NV, ... @ context.c / 384 fixme:d3d:CreateContext GL_INVALID_OPERATION (0x502) from glTexEnvi(GL_TEXTURE_SHADER_NV, GL_PREVIOUS_TEXTURE_INPUT_NV, ... @ context.c / 384 fixme:d3d:CreateContext GL_INVALID_OPERATION (0x502) from glTexEnvi(GL_TEXTURE_SHADER_NV, GL_PREVIOUS_TEXTURE_INPUT_NV, ... @ context.c / 384 fixme:d3d:CreateContext GL_INVALID_OPERATION (0x502) from glTexEnvi(GL_TEXTURE_SHADER_NV, GL_PREVIOUS_TEXTURE_INPUT_NV, ... @ context.c / 384 wine: Unhandled page fault on read access to 0x003c at address 0x4ecf76 (thread 0009), starting debugger... fixme:wave:widRecorder Recovering from XRUN! Unhandled exception: page fault on read access to 0x003c in 32-bit code (0x004ecf76). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:004ecf76 ESP:0032fd10 EBP:0032fd54 EFLAGS:00010206( - 00 - RIP1) EAX: EBX:7ed55b60 ECX:0cbb4660 EDX: ESI: EDI: Stack dump: 0x0032fd10: 0cc1b248 0032fcf4 0057ab7c 0x0032fd20: 027fac38 0046cb07 0x0032fd30: 1388 1388 0cc11e40 0050017a 0x0032fd40: 0040 7ee37b80 0032fd54 0x0032fd50: 0050036f 0032fd60 0050037d 7ee399e0 0x0032fd60: 0032ff08 00577463 0a28 0002 Backtrace: =1 0x004ecf76 in iw3mp (+0xecf76) (0x0032fd54) 2 0x0050037d in iw3mp (+0x10037d) (0x0032fd60) 3
Re: COD4 stopped working
Vitaliy Margolen wrote: Matthew Clark wrote: So around the time that 0.9.54 came out I lost COD4 on both my desktop and laptop. In order for it to work you have to compile wine with the Please don't make posts like this. Open bug in bugzilla instead. The mailing list is the bad place to track any information, especially bug related. Vitaliy. sorry about that http://bugs.winehq.org/show_bug.cgi?id=11545
Re: [press] Phoronix compares 7 versions of Wine
I want to say it said somewhere that it was a 8600 that they used... pretty sure Bryan Haskins wrote: Phoronix often uses the 8 series cards when not testing things like driver versions, we can probably assume they did use an 8 series. On Dec 9, 2007 10:54 AM, Stefan Dösinger [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Am Sonntag, 9. Dezember 2007 14:10:33 schrieb Jonathan Ernst: On dim, 2007-12-09 at 14:07 +0100, Jonathan Ernst wrote: Hello, What do you think about their tests and results ? http://www.phoronix.com/vr.php?view=11539 I guess it's linked with http://bugs.winehq.org/show_bug.cgi?id=10631 No, it doesn't look like they are hit by the 3dmark2k1 bug, which is strange. They are hit by the stencil test slowness in 3dmark2k3 though, which we resolved as a driver bug on geforce 8 cards, since we couldn't reproduce it elsewhere. I didn't find any info what card they used, so it is a bit hard to say what might be wrong. -- Cheers, Bryan
OpenGL 2.3 to 3.0
I was reading the other day about the 2.3 and 3.0 versions of the OpenGL API coming out this year( http://www.theinquirer.net/default.aspx?article=39846 ) and the first thought I had was wine and DX10. I was wondering what you guys thought about this, are you excited(as I am)? are you hesitant? Knowing OpenGL it shouldn't be hard at all to port the code over, but are there plans already or are the plans to wait till it's in our faces to worry about it? Sorry for the tangent but I was just curious to hear what you guys had to say about this.^_^ Thanks for all fish, -Matt
Re: OpenGL 2.3 to 3.0
Ah this makes perfect sense and is exactly what I was looking for, thank you for your response! My limited understanding from the article was that 2.3 was simply cleanup and putting some extensions in the official API that have been in drivers for a while just not in the official API and then 3.0 is where the real change will be, BUT that it will only activate the 3.0 functionality if it's on supporting hardware(i.e. DX10 cards). Please correct me if my understanding is incorrect and again I think we all realize this is all in the future and is just fun to talk about^_^ Thanks for all THE fish, -Matt PS Yes I am an idiot some times =P Stefan Dösinger wrote: We are waiting for the final API before deciding if we like it or not. But from what I've read so far the changes make sense. My concern is backwards compatiblity. For dx 1 to dx9 we will still need the old apis. For one part because the new api may not offer fixed function functionality, but more importantly because old cards will most likely not see any driver updates. If the interface is vastly different we'll need 2 d3d implementations, one wrapping to old gl and one for the new version. An idea would be to just leave dx1 to 9 with gl 2.0 and write dx10 only for opengl 3.0. If the new API allows it however, we want to keep the wine code unified. This could happen by simply duplicating very specific functions which are different, and then select them at creation time by choosing a different virtual function table. If we need an if condition for every opengl call we do it would be pointless to keep everything in one lib. But we need to know the final opengl 3.0 API to decide what to do.
Re: OpenGL 2.3 to 3.0
Ah, thank you for the clarification^^ Stefan Dösinger wrote: Am Dienstag, 5. Juni 2007 22:17 schrieb Matthew Clark: Ah this makes perfect sense and is exactly what I was looking for, thank you for your response! My limited understanding from the article was that 2.3 was simply cleanup and putting some extensions in the official API that have been in drivers for a while just not in the official API and then 3.0 is where the real change will be, BUT that it will only activate the 3.0 functionality if it's on supporting hardware(i.e. DX10 cards). Please correct me if my understanding is incorrect and again I think we all realize this is all in the future and is just fun to talk about^_^ They're takling more about codenames rather than 2.3 and 3.0, but I don't know the names currently. 2.3 will have all the functionality of 3.0 and be fully backwards compatible. This means you can use very old things together with the very new stuff. The drawback will be that you don't get the performance improvements of 3.0. This is somehow like d3d9. with d3d9.dll you can use the new d3d9 features, those will work on d3d9 cards only. But you can also use d3d9.dll to write an app that uses only dx7(or even earlier) level features, and those apps will run on dx7 cards - an example for that is the Source engine in hl2. 3.0 will be the complete rewrite. You'll have 3.0 only on cards that support it, and afaik you can't use the 3.0 API to program older cards(like a geforce 2 that doesn't even support shaders). This is what happened in d3d10 too. The advantage of the api cleanup is that you get rid of all the legacy stuff. The API is cleaner, drivers are simpler. The code is smaller and runs faster. If you look at wined3d you'll see that it is full of stuff to support even oldest cards(theoretically, in theory unsuccessful). Even though the state management keeps the most of the code sleeping until the app actually uses this features it makes everything more complex. A performance penalty is maybe the GL_EXTCALL stuff, which we use to be able to link against old opengl libs. Calling an address inserted by the dynamic linker at load time would be cheaper than finding a function pointer in a table and calling it.
Re: Command and Conquer 3 Demo
Alexander Nicolaysen Sørnes wrote: Not all users are experiencing the crashes, perhaps a SMP issue? may be it I do have a dual-core system
Command and Conquer 3 Demo
I just wanted to write to let all of the devs know how proud of the wine project I am. This Demo seems to work for the most part except for the movies in it don't seem to want to resize and when you are under attack the game crashes. Here is the console dump: fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=49332 primary_done=49356) fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=39800 primary_done=39824) fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=35960 primary_done=35984) fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=36008 primary_done=36032) fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=39968 primary_done=39992) fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=36128 primary_done=36152) fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=36128 primary_done=36152) fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=38072 primary_done=38076) fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=38072 primary_done=38076) fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=38072 primary_done=38076) fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=34232 primary_done=34236) fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=38072 primary_done=38096) fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=34232 primary_done=34256) fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=36152 primary_done=36176) fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=36152 primary_done=36176) fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=36152 primary_done=36176) err:dsound:DSOUND_MixOne underrun on sound buffer 0x210b10 fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=34568 primary_done=34592) wine: Unhandled page fault on read access to 0xfff7 at address 0x7efa2553 (thread 000e), starting debugger... fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=50292 primary_done=50316) fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=40784 primary_done=40808) fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=40784 primary_done=40808) fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=40784 primary_done=40808) fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=40784 primary_done=40808) fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=40784 primary_done=40808) fixme:alsa:ALSA_AddRingMessage two fast messages in the queue toget = 52(WINE_WM_RESTARTING), tosave=53(UNKNOWN(0x)) fixme:alsa:ALSA_AddRingMessage two fast messages in the queue toget = 36(WINE_WM_RESTARTING), tosave=37(UNKNOWN(0x)) hope that helps. Again, greats that that is all that's wrong^_^ The graphics look great, it sounds great, and the videos are crystal clear(though small). -Matthew Clark
