http://bugs.winehq.org/show_bug.cgi?id=10697
Summary: Starcraft:Broodwar (using OpenGL renderer) regression. Product: Wine Version: CVS/GIT Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wine-directx-d3d AssignedTo: wine-bugs@winehq.org ReportedBy: kazikcz@gmail.com
Lately (since 0.9.47) Starcraft became unplayable for me in the OpenGL mode rendering. I suppose this is since the hardware color conversion was implemented.
I guess a little background history may also help:
?.?.?? - 0.9.46: ** 'textex' and 'readtex': The game works. But if the wine window lost it's focus, the would freeze forever and never resume (though the sounds were working, and you could actually try playing). ** 'auto'/others: I don't remember. Propably crashed.
0.9.47 - 0.9.49: ** 'textex' and 'readtex': The game starts. Sound is working, you can start the game, but all you can see is an upscaled upper-left (or so I've heard from someone) pixel to fullscreen - i.e. you see solid colored wine window. ** 'auto'/others: The game crashes nearly instantly after opening wine window.
0.9.50 - git: ** 'textex' and 'readtex': The game starts. Sound is working, you can even start the game, but all you can see is a white screen. I get these messages in the terminal: ------ fixme:d3d_surface:surface_allocate_surface >>>>>>>>>>>>>>>>> GL_INVALID_ENUM (0x500) from glTexImage2D @ surface.c / 304 fixme:d3d_surface:surface_upload_data >>>>>>>>>>>>>>>>> GL_INVALID_ENUM (0x500) from glTexSubImage2D @ surface.c / 245 fixme:d3d_surface:surface_upload_data >>>>>>>>>>>>>>>>> GL_INVALID_ENUM (0x500) from glTexSubImage2D @ surface.c / 245 ... fixme:d3d_surface:surface_upload_data >>>>>>>>>>>>>>>>> GL_INVALID_ENUM (0x500) from glBindBufferARB @ surface.c / 234 fixme:d3d_surface:surface_upload_data >>>>>>>>>>>>>>>>> GL_INVALID_OPERATION (0x502) from glTexSubImage2D @ surface.c / 238 ... Full log in the attachement. ------ ** 'auto'/others: The game crashes just after displaying the main menu screen. I get these messages in the terminal: ------ ... =>1 0x7c85847c d3dfmt_convert_surface+0x10a() in wined3d (0x00000000) 0x7c85847c d3dfmt_convert_surface+0x10a in wined3d: movzbl 0x0(%ecx,%edi,1),%edx ... Full log in the attachement. ------
I use nvidia binary drivers 9643, with a GeForce 4 MX440 card. I'm not using any compositing manager and I've tried running Xorg in both 16 and 24 bit depth. A friend of mine reports he has exactly same issues with his GeForce 4 Ti. I also checked this with xorg-server 1.3 and xorg-server 1.4.
The game however, works for some people (I hear GeForce 6+ users) smoothly and very fast.
Is there anything else I should provide ? Some extra debug ?
http://bugs.winehq.org/show_bug.cgi?id=10697
--- Comment #1 from Michał Kazior kazikcz@gmail.com 2007-12-07 06:38:43 --- Created an attachment (id=9533) --> (http://bugs.winehq.org/attachment.cgi?id=9533) 'textex' fixme messages and 'auto' crash backtrace
http://bugs.winehq.org/show_bug.cgi?id=10697
Wiebe Cazemier wiebe@halfgaar.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |wiebe@halfgaar.net
http://bugs.winehq.org/show_bug.cgi?id=10697
--- Comment #2 from Roderick Colenbrander thunderbird2k@gmx.net 2007-12-16 17:45:11 --- Could you attach the result of glxinfo on your system?
http://bugs.winehq.org/show_bug.cgi?id=10697
--- Comment #3 from Michał Kazior kazikcz@gmail.com 2007-12-17 02:05:39 --- Created an attachment (id=9666) --> (http://bugs.winehq.org/attachment.cgi?id=9666) glxinfo output when running xorg in 16 bit depth
http://bugs.winehq.org/show_bug.cgi?id=10697
--- Comment #4 from Michał Kazior kazikcz@gmail.com 2007-12-17 02:06:46 --- Created an attachment (id=9667) --> (http://bugs.winehq.org/attachment.cgi?id=9667) glxinfo output when running xorg in 24 bit depth
http://bugs.winehq.org/show_bug.cgi?id=10697
blizz blizzi@wp.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |blizzi@wp.pl
--- Comment #5 from blizz blizzi@wp.pl 2007-12-18 10:46:55 --- I can confirm that the problem also exist on my gf4ti and ubuntu 7.10. Regards.
http://bugs.winehq.org/show_bug.cgi?id=10697
Roderick Colenbrander thunderbird2k@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ghettopolak04@hotmail.com
--- Comment #6 from Roderick Colenbrander thunderbird2k@gmx.net 2007-12-23 13:15:28 --- *** Bug 10766 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=10697
--- Comment #7 from Roderick Colenbrander thunderbird2k@gmx.net 2007-12-23 13:50:09 --- Created an attachment (id=9776) --> (http://bugs.winehq.org/attachment.cgi?id=9776) fix
This patch should fix at least the RED issue and most likely also the other problems.
http://bugs.winehq.org/show_bug.cgi?id=10697
--- Comment #8 from Michał Kazior kazikcz@gmail.com 2007-12-23 14:48:21 --- I've built today's git with and without your patch, and the screen's still snow-white (in both cases). No improvement whatsoever.
http://bugs.winehq.org/show_bug.cgi?id=10697
--- Comment #9 from Roderick Colenbrander thunderbird2k@gmx.net 2007-12-23 15:31:18 --- The GL_INVALID_* errors were bad and those should have been fixed. I can't easily say what's broken. It could be a driver bug. I have tested StarCraft using Mesa as that's the best way to emulate your card (it has some GL extensions which my geforce7 lacks and the way around). It appears to work fine there (though before my patch it was red). I was using RenderTargetLockMode readtex.
http://bugs.winehq.org/show_bug.cgi?id=10697
--- Comment #10 from Michał Kazior kazikcz@gmail.com 2007-12-23 16:41:36 --- I decided to check out the sources myself (even though I have absolutely no idea about Direct3D nor OpenGL programming) and played around. Here are my notes:
RenderTargetLockMode - textex/readtex: In the d3dfmt_get_conv() function (line ~1402) the condition: --- if( !(GL_SUPPORT(EXT_PALETTED_TEXTURE) || (GL_SUPPORT(ARB_FRAGMENT_PROGRAM) && p8_render_target)) || colorkey_active || (!use_texturing && GL_SUPPORT(EXT_PALETTED_TEXTURE)) ) { --- .. is never true for me, and neither is the next one. This causes format, internal, type, target_bpp and convert to be left unset. If I change it to: --- if (1) { --- .. then StarCraft renders correctly, however the game is actually slower than in GDI mode! There can be barely seen any movement in the main menu. If I start, for example a custom game, it gets faster, until I try to move something. The more moving/animating objects, the slower things get.
RenderTargetLockMode - auto: This one segfaults right after entering the game main menu. I traced the thing, and it seems something's messed up with PBOs. After inspecting the code, I came to conclusion, that a PBO gets created after a few *_LockRect. However, when the UnlockRect is issued afterwards, it frees the PBO, the This->resource.allocatedMemory is set to NULL and is never recovered (and the PBO is never retrieved, or so I guess), thus --- trace:d3d_surface:d3dfmt_convert_surface ((nil))->(0x2c60028),(640,480,2560,1,0x1886b0) --- .. is issued and crashes the whole thing.
I'm pretty tired since it's rather late here. Nevertheless, I hope it will shed a light on this issue. I'll also attach the 'trace+d3d_surface' results.
http://bugs.winehq.org/show_bug.cgi?id=10697
--- Comment #11 from Michał Kazior kazikcz@gmail.com 2007-12-23 16:42:19 --- Created an attachment (id=9780) --> (http://bugs.winehq.org/attachment.cgi?id=9780) Pure wine-0.9.51-190-g13aadb2 build. This is how things look by default.
http://bugs.winehq.org/show_bug.cgi?id=10697
--- Comment #12 from Michał Kazior kazikcz@gmail.com 2007-12-23 16:42:33 --- Created an attachment (id=9781) --> (http://bugs.winehq.org/attachment.cgi?id=9781) After modifying the conditional.
If I change the condition (dlls/wined3d/surface.c:1402) to be always true 'if(1) {', or explicitly set the format, internal, type, target_bpp and convert variables, the game starts to render properly, but is slower than GDI mode.
http://bugs.winehq.org/show_bug.cgi?id=10697
--- Comment #13 from Michał Kazior kazikcz@gmail.com 2007-12-23 16:42:52 --- Created an attachment (id=9782) --> (http://bugs.winehq.org/attachment.cgi?id=9782) A detailed trace of a segfault using RenderTargetLockMode set to 'auto'.
http://bugs.winehq.org/show_bug.cgi?id=10697
Michał Kazior kazikcz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #9780|Pure wine-0.9.51-190- |Trace of a pure wine-0.9.51- description|g13aadb2 build. This is how |190-g13aadb2 build. This is |things look by default. |how things look by default.
http://bugs.winehq.org/show_bug.cgi?id=10697
Michał Kazior kazikcz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #9781|After modifying the |Trace after modifying the description|conditional. |conditional.
http://bugs.winehq.org/show_bug.cgi?id=10697
Michał Kazior kazikcz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #9782|A detailed trace of a |Trace of a segfault using description|segfault using |RenderTargetLockMode set to |RenderTargetLockMode set to |'auto'. |'auto'. |
http://bugs.winehq.org/show_bug.cgi?id=10697
--- Comment #14 from Roderick Colenbrander thunderbird2k@gmx.net 2007-12-24 12:18:00 --- Can you edit dlls/wined3d/directx.c: Right at the beginning, there is a table containing opengl extensions. Can you comment out or remove the line GL_ARB_texture_rectangle, recompile and see if that makes the game fast?
Not too long ago this extension got added to wine but on some cards it might be emulated.
http://bugs.winehq.org/show_bug.cgi?id=10697
--- Comment #15 from Roderick Colenbrander thunderbird2k@gmx.net 2007-12-24 12:19:48 --- Second can you attach the output of glxinfo? Further in the 'after' screenshot PBOs aren't getting used but those in general only get activated after 50fps or so, so perhaps the log was from an early moment in time.
http://bugs.winehq.org/show_bug.cgi?id=10697
--- Comment #16 from Michał Kazior kazikcz@gmail.com 2007-12-25 03:30:20 --- Created an attachment (id=9792) --> (http://bugs.winehq.org/attachment.cgi?id=9792) Trace of what happens when I comment out the extension in dlls/wined3d/directx.c
(In reply to comment #14)
Can you edit dlls/wined3d/directx.c: Right at the beginning, there is a table containing opengl extensions. Can you comment out or remove the line GL_ARB_texture_rectangle, recompile and see if that makes the game fast?
Not too long ago this extension got added to wine but on some cards it might be emulated.
After removing the line containing this extension I get the behaviour of wine version 0.9.47 to 0.9.49. The whole window is a solid color and it changes when changing menus (via shorcut keys ofcourse), which means it most likely points to a single pixel somewhere.
http://bugs.winehq.org/show_bug.cgi?id=10697
Michał Kazior kazikcz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #9781 is|0 |1 obsolete| |
--- Comment #17 from Michał Kazior kazikcz@gmail.com 2007-12-25 03:45:27 --- Created an attachment (id=9793) --> (http://bugs.winehq.org/attachment.cgi?id=9793) Trace (longer one) after modyfing the aforementioned conditional.
(In reply to comment #15)
Second can you attach the output of glxinfo? Further in the 'after' screenshot PBOs aren't getting used but those in general only get activated after 50fps or so, so perhaps the log was from an early moment in time.
Hope this is enough. This trace is nearly 14 megs after decompressing, and despite that, I don't find any references to the PBOs in it.
This is in 'textex' RenderTargetLockMode. Maybe the PBOs aren't used in this mode ?
My glxinfo output is already attached in the bug report.
http://bugs.winehq.org/show_bug.cgi?id=10697
--- Comment #18 from Roderick Colenbrander thunderbird2k@gmx.net 2007-12-25 04:26:52 --- I'm using readtex but that shouldn't matter much but you can try it.
I fear there is a driver bug. When I started with the 8bit code there was a bug in the nvidia driver of that time for my geforcefx. I don't remember what driver version I was using at that time.
What you could do to test it is to download the mesa source code and compile it. Then set the library path to point to the compiled mesa library and try to run starcraft. If it works (sure, it will be slow) it is a driver bug (you can play a bit with it to verify it).
http://bugs.winehq.org/show_bug.cgi?id=10697
--- Comment #19 from Michał Kazior kazikcz@gmail.com 2007-12-25 05:39:40 --- I did as you told me to. I compiled Mesa, played a bit (using pure wine build), and here's what I found out:
1. I compiled Mesa with 'linux-dri-x86' config first, as this was used in the PKGBUILD of Mesa in my ArchLinux. The outcome is a libGL.so.1.2, libGLU.so.1.3.070001 and libGLw.so.1.0.0. I copied the libGL to the /usr/lib and changed the symlinks. Glxinfo reported no direct rendering (I presume this means it's using Mesa), however glxgears worked as before (no significant frame drop). I tried running StarCraft in these RenderTargetLockModes: 'textex/readtex' (both) - the screen is still as white as it was 'auto' - the game no longer crashes, but is incredibly slow (an improvement)
This means it somewhat fixed the PBO failure.
2. Then, I compiled Mesa with 'linux-x86' and got: libGL.so.1.5.070001, libGLU.so.1.3.070001, libGLw.so.1.0.0 and libOSMesa.so.6.5.3. I copied the libGL and libOSMesa to the /usr/lib and changed the symlinks. This time glxgears slowed down from 1200fps to 200fps. The results are: 'textex/readtex' (both) - the screen is in monochrome red 'auto' - the game crashes like it was before
I applied your earlier patch for the 'red screen bug' and the game started to render correctly (as a sidenote: it worked at least four times slower than in GDI; I could see how the game screen gets drawn from top to bottom, but I guess that's because it's doing software OpenGL).
I think it's not a driver bug, but rather an OpenGL extensions issue (maybe a bug or a slightly different usage; I have no idea, because I've never did anything using OpenGL before)
Oh, and I found this: http://www.nvnews.net/vbulletin/showthread.php?t=73108&highlight=pbo which may be somewhat related to the PBO issue here.
http://bugs.winehq.org/show_bug.cgi?id=10697
--- Comment #20 from Roderick Colenbrander thunderbird2k@gmx.net 2007-12-25 06:48:02 --- On a sidenote if Mesa was build in e.g. /usr/src/Mesa-6.5.3 then the libs would be in I think /usr/src/Mesa-6.5.3/lib. You could then have done export LD_LIBRARY_PATH=/usr/src/Mesa-6.5.3/lib and then run wine. This won't mess up your system.
There could be a pbo bug on your system. You can disable PBOs (GL_ARB_PIXEL_BUFFER_OBJECT) in directx.c in a similar way as I asked you to play with the texture rectangle stuff (so just disable the line in there).
http://bugs.winehq.org/show_bug.cgi?id=10697
--- Comment #21 from Roderick Colenbrander thunderbird2k@gmx.net 2007-12-25 06:54:04 --- On a sidenote when you were using Mesa, Mesa also offers PBOs and everything else. I'm quite sure it is a driver bug. The 'linux-x86' run is the proper mesa binary you should use and as long as the glxinfo output shows Mesa in all the gl / glx vendor strings and such it is fine.
http://bugs.winehq.org/show_bug.cgi?id=10697
--- Comment #22 from blizz blizzi@wp.pl 2007-12-25 16:11:26 --- Created an attachment (id=9801) --> (http://bugs.winehq.org/attachment.cgi?id=9801) output on matrox g400
Well i have done the test of wine 0.9.51 on matrox g400 and starcraft. I have set DirectDrawRenderer to opengl and RenderTargetLockMode to readtex also i've set OffscreenRenderingMode to pbuffer. Result is nearly same as on my gforce4ti except that the screen was in light blue color not white. I have set WINEDEBUG=trace+d3d_surface before run. Regards!
http://bugs.winehq.org/show_bug.cgi?id=10697
--- Comment #23 from blizz blizzi@wp.pl 2007-12-25 16:19:06 --- Created an attachment (id=9802) --> (http://bugs.winehq.org/attachment.cgi?id=9802) glxinfo from matrox g400
Here i've attach glxinfo output of matrox g400
http://bugs.winehq.org/show_bug.cgi?id=10697
--- Comment #24 from Roderick Colenbrander thunderbird2k@gmx.net 2007-12-30 06:37:05 --- Still I don't trust the drivers. I would go back to pure nvidia and mesa (the red issue has been solved). I think something is going wrong with GL_EXT_paletted_texture, perhaps mixed with PBOs. Disable both GL_EXT_paletted_texture and GL_ARB_pixel_buffer_object. After that wine should default to basic GL rendering which should not fail at all.
http://bugs.winehq.org/show_bug.cgi?id=10697
Alexander Dorofeyev alexd4@inbox.lv changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |alexd4@inbox.lv
--- Comment #25 from Alexander Dorofeyev alexd4@inbox.lv 2008-01-02 03:11:04 --- FWIW, Starcraft crashes with opengl renderer and RenderTargetLockMode=auto for me on 0.9.52, while it works ok with readtex (but with performance issues, it would seem, I like it much more in gdi renderer). I've onboard GeForce6100 and binary nvidia drivers 100-something. I'm not sure it's a bug or "feature". Is it supposed to work with auto?
http://bugs.winehq.org/show_bug.cgi?id=10697
--- Comment #26 from Wiebe Cazemier wiebe@halfgaar.net 2008-01-02 05:53:45 --- (In reply to comment #25)
There is no "auto" mode, really. When using auto, you're just using readdraw. See http://wiki.winehq.org/UsefulRegistryKeys.
http://bugs.winehq.org/show_bug.cgi?id=10697
--- Comment #27 from Alexander Dorofeyev alexd4@inbox.lv 2008-01-02 15:48:40 --- Created an attachment (id=9991) --> (http://bugs.winehq.org/attachment.cgi?id=9991) +d3d,+d3d_surface,+ddraw crash log (nvidia 100.14.11-4)
Yeah, I figured auto isn't a real mode. Also I can see how some modes can be non-compatible with some hardware. But crashing is a bit much, especially for something "default". I'm attaching a crash log (has debug symbols). I took the relevant part, the beginning and the end (cleanup after exception) stripped.
I believe bug#10899 may be same thing (little info there, but backtrace looks similar).
http://bugs.winehq.org/show_bug.cgi?id=10697
--- Comment #28 from Roderick Colenbrander thunderbird2k@gmx.net 2008-01-07 16:35:48 --- On a sidenote RenderTargetLockMode=readdraw (the default value) won't cause a crash from now on. Further that if-statement which you forced to one should evaluate to 1 now on your system when it is needed (in case of readdraw mode).
http://bugs.winehq.org/show_bug.cgi?id=10697
--- Comment #29 from Roderick Colenbrander thunderbird2k@gmx.net 2008-01-11 08:43:29 --- An update to this bug. I have debugged it a little on someone's machine with a GeforceFX. In 0.9.47 readtex indeed didn't work. There was an error in d3dfmt_get_conv it applied a 'correction' to the pixel format while it wasn't needed. It was doing:
else if(GL_SUPPORT(ARB_FRAGMENT_PROGRAM)) { *format = GL_RED; *internal = GL_RGBA; *type = GL_UNSIGNED_BYTE; *target_bpp = 1; }
while it should have been doing else if(GL_SUPPORT(ARB_FRAGMENT_PROGRAM) && !GL_SUPPORT(EXT_PALETTED_TEXTURE))
That got it working again but it broke again somewhere during the surface.c rewrite at 29/10. If someone with such a system and programming experience can play around with it, it could help. Myself I can't reproduce the bug, it might also just be that a driver bug got triggered. (I was logged in using remote GLX and didn't see issues on my Geforce6)
http://bugs.winehq.org/show_bug.cgi?id=10697
--- Comment #30 from Roderick Colenbrander thunderbird2k@gmx.net 2008-01-11 10:39:52 --- For some reason uploading of the data ('palette indices') doesn't seem to work for some reason. Just forcing the data to get uploaded as GL_RED seems to work fine (the game is then black&red) else the screen just becomes white. Further the other palette conversion backend which uses shaders also doesn't seem to function on the GeforceFX. I have no idea why.
Is the first version after the surface rewrite which readds texture uploading 2a09716c75207d7276a95c094ef3dfa9bd03c613 but it fails (make sure to adjust d3dfmt_get_conv like I posted in another message).
The last working version (after you fix d3dfmt_get_conv) is 20f1f50b2a20b5d8b033babd2a14a0e43c2a00b4
I suspect it is really an nvidia driver bug as Mesa still works. Somehow the different codepath has triggered or perhaps Wine isn't uploading at the right moment anymore. I won't do more debugging on it for a while.
GL_INVALID_ENUM lines might appear to due GL_ARB_texture_rectangle which you can disable in directx.c.
http://bugs.winehq.org/show_bug.cgi?id=10697
--- Comment #31 from pspallanz@gmail.com 2008-01-11 14:50:36 --- Created an attachment (id=10170) --> (http://bugs.winehq.org/attachment.cgi?id=10170) patch to dlls/wined3d/surface.c
I get this bug with wine 0.9.52 and a nvidia GeForce2 MX graphics card.
Using 'readtex' I get a white screen and lots of GL_INVALID_ENUM messages. This is because although the graphics card supports GL_ARB_texture_rectangle and GL_EXT_paletted_texture apparently they don't work together (cannot create a rectangular paletted texture).
Disabling GL_ARB_texture_rectangle in directx.c fixes this but then I get a solid colored window. This is a bug in surface_blt_to_drawable, the texture coordinates are calculated using an integer division and thus are all set to 0. The attached patch fixes this.
With the patch applied the game runs well but will stop working if another window is moved over the wine window, the game will keep running and respond to mouse clicks but the display will stop updating.
http://bugs.winehq.org/show_bug.cgi?id=10697
--- Comment #32 from Roderick Colenbrander thunderbird2k@gmx.net 2008-01-12 04:06:34 --- Hmm, interesting I'll investigate this. I wonder why this didn't trigger bugs for Geforce6 and higher cards... even with GL_ARB_texture_rectangle disabled.
http://bugs.winehq.org/show_bug.cgi?id=10697
--- Comment #33 from Roderick Colenbrander thunderbird2k@gmx.net 2008-01-12 06:39:05 --- Nothing looks to be wrong with the patch (though I guess the same can be achieved using integers by adding +1 or so for rounding). Before my texture upload function also used floats, but Stefan merged some codepaths and the combined one used integers but it won't matter. Can you make the patch against the latest GIT (wine 0.9.53) and then submit it?
I'm not sure what we should do regarding ARB_texture_rectangle. At some point we should detect its presence and when we suspect that EXT_paletted_texture will be used we need to disable it or so. Not sure where we should do that and if there is a cleaner way.
http://bugs.winehq.org/show_bug.cgi?id=10697
--- Comment #34 from Roderick Colenbrander thunderbird2k@gmx.net 2008-01-12 09:48:12 --- You could try to do the following in surface_blt_to_drawable to disable GL_ARB_texture_rectangle.
if(This->glDescription.target == GL_TEXTURE_RECTANGLE_ARB) to if((This->glDescription.target == GL_TEXTURE_RECTANGEL_ARB) && !((This->resource.format == WINED3DFMT_P8) && GL_SUPPORT(EXT_PALETTED_TEXTURE)))
http://bugs.winehq.org/show_bug.cgi?id=10697
Andrew Charles Hurst a.hurst@shef.ac.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |a.hurst@shef.ac.uk
http://bugs.winehq.org/show_bug.cgi?id=10697
--- Comment #35 from pspallanz@gmail.com 2008-01-12 12:56:26 --- OK, I submitted the patch to wine-patches.
For #32, I guess that newer cards are not affected because they support nonpower2 textures thus in surface_blt_to_drawable This->pow2Width is equal to rect.right.
For #34, that doesn't work. The first GL_INVALID_ENUM message occurs in the call to glTexImage2D in surface_allocate_surface, the fix should be applied before surface_allocate_surface is called. Maybe in IWineD3DSurfaceImpl_PrivateSetup, change
if(This->Flags & SFLAG_NONPOW2 && GL_SUPPORT(ARB_TEXTURE_RECTANGLE)) { This->glDescription.target = GL_TEXTURE_RECTANGLE_ARB; This->pow2Width = This->currentDesc.Width; This->pow2Height = This->currentDesc.Height; This->Flags &= ~SFLAG_NONPOW2; } to
if(This->Flags & SFLAG_NONPOW2 && GL_SUPPORT(ARB_TEXTURE_RECTANGLE) && This->resource.format != WINED3DFMT_P8) { This->glDescription.target = GL_TEXTURE_RECTANGLE_ARB; This->pow2Width = This->currentDesc.Width; This->pow2Height = This->currentDesc.Height; This->Flags &= ~SFLAG_NONPOW2; }
http://bugs.winehq.org/show_bug.cgi?id=10697
--- Comment #36 from Roderick Colenbrander thunderbird2k@gmx.net 2008-01-12 13:28:33 --- Finding the right place is tricky (though not as tricky as what I had to do for the p8 fragment shader). It could be the right place but it should only be overridden for WINED3DFMT_P8, when GL_EXT_paletted_texture is around and when the RenderTargetLockMode is readtex or textex.
http://bugs.winehq.org/show_bug.cgi?id=10697
Paaru pcxunlimited@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |pcxunlimited@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=10697
--- Comment #37 from Roderick Colenbrander thunderbird2k@gmx.net 2008-01-15 10:58:00 --- Your patch is in now. Try this check in PrivateSetup (I didn't have time to build a diff or compile it):
if(This->Flags & SFLAG_NONPOW2 && GL_SUPPORT(ARB_TEXTURE_RECTANGLE) && !((This->resource.format == WINED3DFMT_P8) && GL_SUPPORT(EXT_PALETTED_TEXTURE) && (wined3d_settings.rendertargetlock_mode == READTEX || wined3d_settings.rendertargetlock_mode == TEXTEX)))
http://bugs.winehq.org/show_bug.cgi?id=10697
Paaru pcxunlimited@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |thunderbird2k@gmx.net
http://bugs.winehq.org/show_bug.cgi?id=10697
--- Comment #38 from Paaru pcxunlimited@gmail.com 2008-01-15 11:48:19 --- StarCraft worked flawlessly for me in version 0.9.46 (sans Battle.net) but stopped immediately after upgrading to 0.9.50: when starting up there is only blank white. Sound still comes through and you can navigate the menus but the game is unusable. I have a GeForce FX 5500 and am using the nvidia driver (nvidia-glx-new) in case anybody is curious.
Anyways, I did a clean build and a git regression trace and found this:
134aa67ec9fc9f761e6da15a816f770d8a30c455 is first bad commit commit 134aa67ec9fc9f761e6da15a816f770d8a30c455 Author: Roderick Colenbrander thunderbird2k@gmx.net Date: Thu Oct 11 23:11:37 2007 +0200
wined3d: Use a fragment shader to do P8 palette conversion in hardware.
:040000 040000 5ece1cfa7b511bdf0c8be00272d72458be900e7b a94969633ef6de216ff7ec9010c5fb4642bc455a M dlls
I am not sure if this is the cause of all the problems with everybody, but it definitely seems to be the problem I am having.
http://bugs.winehq.org/show_bug.cgi?id=10697
--- Comment #39 from Roderick Colenbrander thunderbird2k@gmx.net 2008-01-15 11:59:26 --- There are different issues. Initially it was my p8 shader patch but big parts of the code got a rewrite and in that rewrite a number of things broke.
In the latest GIT version starcraft should work again IF you disable GL_ARB_texture_rectangle support in directx.c on cards that lack non-power-of-two textures.
Further read comment 34 to 37. Try to add the lines of comment 37 to the function mentioned in one of the other posts and then it should work too.
http://bugs.winehq.org/show_bug.cgi?id=10697
--- Comment #40 from Roderick Colenbrander thunderbird2k@gmx.net 2008-01-19 08:14:44 --- Does disabling of GL_ARB_texture_rectangle work for everyone? Did anyone try my proposed fix?
http://bugs.winehq.org/show_bug.cgi?id=10697
--- Comment #41 from Paaru pcxunlimited@gmail.com 2008-01-19 15:31:18 --- I followed the directions in comment 35 (for surface.c) and StarCraft works again! The appendage in comment 37, however, does not:
surface.c: In function ‘IWineD3DSurfaceImpl_PrivateSetup’: surface.c:3474: error: ‘READTEX’ undeclared (first use in this function) surface.c:3474: error: (Each undeclared identifier is reported only once surface.c:3474: error: for each function it appears in.) surface.c:3474: error: ‘TEXTEX’ undeclared (first use in this function) make[2]: *** [surface.o] Error 1 make[2]: Leaving directory `/mnt/pauan/wine/dlls/wined3d' make[1]: *** [wined3d] Error 2 make[1]: Leaving directory `/mnt/pauan/wine/dlls' make: *** [dlls] Error 2
http://bugs.winehq.org/show_bug.cgi?id=10697
--- Comment #42 from Roderick Colenbrander thunderbird2k@gmx.net 2008-01-19 15:53:01 --- Err, RTL_ should have been in front of READTEX / TEXTEX, so it should have been:
if(This->Flags & SFLAG_NONPOW2 && GL_SUPPORT(ARB_TEXTURE_RECTANGLE) && !((This->resource.format == WINED3DFMT_P8) && GL_SUPPORT(EXT_PALETTED_TEXTURE) && (wined3d_settings.rendertargetlock_mode == READTEX || wined3d_settings.rendertargetlock_mode == TEXTEX)))
Hmm, perhaps I should just be checking if the format is GL_COLOR_INDEX ...
http://bugs.winehq.org/show_bug.cgi?id=10697
--- Comment #43 from Michał Kazior kazikcz@gmail.com 2008-01-19 16:02:22 --- #40 - yes. Removing the GL_ARB_texture_rectangle in conjuction with the newest GIT brings back the wine 0.9.46 behaviour to the game (GF4 MX440, 96.43.01).
However, the game still ceases to render itself under certain circumstances: - moving the wine window itself - moving a window over the wine window (but not always) - raising the wine window (if succesfully overlapped earlier; also not always) - launching/terminating xcompmgr while starcraft is running (sometimes) - clicking on the wine window titlebar (sometimes) - on it's own (seems like it's the case when the game/system gets overloaded)
When running xcompmgr starcraft doesn't render at all - however one can reveal it's contents when moving a window over the wine window (it doesn't work if the game ceases to render though).
Regards.
http://bugs.winehq.org/show_bug.cgi?id=10697
--- Comment #44 from Roderick Colenbrander thunderbird2k@gmx.net 2008-01-19 16:11:51 --- I guess that the issues you describe are related to changes in winex11.drv causing e.g. some events not to get received or something like that. You could try to perform a regression test on winex11.drv and keep the wined3d/ddraw code around (just only recompile winex11.drv and wineserver).
Also check if my fix works as disabling GL_ARB_texture_rectangle in directx.c is not the solution. I like to have a fix in the next wine.
http://bugs.winehq.org/show_bug.cgi?id=10697
--- Comment #45 from Paaru pcxunlimited@gmail.com 2008-01-19 17:35:37 --- Well, with the update I now get:
surface.c: In function ‘IWineD3DSurfaceImpl_PrivateSetup’: surface.c:3474: error: ‘READTEX’ undeclared (first use in this function) surface.c:3474: error: (Each undeclared identifier is reported only once surface.c:3474: error: for each function it appears in.) surface.c:3474: error: ‘TEXTEX’ undeclared (first use in this function) surface.c:3475: warning: statement with no effect surface.c:3475: error: expected ‘;’ before ‘->’ token surface.c:3475: error: expected statement before ‘)’ token surface.c:3475: error: label ‘This’ used but not defined make[2]: *** [surface.o] Error 1 make[2]: Leaving directory `/mnt/pauan/wine/dlls/wined3d' make[1]: *** [wined3d] Error 2 make[1]: Leaving directory `/mnt/pauan/wine/dlls' make: *** [dlls] Error 2
(Note: I didn't change directx.c at all)
http://bugs.winehq.org/show_bug.cgi?id=10697
--- Comment #46 from Roderick Colenbrander thunderbird2k@gmx.net 2008-01-20 02:57:32 --- Oops, I really can't type. I said in my last comment that it should have been 'RTL_READTEX' and so on but didn't patch the code.
if(This->Flags & SFLAG_NONPOW2 && GL_SUPPORT(ARB_TEXTURE_RECTANGLE) && !((This->resource.format == WINED3DFMT_P8) && GL_SUPPORT(EXT_PALETTED_TEXTURE) && (wined3d_settings.rendertargetlock_mode == RTL_READTEX || wined3d_settings.rendertargetlock_mode == RTL_TEXTEX)))
http://bugs.winehq.org/show_bug.cgi?id=10697
--- Comment #47 from Paaru pcxunlimited@gmail.com 2008-01-20 06:41:05 --- Well, now it works. Though.. when I moved the terminal window over the StarCraft window it crashed. I'll attach the file, though I doubt it has much to do with this bug. (I'll file a new bug report if necessary)
http://bugs.winehq.org/show_bug.cgi?id=10697
--- Comment #48 from Paaru pcxunlimited@gmail.com 2008-01-20 06:46:59 --- Created an attachment (id=10378) --> (http://bugs.winehq.org/attachment.cgi?id=10378) Debug log (with backtrace)
http://bugs.winehq.org/show_bug.cgi?id=10697
--- Comment #49 from Roderick Colenbrander thunderbird2k@gmx.net 2008-01-20 07:03:59 --- Hmm, it looks like it can be a sound issue. I guess that due to covering starcraft with another window, the sound thread doesn't receive enough priority which causes issues. Could you check if the problem also happens when you disable sound in wine? (just don't select an audio driver)
http://bugs.winehq.org/show_bug.cgi?id=10697
--- Comment #50 from Paaru pcxunlimited@gmail.com 2008-01-20 07:43:45 --- Oddly enough I can't recreate the crash. I was testing it in-game against computers so I'll try and find the exact map I was playing on. It seems that sometimes it will stop rendering, but not always. Example: if you switch to a different application while StarCraft is on the Loading screen it usually stops rendering, but past that it seems to work fine. I'll keep looking to see if I can spot the crash again.
http://bugs.winehq.org/show_bug.cgi?id=10697
Roderick Colenbrander thunderbird2k@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED
--- Comment #51 from Roderick Colenbrander thunderbird2k@gmx.net 2008-01-23 10:12:59 --- The last fix is in GIT, so starcraft should run out of the box again.
http://bugs.winehq.org/show_bug.cgi?id=10697
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #52 from Dan Kegel dank@kegel.com 2008-01-28 06:11:23 --- Closing all RESOLVED FIXED bugs older than 0.9.54.
http://bugs.winehq.org/show_bug.cgi?id=10697
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|CVS/GIT |unspecified
-
wine-bugs＠winehq.org