http://bugs.winehq.org/show_bug.cgi?id=22356
Summary: Jedi Knight: Dark Forces II - weapons flicker Product: Wine Version: 1.1.42 Platform: x86 URL: http://www.filefront.com/845549/jedidemo.exe OS/Version: Linux Status: NEW Keywords: download, regression Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: jeffz@jeffz.name
nvidia geforce 8 - driver version 195.36.15, latest git.
Install the demo, wine jkdemo, create a new player profile, start a new game, notice the blaster rifle flickers very quickly. wine-1.1.37 doesn't have this issue.
I'll be able to post the regression test results in a few days.
http://bugs.winehq.org/show_bug.cgi?id=22356
Wylda wylda@volny.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |wylda@volny.cz
--- Comment #1 from Wylda wylda@volny.cz 2010-04-15 17:36:32 --- (In reply to comment #0)
I'll be able to post the regression test results in a few days.
Regressions can't wait :-)
1. For me the weapon does not flicker, but is missing completely.
2. I did a regression test between 1.1.38 and 1.1.39:
commit 5c4d3fb5a21210f48dfb7d9c0af8a91b23dc7ac4 Author: Stefan Dösinger stefan@codeweavers.com Date: Mon Feb 15 12:30:37 2010 +0100
wined3d: Control SFLAG_CONVERTED in surface_prepare_texture.
This makes sure that the flag is set correctly when surface_allocate_surface is called and client storage is disabled properly for converted surfaces.
:040000 040000 1d8c4d280d07e4a43f64fadd0e147896a91350ae 70774f9a29c3acddd57298cdc71b39b31a778aa9 M dlls
3. No other bug report suffers from this commit.
4. Revert of this patch after git checkout makes that problem go away. Reverting on top of wine-1.1.42-345-gd4b8536 fails due to other code changes.
5. Adding author of this patch to CC.
--private keyword: bisected
Note: I had to setup windowed mode, otherwise game does not run.
http://bugs.winehq.org/show_bug.cgi?id=22356
Wylda wylda@volny.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stefan@codeweavers.com
http://bugs.winehq.org/show_bug.cgi?id=22356
Jeff Zaroyko jeffz@jeffz.name changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |directx-d3d
--- Comment #2 from Jeff Zaroyko jeffz@jeffz.name 2010-04-16 04:36:13 --- setting component to directx-d3d.
http://bugs.winehq.org/show_bug.cgi?id=22356
--- Comment #3 from Wylda wylda@volny.cz 2010-04-17 18:47:25 ---
This regression (bisected) is still present in wine-1.1.43.
http://bugs.winehq.org/show_bug.cgi?id=22356
Roderick Colenbrander thunderbird2k@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |thunderbird2k@gmail.com
--- Comment #4 from Roderick Colenbrander thunderbird2k@gmail.com 2010-04-19 09:30:33 --- Are you all seeing this issue (or something related) on Nvidia? I have tried to reproduce it on my laptop which uses ATI but I don't see any issues here. One issue I see though is that at least in a recent Wine 3D mode (16-bit) won't work but software rendering (8-bit) works.
http://bugs.winehq.org/show_bug.cgi?id=22356
--- Comment #5 from Wylda wylda@volny.cz 2010-04-19 09:39:31 --- (In reply to comment #4)
Are you all seeing this issue (or something related) on Nvidia? I have tried to reproduce it on my laptop which uses ATI but I don't see any issues here. One issue I see though is that at least in a recent Wine 3D mode (16-bit) won't work but software rendering (8-bit) works.
Yes, i had this issue on nVidia. Other notes:
* wine: windowed mode * game: 640x480, 3d acceleration not checked
...and the weapon is missing completely.
http://bugs.winehq.org/show_bug.cgi?id=22356
--- Comment #6 from Roderick Colenbrander thunderbird2k@gmail.com 2010-04-22 06:30:51 --- I have seen the issue on Nvidia and I know what the problem is. The patch itself was not bad but the problem is that some other piece of code is removing the SFLAG_CONVERTED flag. Before we always set it by hand, so that hid this issue.
The problem in this case appears to be flip_surface which swaps surface flags (evil). I'm thinking what the nicest fix is.
http://bugs.winehq.org/show_bug.cgi?id=22356
--- Comment #7 from Roderick Colenbrander thunderbird2k@gmail.com 2010-04-27 15:40:19 --- Created an attachment (id=27581) --> (http://bugs.winehq.org/attachment.cgi?id=27581) Fix
This patch should fix the problem.
http://bugs.winehq.org/show_bug.cgi?id=22356
--- Comment #8 from Wylda wylda@volny.cz 2010-04-27 15:49:57 --- (In reply to comment #7)
This patch should fix the problem.
Hi Roderick, unfortunately doesn't fix this problem for me. Applied on top of wine-1.1.43-321-g94a3c09 and the situation is the same, i.e. gun is still completely missing.
http://bugs.winehq.org/show_bug.cgi?id=22356
--- Comment #9 from Roderick Colenbrander thunderbird2k@gmail.com 2010-04-27 16:11:30 --- The patch fixes the flickering gun issue on my Geforce GTS360M system which appears if you run the game in 8-bit mode (the no 3d acceleration mode). Perhaps a different backend is entered on your system which prevents this issue from occurring. What gpu are you using?
You could try to add the following line after 'd3dfmt_convert_surface' (approx 4598): This->Flags |= SFLAG_CONVERTED; So you will get: return WINED3DERR_OUTOFVIDEOMEMORY; } d3dfmt_convert_surface(This->resource.allocatedMemory, mem, pitch, width, height, outpitch, convert, This); This->Flags |= SFLAG_CONVERTED; } else { mem = This->resource.allocatedMemory; }
Hopefully this helps there. I will submit the current fix anyway since it is correct for one class of systems.
http://bugs.winehq.org/show_bug.cgi?id=22356
--- Comment #10 from Wylda wylda@volny.cz 2010-04-27 17:45:51 --- (In reply to comment #9)
appears if you run the game in 8-bit mode (the no 3d acceleration mode).
Exactly. I set up 640x480 8bit, 3d NOT checked
Perhaps a different backend is entered on your system which prevents this issue from occurring. What gpu are you using?
I have nvidia 8600GT v195.36.15
Hopefully this helps there. I will submit the current fix anyway since it is correct for one class of systems.
I modified surface.c as you suggest, but unfortunately it did not fix the problem.
http://bugs.winehq.org/show_bug.cgi?id=22356
--- Comment #11 from Wylda wylda@volny.cz 2010-04-27 18:29:34 ---
Roderick, what about my note, that i'm running that in windowed mode? Can that make a difference??
Anyway, i try to find out, how is the flag value changed before and after the patch. So i did:
d3dfmt_convert_surface(This->resource.allocatedMemory, mem, pitch, width, height, outpitch, convert, This);
+ printf("Change1 before: 0x%08x\n", This->Flags); - This->Flags |= SFLAG_CONVERTED; + printf("Change1 after : 0x%08x\n", This->Flags); } else if (This->resource.format_desc->format == WINED3DFMT_P8_UINT && (gl_info->supported[EXT_PALETTED_TEXTURE] || gl_info->supported[ARB_FRAGMENT_PROGRAM])) { d3dfmt_p8_upload_palette(iface, convert); + printf("Change2 before: 0x%08x\n", This->Flags); - This->Flags &= ~SFLAG_CONVERTED; + printf("Change2 after : 0x%08x\n", This->Flags); mem = This->resource.allocatedMemory; } else { + printf("Change3 before: 0x%08x\n", This->Flags); - This->Flags &= ~SFLAG_CONVERTED; + printf("Change3 after : 0x%08x\n", This->Flags); mem = This->resource.allocatedMemory;
Standing in game with visible gun, i.e. before Stefan's patch:
Change2 after : 0x011a0a28 Change2 before: 0x011a0a28 Change2 after : 0x011a0a28 Change2 before: 0x011a0a28 Change2 after : 0x011a0a28 Change2 before: 0x011a0a28 Change2 after : 0x011a0a28 ...
When the gun is missing, i.e. when Stefan's patch is applied: Change2 after : 0x01120a2a Change2 before: 0x01120a2a Change2 after : 0x01120a2a Change2 before: 0x01120a2a Change2 after : 0x01120a2a Change2 before: 0x01120a2a Change2 after : 0x01120a2a ...
Of course, when Stefan's patch is applied than after == before, but i was lazy to change that ;)
Looking into wined3d_private.h to decode those value did not helped me, because i don't know what's going on.
http://bugs.winehq.org/show_bug.cgi?id=22356
--- Comment #12 from Roderick Colenbrander thunderbird2k@gmail.com 2010-04-28 01:48:36 --- Perhaps windowed mode makes a difference. Myself I'm running the game in a wine desktop and I'm using the demo.
http://bugs.winehq.org/show_bug.cgi?id=22356
--- Comment #13 from Roderick Colenbrander thunderbird2k@gmail.com 2010-04-28 04:53:55 --- Hmm, apparently we are letting the gpu perform 8-bit conversion before Stefan his patch and after it we trigger our software conversion path.
http://bugs.winehq.org/show_bug.cgi?id=22356
--- Comment #14 from Roderick Colenbrander thunderbird2k@gmail.com 2010-04-28 05:00:52 --- Could you try the game using a recent Wine? The 8-bit shader path shouldn't be entered on that at the moment (if I turn the shader path on the game indeed won't start).
http://bugs.winehq.org/show_bug.cgi?id=22356
--- Comment #15 from Wylda wylda@volny.cz 2010-04-28 05:28:59 --- (In reply to comment #14)
Could you try the game using a recent Wine?
Hi Roderick, i tried that yesterday - see comment #8. I usualy try with and without the patch, so i would say wine-1.1.43-321-g94a3c09 is still missing the gun.
The 8-bit shader path shouldn't be entered on that at the moment (if I turn the shader path on the game indeed won't start).
I'm bit worried, if codepath was changed now, there will remain hidden bug with incorrectly set "This->Flags" ?
http://bugs.winehq.org/show_bug.cgi?id=22356
--- Comment #16 from Roderick Colenbrander thunderbird2k@gmail.com 2010-04-28 05:49:22 --- Created an attachment (id=27593) --> (http://bugs.winehq.org/attachment.cgi?id=27593) Another fix (use this one and the other one)
I'm not sure what crash issue you were seeing at startup if you didn't run in windowed mode but perhaps it is the one which is fixed by this patch.
http://bugs.winehq.org/show_bug.cgi?id=22356
--- Comment #17 from Wylda wylda@volny.cz 2010-04-28 06:19:00 ---
Created an attachment (id=27593)
--> (http://bugs.winehq.org/attachment.cgi?id=27593) [details]
Another fix (use this one and the other one)
I'm not sure, what you think by "the other one", because attachment 27581 and 27593 are the same.
I'm not sure what crash issue you were seeing at startup if you didn't run in windowed mode but perhaps it is the one which is fixed by this patch.
I can't recall exactly, but i think it was something messed or unresponsive rather than crash.
Hopefully i will double check both "crash" and patch in cca 6hours.
http://bugs.winehq.org/show_bug.cgi?id=22356
--- Comment #18 from Henri Verbeet hverbeet@gmail.com 2010-04-28 06:28:02 --- (In reply to comment #9)
Hopefully this helps there. I will submit the current fix anyway since it is correct for one class of systems.
I'll save you some trouble then, the patch doesn't make sense to me. If you consistently swap the contents of two surfaces they should also get eachothers flags, otherwise the flags are inconsistent with the surface contents. In that regard, I'm also not sure if the reason that flip_surface() doesn't just copy the entire surface's contents is just a miguided optimization, or if there's a real reason behind that.
http://bugs.winehq.org/show_bug.cgi?id=22356
--- Comment #19 from Roderick Colenbrander thunderbird2k@gmail.com 2010-04-28 09:59:35 --- Created an attachment (id=27599) --> (http://bugs.winehq.org/attachment.cgi?id=27599) The real fix ;)
After some more searching it appeared that the actual issue is that read_from_framebuffer_texture is allocating the texture (because nothing else did it before) but it doesn't set the conversion flags. Instead use surface_prepare_texture to allocate the texture.
http://bugs.winehq.org/show_bug.cgi?id=22356
--- Comment #20 from Wylda wylda@volny.cz 2010-04-28 13:54:34 ---
Created an attachment (id=27599)
--> (http://bugs.winehq.org/attachment.cgi?id=27599) [details]
The real fix ;)
Sorry to say that, but it does not work :-( To be sure i did it correctly, i took wine-1.1.43-347-gb939193 and on top of it i applied attachment id=27599.
Vanilla wine-1.1.43-347-gb939193 does not show the gun either.
Finger crossed for next try - don't worry, i will gladly test anything you send me. I still think, that key here are the flags, i mean the value 0x011a0a28.
http://bugs.winehq.org/show_bug.cgi?id=22356
--- Comment #21 from Roderick Colenbrander thunderbird2k@gmail.com 2010-04-28 14:24:08 --- Perhaps there is a different issue in your case (not sure why, perhaps you added some registry keys? but I guess you are using a clean prefix). Anyway the current fix at least fixes some of the issues and looks correct. The way I found the issue was by calling setting surface_prepare_texture at the start of LoadLocation and found everything working then. Perhaps that could be a start point for you as well. It is quite harmless, the issue is that SFLAG_CONVERTED is not set while in current git that flag is always needed when 'd3dmft_convert_surface' is called.
http://bugs.winehq.org/show_bug.cgi?id=22356
--- Comment #22 from Wylda wylda@volny.cz 2010-05-10 14:14:30 ---
Hi Roderick, i went for the patch http://source.winehq.org/patches/data/61433 and applied on top of wine-1.1.44-72-g658209b but it still does not fix the issue, i.e. weapon is still completely missing.
If you want to tune the patch, send it and can give it quick retest. I don't care how many iteration it will take, gladly test everything :)
http://bugs.winehq.org/show_bug.cgi?id=22356
--- Comment #23 from Roderick Colenbrander thunderbird2k@gmail.com 2010-05-10 14:28:49 --- Perhaps I should have updated the comment when I resubmitted it. Apparently the bug you are seeing is slightly different and this patch only addresses one class of the issues (the patch is good).
I'm still not sure what the other issue is. As I mentioned last time, try what happens if surface_prepare_texture is called at the start of LoadLocation.
http://bugs.winehq.org/show_bug.cgi?id=22356
--- Comment #24 from Roderick Colenbrander thunderbird2k@gmail.com 2010-05-13 14:57:37 --- Created an attachment (id=27940) --> (http://bugs.winehq.org/attachment.cgi?id=27940) test patch
Also give this patch a try. I wonder if it would fix the issue you are seeing. It is not a fix but a dirty hack to figure out where the bug is.
http://bugs.winehq.org/show_bug.cgi?id=22356
--- Comment #25 from Wylda wylda@volny.cz 2010-05-13 15:03:31 --- (In reply to comment #24)
Created an attachment (id=27940)
--> (http://bugs.winehq.org/attachment.cgi?id=27940) [details]
test patch
Also give this patch a try. I wonder if it would fix the issue you are seeing. It is not a fix but a dirty hack to figure out where the bug is.
Nope, doesn't work. Tried this patch and still missing. Than unapplied and applied the trackmania's as i saw it also deals with FLAGS. But none of these makes the gun visible.
http://bugs.winehq.org/show_bug.cgi?id=22356
--- Comment #26 from Wylda wylda@volny.cz 2010-05-13 17:40:19 ---
Hi Roderecik, this seems unfortunate... We are probably looking at wrong place. When i was working on this, i found out that:
* 1.1.38 <--GOOD * 1.1.39 <--BAD * 1.1.40 <--BAD * 1.1.41 <--GOOD * 1.1.42 <--GOOD * 1.1.43 <--BAD * 1.1.44 <--BAD
So i did the testing on git (shortly before release of 1.1.43) and check that again on 1.1.43. But regression testing led me to 1.1.38/39. The patches probably tried to fix the 38/39 issue, but the root is 42/43 issue.
So i filled up bug 22683 which covers the second regression.
Jeff, was the originally reported problem solved for you? If yes, than let's close this bug report.
http://bugs.winehq.org/show_bug.cgi?id=22356
Jeff Zaroyko jeffz@jeffz.name changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #27 from Jeff Zaroyko jeffz@jeffz.name 2010-05-13 18:08:35 --- Confirming fixed. Weapon no longer flickers. Thanks for your work Roderick and thanks for testing Wylda.
The only other regression I see at the moment is when you pick up an item the screen flips when picking up an item. I think normally there is a light blue hue applied to the screen which fades out in 1 second. The inverted display is for the same duration. I think it appeared about the same time as the flickering but it'll need a separate bug report.
http://bugs.winehq.org/show_bug.cgi?id=22356
--- Comment #28 from Wylda wylda@volny.cz 2010-05-13 18:35:42 ---
The only other regression I see at the moment is when you pick up an item the screen flips when picking up an item.
Hmmm... i see that. Not to make the same mistake again i took whole bunch of versions.
* 1.1.40 <--GOOD * 1.1.41 <--BAD * 1.1.42 <--BAD * 1.1.43 <--BAD * 1.1.44 <--BAD
As the pattern differs from comment #26, this will be something new. I'll try to nail that down.
http://bugs.winehq.org/show_bug.cgi?id=22356
--- Comment #29 from Wylda wylda@volny.cz 2010-05-13 19:01:41 ---
The only other regression I see at the moment is when you pick up an item the screen flips when picking up an item.
Filled in bug 22684.
http://bugs.winehq.org/show_bug.cgi?id=22356
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
http://bugs.winehq.org/show_bug.cgi?id=22356
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #30 from Alexandre Julliard julliard@winehq.org 2010-05-21 14:39:55 --- Closing bugs fixed in 1.2-rc1.
http://bugs.winehq.org/show_bug.cgi?id=22356
Wylda wylda@volny.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |5c4d3fb5a21210f48dfb7d9c0af | |8a91b23dc7ac4
-
wine-bugs＠winehq.org