http://bugs.winehq.org/show_bug.cgi?id=16997
Summary: Graphical regression bug in lotro as of Win 1.1.13 Product: Wine Version: 1.1.13 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-d3d AssignedTo: wine-bugs@winehq.org ReportedBy: a.vankaam@chello.nl CC: stefan@codeweavers.com
Created an attachment (id=18791) --> (http://bugs.winehq.org/attachment.cgi?id=18791) 2 screenshots, good vs bad
As of win 1.1.13 symbols above NPC's are totally black, this is most visible when in 3rd person view but also happens in 1st person view but depends more on where your standing when looking at the NPC
I have done the complete regression run between 1.1.12 and 1.1.13 and GIT comes with the following end result:
1deafcb5a758ba7c88e498718a3186d6b526fe71 is first bad commit commit 1deafcb5a758ba7c88e498718a3186d6b526fe71 Author: Stefan Dösinger stefan@codeweavers.com Date: Mon Dec 15 19:37:36 2008 +0100
wined3d: Split the remains of state_fog.
:040000 040000 39455d30afadc1d21664e6730064c5028aa2c3eb 91e5b3d98e7cd72aa61dd8eac1058792d5fce9a7 M dlls
as requested on the regression page I added the author as cc. I will add 2 screenshots to show the diffrence between good (1.1.12) and bad (1.1.13)
-Alex
http://bugs.winehq.org/show_bug.cgi?id=16997
--- Comment #1 from Caladan a.vankaam@chello.nl 2009-01-18 09:51:21 --- Created an attachment (id=18796) --> (http://bugs.winehq.org/attachment.cgi?id=18796) smoke/fog section wine 1.1.12 vs 1.1.13
Noticed it also happens at certain location with smoke/fog, 2 new screenshots attached
http://bugs.winehq.org/show_bug.cgi?id=16997
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |DUPLICATE
--- Comment #2 from Vitaliy Margolen vitaliy@kievinfo.com 2009-01-18 15:12:59 --- Duplicate
*** This bug has been marked as a duplicate of bug 16932 ***
http://bugs.winehq.org/show_bug.cgi?id=16997
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #3 from Vitaliy Margolen vitaliy@kievinfo.com 2009-01-18 15:13:07 --- Closing dup
http://bugs.winehq.org/show_bug.cgi?id=16997
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |UNCONFIRMED Resolution|DUPLICATE |
--- Comment #4 from Vitaliy Margolen vitaliy@kievinfo.com 2009-02-04 01:01:09 --- Then reopening this one. The bug 16932 is fixed.
http://bugs.winehq.org/show_bug.cgi?id=16997
--- Comment #5 from Caladan a.vankaam@chello.nl 2009-02-04 13:28:02 --- I have done a complete new regression test to be 100% sure between 1.1.12 marked as good and 1.1.13 marked as bad.
Again the regresion test came with the same result:
1deafcb5a758ba7c88e498718a3186d6b526fe71 is first bad commit commit 1deafcb5a758ba7c88e498718a3186d6b526fe71 Author: Stefan Dösinger stefan@codeweavers.com Date: Mon Dec 15 19:37:36 2008 +0100
wined3d: Split the remains of state_fog.
:040000 040000 39455d30afadc1d21664e6730064c5028aa2c3eb 91e5b3d98e7cd72aa61dd8eac1058792d5fce9a7 M dlls
I have found a nice spot where I placed a character and by turning the character a little I go from good to bad, this happens both in 1.1.13 as in 1.1.14.
I also attached 8 screenshots, notice the gold ring above the npc's head and if you can see it the smoke from the fireplace to the right:
1.1.12-view-1-good.jpg looking into direction 1 and no bug with wine 1.1.12 1.1.12-view-2-good.jpg looking into direction 2 and no bug with wine 1.1.12 1.1.13-regr-view-1-good.jpg looking into direction 1 and no bug with wine 1.1.13 after the regression run removed the above commit 1.1.13-regr-view-2-good.jpg looking into direction 2 and no bug with wine 1.1.13 after the regression run removed the above commit
1.1.13-view-1-good.jpg looking into direction 1 and no bug with wine 1.1.13 1.1.13-view-2-good.jpg looking into direction 2 bug shows wine 1.1.13 1.1.14-view-1-good.jpg looking into direction 1 and no bug with wine 1.1.14 1.1.14-view-2-good.jpg looking into direction 2 bug shows wine 1.1.14
as you can see both 1.1.13 and 1.1.14 are identical in their behavoir.
I can reproduce and/or test this on the fly as I just need to change, so if these is anything you want me to try please let me know.
Alex
http://bugs.winehq.org/show_bug.cgi?id=16997
Caladan a.vankaam@chello.nl changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #18791|0 |1 is obsolete| | Attachment #18796|0 |1 is obsolete| |
--- Comment #6 from Caladan a.vankaam@chello.nl 2009-02-04 13:36:32 --- Created an attachment (id=19241) --> (http://bugs.winehq.org/attachment.cgi?id=19241) screenshots wine 1.1.12
http://bugs.winehq.org/show_bug.cgi?id=16997
--- Comment #7 from Caladan a.vankaam@chello.nl 2009-02-04 13:37:11 --- Created an attachment (id=19242) --> (http://bugs.winehq.org/attachment.cgi?id=19242) screenshots wine 1.1.13 after regression run
http://bugs.winehq.org/show_bug.cgi?id=16997
--- Comment #8 from Caladan a.vankaam@chello.nl 2009-02-04 13:37:47 --- Created an attachment (id=19243) --> (http://bugs.winehq.org/attachment.cgi?id=19243) screenshots wine 1.1.13
http://bugs.winehq.org/show_bug.cgi?id=16997
--- Comment #9 from Caladan a.vankaam@chello.nl 2009-02-04 13:38:03 --- Created an attachment (id=19244) --> (http://bugs.winehq.org/attachment.cgi?id=19244) screenshots wine 1.1.14
http://bugs.winehq.org/show_bug.cgi?id=16997
--- Comment #10 from Rico kgbricola@web.de 2009-02-04 15:03:02 --- Please try the patches Stefan sent a while ago to wine-patches. These were 7 patches but only the first 3 were applied. The last 4 collide with other patches. So get the last 4 (4-7) and apply that. Here is the link to the first http://www.winehq.org/pipermail/wine-patches/2009-January/067950.html one. Does that solve your problem?
http://bugs.winehq.org/show_bug.cgi?id=16997
--- Comment #11 from Vitaliy Margolen vitaliy@kievinfo.com 2009-02-04 22:37:26 --- What format are those files in? If you attaching screenshot attach it in an image format one file per attachment! No extensions can't be opened directly with browser - 100% useless. The worst 1MB downloaded ever.
http://bugs.winehq.org/show_bug.cgi?id=16997
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression Summary|Graphical regression bug in |lotro: symbols above NPC's |lotro as of Win 1.1.13 |are totally black
http://bugs.winehq.org/show_bug.cgi?id=16997
Caladan a.vankaam@chello.nl changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #19241|0 |1 is obsolete| | Attachment #19242|0 |1 is obsolete| | Attachment #19243|0 |1 is obsolete| | Attachment #19244|0 |1 is obsolete| |
--- Comment #12 from Caladan a.vankaam@chello.nl 2009-02-05 09:43:29 --- Created an attachment (id=19263) --> (http://bugs.winehq.org/attachment.cgi?id=19263) screenshots wine 1.1.12
http://bugs.winehq.org/show_bug.cgi?id=16997
--- Comment #13 from Caladan a.vankaam@chello.nl 2009-02-05 09:43:53 --- Created an attachment (id=19264) --> (http://bugs.winehq.org/attachment.cgi?id=19264) screenshots wine 1.1.13 after regression
http://bugs.winehq.org/show_bug.cgi?id=16997
--- Comment #14 from Caladan a.vankaam@chello.nl 2009-02-05 09:44:16 --- Created an attachment (id=19265) --> (http://bugs.winehq.org/attachment.cgi?id=19265) screenshots wine 1.1.13
http://bugs.winehq.org/show_bug.cgi?id=16997
--- Comment #15 from Caladan a.vankaam@chello.nl 2009-02-05 09:44:35 --- Created an attachment (id=19266) --> (http://bugs.winehq.org/attachment.cgi?id=19266) screenshots wine 1.1.14
http://bugs.winehq.org/show_bug.cgi?id=16997
--- Comment #16 from Caladan a.vankaam@chello.nl 2009-02-05 09:46:46 --- (In reply to comment #11)
What format are those files in? If you attaching screenshot attach it in an image format one file per attachment! No extensions can't be opened directly with browser - 100% useless. The worst 1MB downloaded ever.
my apologies, they where .tar.gz, I removed them and added new once.
(In reply to comment #10)
Please try the patches Stefan sent a while ago to wine-patches. These were 7 patches but only the first 3 were applied. The last 4 collide with other patches. So get the last 4 (4-7) and apply that. Here is the link to the first http://www.winehq.org/pipermail/wine-patches/2009-January/067950.html one. Does that solve your problem?
will try that tonight and let you know
http://bugs.winehq.org/show_bug.cgi?id=16997
Caladan a.vankaam@chello.nl changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|lotro: symbols above NPC's |lotro: symbols above NPC's |are totally black |are totally black as is fog
--- Comment #17 from Caladan a.vankaam@chello.nl 2009-02-05 11:06:29 --- I sort of hit a dead end, the url posted no longer has the patches, they are "scrubbed" from the mail, I did find some of it on other sites and tried to work with that (copy and paste into a file then git-apply file) but to be honest I am lost, getting errors:
/wine-git> git-apply patch4of7.diff patch4of7.diff:24: trailing whitespace. if (This->cur_args->swizzle_map & (1 << reg)) is_color = TRUE; patch4of7.diff:34: trailing whitespace. struct vs_compile_args compile_args; patch4of7.diff:37: trailing whitespace. TRACE("Using vertex shader\n"); patch4of7.diff:38: trailing whitespace. find_vs_compile_args((IWineD3DVertexShaderImpl *) This->stateBlock->vertexShader, This->stateBlock, &compile_args); patch4of7.diff:39: trailing whitespace. priv->current_vprogram_id = find_gl_vshader((IWineD3DVertexShaderImpl *) This->stateBlock->vertexShader, &compile_args); error: dlls/wined3d/arb_program_shader.c : No such file or directory error: dlls/wined3d/baseshader.c : No such file or directory error: dlls/wined3d/glsl_shader.c : No such file or directory error: dlls/wined3d/vertexshader.c : No such file or directory error: dlls/wined3d/wined3d_private.h : No such file or directory
they there though:
/wine-git> ls dlls/wined3d/wined3d_private.h dlls/wined3d/wined3d_private.h
sorry to be so thick.
http://bugs.winehq.org/show_bug.cgi?id=16997
--- Comment #18 from Caladan a.vankaam@chello.nl 2009-02-06 12:10:27 --- Since both patch and git-apply refused to work against the current GiT, maybe because the original patches from Stefan where on 1.1.12 version, I manually added the patches 4/7 (version 2), 5/7, 6/7 and 7/7 to the current GiT, in total 6 files where changed, I saved them incase anybody wants them.
Compiliation was without errors but I am sad to say that the patches 4 to 7 made no diffrence, so seems something is still being skiped/goes wrong fog or shader wise with the changes made in 1.1.13.
http://bugs.winehq.org/show_bug.cgi?id=16997
knan-wine@anduin.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |knan-wine@anduin.net
--- Comment #19 from knan-wine@anduin.net 2009-02-07 20:45:41 --- I can confirm this one.
http://bugs.winehq.org/show_bug.cgi?id=16997
Caladan a.vankaam@chello.nl changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #20 from Caladan a.vankaam@chello.nl 2009-02-08 00:41:44 --- *** This bug has been confirmed by popular vote. ***
http://bugs.winehq.org/show_bug.cgi?id=16997
--- Comment #21 from Caladan a.vankaam@chello.nl 2009-02-10 12:03:23 --- Is there anything else I can do to figure out more about this regression bug ? I been looking through the original patch but I dont feel I an knowledge enough to adjust it to bug hunt.
Might it have to do with the lightsource since it changes depending on the angle/location your looking at it (npc stuff of general smoke) ?
Seem the fog or what ever it actually is, is just black and covering the normal texture of the object. I added a screenshot, it shows in this case the ring black but flames comming from the ring do show correct.
http://bugs.winehq.org/show_bug.cgi?id=16997
--- Comment #22 from Caladan a.vankaam@chello.nl 2009-02-10 12:03:56 --- Created an attachment (id=19365) --> (http://bugs.winehq.org/attachment.cgi?id=19365) same ring, diffrent angle
http://bugs.winehq.org/show_bug.cgi?id=16997
--- Comment #23 from Stefan Dösinger stefandoesinger@gmx.at 2009-02-10 12:27:52 --- I just sent 4 patches that might fix the problem. They finish the fog cleanup and fix the temporary regressions that were partially knowingly introduced.
http://bugs.winehq.org/show_bug.cgi?id=16997
--- Comment #24 from Caladan a.vankaam@chello.nl 2009-02-11 10:53:34 --- Hello Stefan
I d/l and applied the patches (4) last night to the git, this went without error but made no change, so to be sure I waited till today to refresh my git and again no changes.
http://bugs.winehq.org/show_bug.cgi?id=16997
--- Comment #25 from Caladan a.vankaam@chello.nl 2009-02-17 10:41:49 --- Wine 1.1.15 still has the same issue, is there anything else I can do to provide you with some more information ?
http://bugs.winehq.org/show_bug.cgi?id=16997
--- Comment #26 from Stefan Dösinger stefandoesinger@gmx.at 2009-02-17 17:44:35 --- I really hoped this would be fixed by the patches I sent earlier. Can you attach a +d3d,d3d_shader log? I am afraid I won't see much though, because it is pretty hard/impossible to find the place where the ring is rendered from the log. We have lotro around at CodeWeavers, maybe I can get it set up to test this myself.
http://bugs.winehq.org/show_bug.cgi?id=16997
--- Comment #27 from Caladan a.vankaam@chello.nl 2009-02-18 12:28:44 --- Hello Stefan
the log is pretty huge, used fixme-all,+d3d,+d3d_shader, you can get it here: http://members.chello.nl/~a.vankaam/lotro/lotro-wine1.1.15.log.bz2 If you could let me know once you d/l it, am a bit close to my limit :)
I did a wc -l so you atleast know where to look, if thats even possible with so much info:
line 4883413 the game was finished loading and my selected character was at his test spot looking at a "gold" ring. line 9044791 I turned a bit to the right and the ring changed to a "black" ring. line 12088976 I turned back a bit to the left and the ring changed to a "gold" ring.
If there is anything I can do to get your version running just mail me, my test char is a human champion, in tutorial I talked to the 1st npc to skip it and was ported to the starting town of Archet in which there is lots of smoke and NPC's with rings.
ps: fog and smoke also go wrong but ring is easiest to show
http://bugs.winehq.org/show_bug.cgi?id=16997
--- Comment #28 from Stefan Dösinger stefandoesinger@gmx.at 2009-02-19 16:12:34 --- Prince of Persia the sands of time has a similar fog regression in the same patchset, and there is a freely available demo. I'll take a look at this game first and see what is wrong there. Maybe the fix for POPSOT fixes lotro too.
http://bugs.winehq.org/show_bug.cgi?id=16997
--- Comment #29 from Caladan a.vankaam@chello.nl 2009-02-20 07:17:45 --- okay, although the POPSOT seemed to be okay till 1.1.14, but will keep an eye on it and any patch posted there.
http://bugs.winehq.org/show_bug.cgi?id=16997
--- Comment #30 from Caladan a.vankaam@chello.nl 2009-02-22 01:13:21 --- Hello Stefan,
I saw the patch on POPSOT and applied it to todays GIT, that made no diffrence, you did mention in the POPSOT thread that the same could be applied to the arb shader so I did that:
if(args->fog_src == VS_FOG_Z) { if(!reg_maps->fog) { shader_addline(buffer, "MOV result.fogcoord = TMP_OUT.z;\n"); } else { FIXME("Shader writes fog coord and table fog is used\n"); } } else if (!reg_maps->fog) { shader_addline(buffer, "MOV result.fogcoord, 0.0;\n"); }
but that also did not change anything. from what I can gather from the POPSOT issue is that its always like that, this LOTRO issue is only from certain angles/distance.
http://bugs.winehq.org/show_bug.cgi?id=16997
Stefan Dösinger stefandoesinger@gmx.at changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stefandoesinger@gmx.at
--- Comment #31 from Stefan Dösinger stefandoesinger@gmx.at 2009-02-22 06:10:11 --- Yeah, I think the issues are different.
The POPSOT bug smells like a "bug" in the game, worked around by game specific fixes in the Windows drivers. This here is more likely a genuine Wine bug.
http://bugs.winehq.org/show_bug.cgi?id=16997
Stefan Dösinger stefandoesinger@gmx.at changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|stefan@codeweavers.com |
http://bugs.winehq.org/show_bug.cgi?id=16997
--- Comment #32 from Stefan Dösinger stefandoesinger@gmx.at 2009-02-22 07:34:31 --- Created an attachment (id=19607) --> (http://bugs.winehq.org/attachment.cgi?id=19607) Debug hack
Does the attached patch fix the problem? If yes, it is most likely a problem with calling the state application functions. If it doesn't, it is most likely a bug in one of the application functions itself.
http://bugs.winehq.org/show_bug.cgi?id=16997
--- Comment #33 from Caladan a.vankaam@chello.nl 2009-02-22 07:55:41 --- removed POPSOT patch, applied debug hack to current GIT, made no diffrence, sorry.
http://bugs.winehq.org/show_bug.cgi?id=16997
--- Comment #34 from Stefan Dösinger stefandoesinger@gmx.at 2009-02-22 08:56:26 --- Nothing to be sorry about - those state dependency issues are tricky to debug and sometimes ugly to fix. In fact the patchset that the regression causing patch was part of was an attempt to fix troubles with the fog state dependencies.
Otoh I have to find something else now.
http://bugs.winehq.org/show_bug.cgi?id=16997
--- Comment #35 from Stefan Dösinger stefandoesinger@gmx.at 2009-02-22 09:07:21 --- What happens if you change select_fragment_implementation in directx.c to always return ffp_fragment_pipeline ? (This disables the ARBFP fragment pipeline replacement)
http://bugs.winehq.org/show_bug.cgi?id=16997
--- Comment #36 from Caladan a.vankaam@chello.nl 2009-02-22 10:49:32 --- I have limited C knowledge, but I asume you mean:
static const struct fragment_pipeline *select_fragment_implementation(UINT Adapter, WINED3DDEVTYPE DeviceType) { int vs_selected_mode; int ps_selected_mode;
return &ffp_fragment_pipeline;
/* select_shader_mode(&GLINFO_LOCATION, DeviceType, &ps_selected_mode, &vs_selected_mode); if((ps_selected_mode == SHADER_ARB || ps_selected_mode == SHADER_GLSL) && GL_SUPPORT(ARB_FRAGMENT_PROGRAM)) { return &arbfp_fragment_pipeline; } else if(ps_selected_mode == SHADER_ATI) { return &atifs_fragment_pipeline; } else if(GL_SUPPORT(NV_REGISTER_COMBINERS) && GL_SUPPORT(NV_TEXTURE_SHADER2)) { return &nvts_fragment_pipeline; } else if(GL_SUPPORT(NV_REGISTER_COMBINERS)) { return &nvrc_fragment_pipeline; } else { return &ffp_fragment_pipeline; } */ }
This fixes the icons above the npc and smoke from all angles and distance, however it gives a few new issues, codemaster logo movie is black, background at char select is black, underside of clouds in the sky is black. But I am guess that does not mather as this points you to ARBFP and that is what you wanted to know ?
http://bugs.winehq.org/show_bug.cgi?id=16997
--- Comment #37 from knan-wine@anduin.net 2009-02-22 10:55:16 --- (In reply to comment #35)
What happens if you change select_fragment_implementation in directx.c to always return ffp_fragment_pipeline ? (This disables the ARBFP fragment pipeline replacement)
In my case, that causes an almost black blur/fog overlaid over everything.
I have an interesting screenshot, will add...
http://bugs.winehq.org/show_bug.cgi?id=16997
--- Comment #38 from knan-wine@anduin.net 2009-02-22 11:00:17 --- Created an attachment (id=19608) --> (http://bugs.winehq.org/attachment.cgi?id=19608) screenshot w/return &ffp_fragment_pipeline
(Without debug hack, only with the return &ffp_fragment_pipeline hack suggested)
Those clear strips must be the game/graphics being mid-update, I didn't see any clear strips in-game.
http://bugs.winehq.org/show_bug.cgi?id=16997
--- Comment #39 from Caladan a.vankaam@chello.nl 2009-02-22 11:04:57 --- @Knan,
I got a normal play screen, just the mentioned no movie, black background on char select and black underneath clouds.
@Stefan,
experimented a tad more with this since there are more options (depending on your gfx card I think ?):
&arbfp_fragment_pipeline; &atifs_fragment_pipeline; &nvts_fragment_pipeline; &nvrc_fragment_pipeline; &ffp_fragment_pipeline;
it's enough to replace "return &arbfp_fragment_pipeline;" with "return &ffp_fragment_pipeline;", thus eliminating the others. gives the same result as I previously mentioned, so seems &arbfp_fragment_pipeline; is where to search.
http://bugs.winehq.org/show_bug.cgi?id=16997
--- Comment #40 from Caladan a.vankaam@chello.nl 2009-02-22 11:07:35 --- sorry to spam, @Knan, if you turn of post-proccessing in the adv-graphics you get a more normal screen with working icons above the npc and smoke. just the black underside of clouds.
http://bugs.winehq.org/show_bug.cgi?id=16997
--- Comment #41 from knan-wine@anduin.net 2009-02-22 11:15:27 --- Ah. I can confirm that the ffp_fragment_pipeline hack fixes the black symbols, but breaks the post-processing blur filter horribly if that's enabled in the game's graphics settings. With the blur filter disabled, things look fine.
http://bugs.winehq.org/show_bug.cgi?id=16997
--- Comment #42 from Stefan Dösinger stefandoesinger@gmx.at 2009-02-22 12:02:51 --- Caladan, thanks for testing this. This helps to pinpoint the problem.
Yes, as you have noticed, there are multiple fixed function fragment pipeline implementations, tailored for specific feature levels of graphics cards.
arbfp_fragment_pipeline: Everything that supports GL_ARB_fragment_program(~ d3d shader model 2.0). Newer intel cards, Geforce 5+, ATI r300+ (radeon 9500+)
atifs_fragment_pipeline: uses GL_ATI_fragment_shader, radeon 8500 - 9200
nvts_fragment_pipeline: Uses GL_NV_register_combiners and GL_NV_texture_shader, geforce 3 and 4
nvrc_fragment_pipeline: uses only GL_NV_register_combiners. I think TNT2 to Geforce 2
ffp_fragment_pipeline: The rest. Basically pre-8500 radeons. Uses GL_ARB_texture_env_combine
Strictly speaking we're lacking a GL 1.2 core fixed function pipeline, but cards that do not at least support GL_ARB_texture_env_combine are pretty rare. The only card I know that doesn't support this extension is my old ATI Mach64 card.
arbfp is the only 100% feature-complete pipeline implementation. nvts and atifs are almost perfect, they're missing D3DTOP_BUMPENVMAPLUMINANCE support. It could be implemented in nvts. In atifs maybe too, although its a rather tough call because of the instruction limitations. nvrc is missing D3DTOP_BUMPENVMAPLUMINANCE and D3DTOP_BUMPENVMAP because the HW doesn't support it(not even on Windows). The FFP pipeline is missing quite a number of features, like the bump mapping operations, TSSARGTEMP, secondary color input. These features are important in a number of games, so we try to avoid this backend if possible(even at the cost of writing card-specific backends like nvts and atifs).
http://bugs.winehq.org/show_bug.cgi?id=16997
--- Comment #43 from Stefan Dösinger stefandoesinger@gmx.at 2009-02-23 16:52:51 --- I looked over the code and the patch and found ... nothing.
I can't find anything that would explain a fog bug that affects the ARB ffp replacement but not the fixed function one and is caused by this patch. Can someone repeat the regression test to make sure we're not hunting a regression in a wrong patch?
The only other clue: Does the old(working) code write a fixme about using table fog with a shader?
http://bugs.winehq.org/show_bug.cgi?id=16997
--- Comment #44 from Stefan Dösinger stefandoesinger@gmx.at 2009-02-23 17:34:21 --- Can you try this patch? : http://www.winehq.org/pipermail/wine-patches/2009-February/069822.html
I don't know if it will help, but I think it was a problem introduced with one of the fog patches. I had it in my tree for quite a while, and that would explain why I didn't see any problematic differences between the old and the new code.
http://bugs.winehq.org/show_bug.cgi?id=16997
--- Comment #45 from knan-wine@anduin.net 2009-02-23 17:53:05 --- (In reply to comment #44)
Can you try this patch? : http://www.winehq.org/pipermail/wine-patches/2009-February/069822.html
Didn't help, at least not on its own.
http://bugs.winehq.org/show_bug.cgi?id=16997
--- Comment #46 from Caladan a.vankaam@chello.nl 2009-02-24 13:25:35 --- Hello Stefan
as Knan said the patch did not change a thing.
if I use 1.1.12 to play there are no fixme related to shaders, I will attach the log.
did a new regresion between 1.1.12 and 1.1.15, 861 revisions :) and it came up again with:
1deafcb5a758ba7c88e498718a3186d6b526fe71 is first bad commit commit 1deafcb5a758ba7c88e498718a3186d6b526fe71 Author: Stefan Dösinger stefan@codeweavers.com Date: Mon Dec 15 19:37:36 2008 +0100
wined3d: Split the remains of state_fog.
:040000 040000 39455d30afadc1d21664e6730064c5028aa2c3eb 91e5b3d98e7cd72aa61dd8eac1058792d5fce9a7 M dlls
I played a bit with the original patch and specificly the arb_program_shader.c, the original patch had basicly 2 changes in there, lot of new code at "static void state_arbfp_fog" and 2 lines at "static void textransform".
I removed the whole set of new code in "static void state_arbfp_fog" and there was no diffrence, so placed it back.
then removed the 2 lines at "static void textransform" (the FOGSTART en FOGEND lines). Only diffrence for the fog/icons was that black was still black but gold was now dark grey. So probably useless info this.
Anyways, just turning 1 pixel is enough to make it change. It's like the fog/smoke loses it's transparency and/or color and just turns pitch black thus obscuring what ever is behind it.
It is easiest to explain in 3rd person view in game, If you if you take a compass:
from around 10 degree's turning clockwise to 190 degree's all is ok, from 190 degree's turning clockwise to 10 degree's fog/icons are black, this goes for all fog/icons infront of me, beside me, behind me and far away in the distance. Stepping side way and looking at a fixed direction, so the fog/icons infront of me moves left or right of me, does not mather, its really the direction of the camera.
The height of your camera changes it a bit as does 1st person view but in general looking east (270 degree) the fog is black.
I made a recording with "Record my desktop" to show you what I mean, it isnt that great but should show you what I mean, you can see 2 icons close and 2 in the distance, all go black at the same time when I turn and gold again, all depending on my direction, side stepping does not effect it, only turning. I will attach is also (if not to big else post it) hope it helps you a bit further.
http://bugs.winehq.org/show_bug.cgi?id=16997
--- Comment #47 from Caladan a.vankaam@chello.nl 2009-02-24 13:26:20 --- Created an attachment (id=19628) --> (http://bugs.winehq.org/attachment.cgi?id=19628) wine 1.1.12 log file without fixme-all
http://bugs.winehq.org/show_bug.cgi?id=16997
--- Comment #48 from Caladan a.vankaam@chello.nl 2009-02-24 13:36:29 --- video showing it: http://members.chello.nl/~a.vankaam/lotro/lotro-showing-bug.ogv
if you can let me know when you seen it so can delete (space and all that)
http://bugs.winehq.org/show_bug.cgi?id=16997
--- Comment #49 from Rico kgbricola@web.de 2009-02-24 13:39:34 --- Is there a demo/trial available which has the same problem?
http://bugs.winehq.org/show_bug.cgi?id=16997
--- Comment #50 from Stefan Dösinger stefandoesinger@gmx.at 2009-02-24 13:46:30 --- I tried to download the game today(since we have a lotro account here at codeweavers), but the download failed when I accidentally turned my laptop's wlan off. The server refused to let me resume the download unfortunately. I'll give it another try over the night and see what happens.
http://bugs.winehq.org/show_bug.cgi?id=16997
--- Comment #51 from Caladan a.vankaam@chello.nl 2009-02-24 14:00:33 --- Codemasters has a 2 week trail offer:
http://www.codemasters.co.uk/trylotro/trialkey.php?territory=EnglishUK
Game does require some tricks to get working correct, easiest way is to install under windows (real or virtual) and simply copy it over to Linux. Wine requiers wintricks vcrun2005 and vcrun2005sp1 since last expansion of the game.
All described at http://appdb.winehq.org/objectManager.php?sClass=version&iId=14566
The best way to test it is like this:
login, make a human char, select captain, give him a name, enter game, double click the 1st npc (amdir), select Skip now, select a reward and press finish. Then you end up in Archet, that area shows it all best.
other starting area's are more bright (less fog ?) and you see it happen less there.
http://bugs.winehq.org/show_bug.cgi?id=16997
--- Comment #52 from Stefan Dösinger stefandoesinger@gmx.at 2009-02-26 13:16:23 --- So finally the download succeeded, but the zipfile was corrupted somewhere. Another try today...
http://bugs.winehq.org/show_bug.cgi?id=16997
hash HASH.DuOrden@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |HASH.DuOrden@gmail.com
--- Comment #53 from hash HASH.DuOrden@gmail.com 2009-03-03 04:47:44 --- It might help or might not but I have found something interesting about this bug. I'm runnig Gentoo and have wine installed (just for dependances to be updated) but never before I used installed one, instead I'm using git version(checking regularly and monitoring rss of git), but recently my friend asked me to check the "release" versions and I've found out that all release starting from 1.1.13 have that bug, but! Non of the git snapshots from corresponding release have this bug!
http://bugs.winehq.org/show_bug.cgi?id=16997
--- Comment #54 from Stefan Dösinger stefandoesinger@gmx.at 2009-03-03 05:34:46 --- Now that sounds odd. The only difference I can imagine are compile flags. Maybe you compiled one yourself, and the other with emerge?
If it is a matter of compile flags, this is probably and uninitialized variable. Which might be in Wine, or in the 3D driver.
A wild guess of something the patch changed: Can you try to replace the glFogf() with glFogfv()? The patch replaced the old glFogfv call with glFogf because there was no need to pass a 32 or 64 bit pointer instead of the 32 bit float value. But there might be a bug in the non-pointer version of that call. (happened in the GLSL uniform setting code some time ago)
http://bugs.winehq.org/show_bug.cgi?id=16997
--- Comment #55 from hash HASH.DuOrden@gmail.com 2009-03-03 07:25:44 --- I've tried something different, yes, in emerege there is some ./configure flags so I've tried to simply compile from source with same flags I use normally (i.e. no flags :) ) and wonder-oh-wonder, the very same bug is appeared! So to summarize: If I git fetch&&./configure --prefix=/opt/wine&&make install then no bug. If I unpack from wine-1.1.16.tar.bz2 and... ./configure --prefix=/opt/wine&&make install Then bug present!
http://bugs.winehq.org/show_bug.cgi?id=16997
--- Comment #56 from hash HASH.DuOrden@gmail.com 2009-03-03 07:26:46 --- Lats thing that comes in my mind is to diff git tag 1.1.16 with wine-1.1.16.tar.bg2?..
http://bugs.winehq.org/show_bug.cgi?id=16997
--- Comment #57 from Caladan a.vankaam@chello.nl 2009-03-04 11:00:22 --- (In reply to comment #56)
Lats thing that comes in my mind is to diff git tag 1.1.16 with wine-1.1.16.tar.bg2?..
I refresh and use the git since this issue daily, just to see if something might change, also have the normal 1.1.16 installed via the suse repo and tested the daily build from the suse repo but all 3 give the same result, so I cant really place this.
Only diffrent is I run the git from /home/user/wine-git/wine and not really install it (for suse /usr/bin/wine) but doubt that makes a diffrence ?
http://bugs.winehq.org/show_bug.cgi?id=16997
--- Comment #58 from Caladan a.vankaam@chello.nl 2009-03-04 11:16:54 --- (In reply to comment #56)
Lats thing that comes in my mind is to diff git tag 1.1.16 with wine-1.1.16.tar.bg2?..
out of curiosity, removed wine from the suse repo, git fetch ; git rebase origin ./configure make sudo make install
so got the wine from the git into /usr/local/lib/wine and /usr/local/bin/, but shows the exact same bug, sorry :)
http://bugs.winehq.org/show_bug.cgi?id=16997
--- Comment #59 from hash HASH.DuOrden@gmail.com 2009-03-05 04:52:37 --- Hmm, then we have an extreme tricky bug here. I have unique ability to compare it's presence and absence on same computer, but I have no idea on how to track it's origin on my own, other then regression test and/or diff git tag 1.1.16 against 1.1.16 release. If any one have an ideas on what I should do to find the cause I'd like to hear them.
http://bugs.winehq.org/show_bug.cgi?id=16997
--- Comment #60 from Rico kgbricola@web.de 2009-03-05 07:09:15 ---
git fetch&&./configure --prefix=/opt/wine&&make install
Please run the commands correctly. Git fetch doesn't update the source files! It only get a copy of the source in the gitdb. You have to run "git rebase origin" or something afterwards (see http://wiki.winehq.org/GitWine ).
Also please verify the version you are running with a call to "wine --version && wine game.exe" (or /path/to/builddir/wine --version && /path/to/builddir/wine game.exe" if you run it directly from the build directory without make install) to see if you are running the version you like to test and not the wrong one.
http://bugs.winehq.org/show_bug.cgi?id=16997
--- Comment #61 from hash HASH.DuOrden@gmail.com 2009-03-06 10:08:20 --- Ok, now I've got where I was mistaken, I haven't done "git rebase origin" for a very long time, sorry to everyone who I've got in wrong direction, I haven't understood "man git" too well (and still I'm) and thank you for pointing that for me. I think it'll be better to remove all my comments concerning git-release differences so that no one will get into such dumb(of me) thinking.
The only thing still eludes me is why winecfg reported last correct version even thought I didn't "git rebase origin"?
I'm still have a backup of that wine installation (it is appears as 1.1.12-393-ga69c86d as a response for wine --version) and if I start winecfg from there "About" page it report that it is 1.1.16, can any one enlighten me on that strangeness?
And as a last thing to say that now I have this bug in all versions of wine.
http://bugs.winehq.org/show_bug.cgi?id=16997
Adrian erandel_gl@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |erandel_gl@yahoo.com
--- Comment #62 from Adrian erandel_gl@yahoo.com 2009-03-31 09:27:39 --- Tested with 1.1.18
The good news is that the errors about unknown textures from console output are gone. Also this seems to have fixed the problems that occurred with alt+tab from full screen mode. With version 1.1.16 there was a message every time the window was minimized. After several changes the game would grind to a halt, but now that seems to be fixed.
The black icons over the vendor/trainer heads are still there. Nothing has changed there. I'm not sure but it might be a z-buffer problem because if I change the angle of the camera, the icons are visible in some positions.
Also the icons you use to mark monster when you are in a fellowship have the same problem. The shape is right but it has only a black color.
http://bugs.winehq.org/show_bug.cgi?id=16997
--- Comment #63 from Caladan a.vankaam@chello.nl 2009-04-06 10:00:10 --- Upgraded nvidia drivers from 177.82 tp 180.37 a while back but that made no diffrence.
Upgraded nvidia drivers from 180.37 to 180.44 last weekend and that black icons/fog/smoke is now grey/very light blue but still there.
http://bugs.winehq.org/show_bug.cgi?id=16997
Alan Jackson ajackson@bcs.org.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ajackson@bcs.org.uk
http://bugs.winehq.org/show_bug.cgi?id=16997
Eric Sandall sandalle@sourcemage.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sandalle@sourcemage.org
--- Comment #64 from Eric Sandall sandalle@sourcemage.org 2009-05-15 21:02:09 --- Still an issue with WINE 1.1.21 and nvidia_driver 180.60. Up close, the quest rings display correctly (gold colour), but further away, or at certain angles, they have a whitish/blue colour.
http://bugs.winehq.org/show_bug.cgi?id=16997
--- Comment #65 from Caladan a.vankaam@chello.nl 2009-06-06 00:47:08 --- tried the new nividia driver 185.18.14, only diffrence between that and 180.60 that I was running before it is that the fog/icons in question are black again instead of white/blue-isch.
so in my case (wine 1.1.22):
177.82 - black 180.37 - black 180.44 - white 180.60 - white 185.18.14 - black
for the rest nothing has changed.
http://bugs.winehq.org/show_bug.cgi?id=16997
rockrobban@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |rockrobban@gmail.com
--- Comment #66 from rockrobban@gmail.com 2009-07-08 18:03:09 --- The black icons dissappear in the VERY unofficial 190.x drivers. However, with these drivers lotro crash more frequently, so I would not recommend updating jsut yet.
http://bugs.winehq.org/show_bug.cgi?id=16997
--- Comment #67 from Caladan a.vankaam@chello.nl 2009-07-09 09:43:20 --- very intresting, btw you sure the 190 driver cause the crashes and not wine 1.1.25, as there seems to be regression in that one (http://bugs.winehq.org/show_bug.cgi?id=19221)
http://bugs.winehq.org/show_bug.cgi?id=16997
--- Comment #68 from Rizzly rockrobban@gmail.com 2009-07-09 10:57:26 --- No, I have tried with both .24 and .25.
In .24 compiz crashes (porbably because of x?) and the computer jumps back to the metacity window handler. Lotro does not crash itself, unless I have post-processing effects enabled. I get the impression that post-processing actually might be working (think drunk-, and dreadeffects etc.) and that is what makes lotro crash.
In .25 I get the random crashes, but it actually seems like 190 is not the problem there (I have not gotten to trying out my theory about post-processing effects here).
http://bugs.winehq.org/show_bug.cgi?id=16997
Sascha Berg berg.sascha@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |berg.sascha@web.de
--- Comment #69 from Sascha Berg berg.sascha@web.de 2009-07-21 14:13:52 --- With the new nvidia-driver 190.16 is this fault gone for me. Can confirm this anyone ? Mfg
http://bugs.winehq.org/show_bug.cgi?id=16997
Andrzej Kardaś andrzej.kardas@kardasa.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |andrzej.kardas@kardasa.pl
--- Comment #70 from Andrzej Kardaś andrzej.kardas@kardasa.pl 2009-07-30 01:30:59 --- (In reply to comment #69)
With the new nvidia-driver 190.16 is this fault gone for me. Can confirm this anyone ? Mfg
I can confirm with latest nvidia driver (190.18) in portage tree (Gentoo Linux) the problem no longer exist. Wine 1.1.26.
http://bugs.winehq.org/show_bug.cgi?id=16997
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #71 from Austin English austinenglish@gmail.com 2009-07-30 10:29:58 --- Reported fixed.
http://bugs.winehq.org/show_bug.cgi?id=16997
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #72 from Alexandre Julliard julliard@winehq.org 2009-08-07 12:37:07 --- Closing bugs fixed in 1.1.27.
-
wine-bugs＠winehq.org