https://bugs.winehq.org/show_bug.cgi?id=45375
Bug ID: 45375 Summary: Halo Online: Weird black display problems. Product: Wine Version: 3.10 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-d3d Assignee: wine-bugs@winehq.org Reporter: conmanx360@gmail.com Distribution: ---
This issue happens on certain maps in Halo Online depending on what your current Z position is. Not all maps suffer from it, only certain ones do. If you're above the Z position that it begins happening at, everything below renders normally, but once you go below it, a portion of the frame becomes black. It seems to be in a pattern. Not all objects are blacked out, either. So there must be some sort of "priority".
Image examples here: https://imgur.com/a/176i4xr
https://bugs.winehq.org/show_bug.cgi?id=45375
Connor McAdams conmanx360@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |conmanx360@gmail.com Distribution|--- |Ubuntu
https://bugs.winehq.org/show_bug.cgi?id=45375
--- Comment #1 from Connor McAdams conmanx360@gmail.com --- Forgot to mention, there's a setting in the in-game editor that sets the level of fog effect. If you turn it down to 0, the issue goes away.
https://bugs.winehq.org/show_bug.cgi?id=45375
--- Comment #2 from Connor McAdams conmanx360@gmail.com --- After some digging through apitrace, I have found the source of the problem, although I do not fully know what to do with that information. Basically, your current position is stored into a a uniform value for the vertex shader, and when your Z position goes below 0, this stuff starts happening. In apitrace, editing out this portion of the shader fixes the issue, but of course that can't really be translated into the game in any way.
https://bugs.winehq.org/show_bug.cgi?id=45375
--- Comment #3 from Connor McAdams conmanx360@gmail.com --- This is due to a division by 0 in the conversion of an RCP function to GLSL. D3D9 handles inf and NaN differently than OpenGL, so to fix it, that issue will need to be resolved. However, as a temporary hack, you can do this:
in the file glsl_shader.c, function "shader_glsl_scalar_op", at the bottom, replace the regular else with: else { shader_addline(buffer, "%s%s%s);\n", prefix, src0_param.param_str, suffix); if (ins->handler_idx == WINED3DSIH_RCP) { struct glsl_dst_param dst_param; shader_glsl_add_dst_param(ins, &ins->dst[0], &dst_param); shader_addline(buffer, "%s%s = ((isinf(%s%s)) ? 0.0 : %s%s);\n", dst_param.reg_name, dst_param.mask_str, dst_param.reg_name, dst_param.mask_str, dst_param.reg_name, dst_param.mask_str); } }
This will add a check after every RCP conversion. It works fine for me, and doesn't seem to effect performance much. However, this is a hack. Not sure if it will cause issues in other games.
https://bugs.winehq.org/show_bug.cgi?id=45375
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |STAGED Ever confirmed|0 |1 CC| |leslie_alistair@hotmail.com Staged patchset| |https://github.com/wine-sta | |ging/wine-staging/tree/mast | |er/patches/wined3d-Improved | |-RCP_Support
https://bugs.winehq.org/show_bug.cgi?id=45375
Gijs Vermeulen gijsvrm@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|STAGED |NEW
--- Comment #4 from Gijs Vermeulen gijsvrm@gmail.com --- Staging patch was removed, removing STAGED status.
https://bugs.winehq.org/show_bug.cgi?id=45375
Paul Gofman gofmanp@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gofmanp@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=45375
halome halome@blockchainworldawards.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |halome@blockchainworldaward | |s.com
--- Comment #5 from halome halome@blockchainworldawards.com --- In wine 4.15, this issue occurs often. In 4.15-staging it only happens when the player goes below the 0 z axis.
https://bugs.winehq.org/show_bug.cgi?id=45375
--- Comment #6 from Paul Gofman gofmanp@gmail.com --- Can you please test it with Wine Staging 4.16 and multiply_special registry set to 1 and to 2? Some details related to the option are here: https://bugs.winehq.org/show_bug.cgi?id=34266#c34
https://bugs.winehq.org/show_bug.cgi?id=45375
--- Comment #7 from halome halome@blockchainworldawards.com --- I used wine 4.16 and added the multiply_special value to the registry. When it as set to 1 it did nothing but when it was set to 2 it seemed to remove most of the black texture issues.
I tested this in Diamondback and once I set the multiply_special to 2 the only graphical issues I got was some texture shredding especally as I headed toward the cliff on Diamondback and the cliff had some texture issues. Also my crosshair would have a black oval now and them but nevertheless major improvements.
https://bugs.winehq.org/show_bug.cgi?id=45375
--- Comment #8 from halome halome@blockchainworldawards.com --- I did some more testing. If I launched the game and load Diamondback there is not black texture issue. After I loaded Edge and in Edge there was that black texture issue and then when I load Diamondback again the black texture issue reappears again. It seems once the black texture issue gets triggered it will remain until the game process is closed.
https://bugs.winehq.org/show_bug.cgi?id=45375
--- Comment #9 from Paul Gofman gofmanp@gmail.com --- (In reply to halome from comment #8)
I did some more testing. If I launched the game and load Diamondback there is not black texture issue. After I loaded Edge and in Edge there was that black texture issue and then when I load Diamondback again the black texture issue reappears again. It seems once the black texture issue gets triggered it will remain until the game process is closed.
Can you please choose some specific glitch and attach the output with WINEDEBUG=+d3d9,+d3d,+d3d_shader environment variable set, recorded from start? The log will be huge, but they are compressed well. If that appears absolutely not possible (if you have to run the game long enough to reproduce and the log is impossibly huge), could you please get at least WINEDEBUG=warn+d3d9,warn+d3d,+d3d_shader?
https://bugs.winehq.org/show_bug.cgi?id=45375
--- Comment #10 from Connor McAdams conmanx360@gmail.com --- (In reply to Paul Gofman from comment #9)
(In reply to halome from comment #8)
I did some more testing. If I launched the game and load Diamondback there is not black texture issue. After I loaded Edge and in Edge there was that black texture issue and then when I load Diamondback again the black texture issue reappears again. It seems once the black texture issue gets triggered it will remain until the game process is closed.
Can you please choose some specific glitch and attach the output with WINEDEBUG=+d3d9,+d3d,+d3d_shader environment variable set, recorded from start? The log will be huge, but they are compressed well. If that appears absolutely not possible (if you have to run the game long enough to reproduce and the log is impossibly huge), could you please get at least WINEDEBUG=warn+d3d9,warn+d3d,+d3d_shader?
I might be incorrect, but if I remember correctly, this may be due to there being not enough memory. The software decompression of DXT5 3D textures takes quite a bit of space, and with Halo Online being a 32-bit executable, it already brings us pretty close to the 32-bit memory limit.
A log should figure it out, but you may be running into the problem of lack of memory instead of a shader problem.
https://bugs.winehq.org/show_bug.cgi?id=45375
--- Comment #11 from Paul Gofman gofmanp@gmail.com --- Created attachment 65314 --> https://bugs.winehq.org/attachment.cgi?id=65314 Hack to use 4GB memory
If this is a virtual memory exhaustion issue, then there is a chance it can be worked around by an attached hack (the patch in the present form is taken from Proton). The game should be run with WINE_LARGE_ADDRESS_AWARE=1 environment variable in this case.
But it would really be nice to see the log.
https://bugs.winehq.org/show_bug.cgi?id=45375
--- Comment #12 from halome halome@blockchainworldawards.com --- Created attachment 65321 --> https://bugs.winehq.org/attachment.cgi?id=65321 log
Here is a log of me without the WINEDEBUG=+d3d9,+d3d,+d3d_shader environment variable. I will post another log once I figure out how to use these sharers.
In this test run I loaded the Diamondback map, Edge map, and the Icebox and had no issues. Then I loaded Reactor and I got this white texture issue essentially the same thing but instead of black most of the map was white. Then I loaded Diamonback again and the map textures was black. I can see this being some memory issue but I am no expert.
https://bugs.winehq.org/show_bug.cgi?id=45375
--- Comment #13 from halome halome@blockchainworldawards.com --- Created attachment 65322 --> https://bugs.winehq.org/attachment.cgi?id=65322 log
I made a log by using doing this in my terminal. I hope this got the shaders to work.
env WINEPREFIX="/home/user/PlayOnLinux's virtual drives/HaloOnline" wine "C:\windows\command\start.exe" /Unix "/home/user/PlayOnLinux's virtual drives/HaloOnline/drive_c/Halo Online/eldorado.exe" &> haloonline.txt WINEDEBUG=warn+d3d9,warn+d3d,+d3d_shader
In this test I loaded Diamondback, Reactor, Sandtrap and then Diamondback again. All was fine until I loaded Sandtrap that is when the black texures appeared.
Reactor does have some texture issues too but not black textures.
https://bugs.winehq.org/show_bug.cgi?id=45375
--- Comment #14 from Connor McAdams conmanx360@gmail.com --- (In reply to halome from comment #13)
Created attachment 65322 [details] log
I made a log by using doing this in my terminal. I hope this got the shaders to work.
env WINEPREFIX="/home/user/PlayOnLinux's virtual drives/HaloOnline" wine "C:\windows\command\start.exe" /Unix "/home/user/PlayOnLinux's virtual drives/HaloOnline/drive_c/Halo Online/eldorado.exe" &> haloonline.txt WINEDEBUG=warn+d3d9,warn+d3d,+d3d_shader
In this test I loaded Diamondback, Reactor, Sandtrap and then Diamondback again. All was fine until I loaded Sandtrap that is when the black texures appeared.
Reactor does have some texture issues too but not black textures.
Yep, memory allocation issues at line 14204 and 19071.
https://bugs.winehq.org/show_bug.cgi?id=45375
--- Comment #15 from Connor McAdams conmanx360@gmail.com --- (In reply to Connor McAdams from comment #14)
(In reply to halome from comment #13)
Created attachment 65322 [details] log
I made a log by using doing this in my terminal. I hope this got the shaders to work.
env WINEPREFIX="/home/user/PlayOnLinux's virtual drives/HaloOnline" wine "C:\windows\command\start.exe" /Unix "/home/user/PlayOnLinux's virtual drives/HaloOnline/drive_c/Halo Online/eldorado.exe" &> haloonline.txt WINEDEBUG=warn+d3d9,warn+d3d,+d3d_shader
In this test I loaded Diamondback, Reactor, Sandtrap and then Diamondback again. All was fine until I loaded Sandtrap that is when the black texures appeared.
Reactor does have some texture issues too but not black textures.
Yep, memory allocation issues at line 14204 and 19071.
(In reply to halome from comment #13)
Created attachment 65322 [details] log
I made a log by using doing this in my terminal. I hope this got the shaders to work.
env WINEPREFIX="/home/user/PlayOnLinux's virtual drives/HaloOnline" wine "C:\windows\command\start.exe" /Unix "/home/user/PlayOnLinux's virtual drives/HaloOnline/drive_c/Halo Online/eldorado.exe" &> haloonline.txt WINEDEBUG=warn+d3d9,warn+d3d,+d3d_shader
In this test I loaded Diamondback, Reactor, Sandtrap and then Diamondback again. All was fine until I loaded Sandtrap that is when the black texures appeared.
Reactor does have some texture issues too but not black textures.
Also, I think I remember solving Reactor texture issues (and the ones that are shown underneath the ghost exhaust, as well as Diamondback's heat effect) by adding
if (ins->handler_idx == WINED3DSIH_RCP || ins->handler_idx == WINED3DSIH_RSQ)
in my patch posted above instead of just the check for RCP. I went through an apitrace dump to figure it out at the time. So, if you'd mind adding in the check for WINED3DSIH_RSQ and seeing if that fixes the other texture issues, that'd be helpful.
https://bugs.winehq.org/show_bug.cgi?id=45375
--- Comment #16 from halome halome@blockchainworldawards.com ---
Also, I think I remember solving Reactor texture issues (and the ones that are shown underneath the ghost exhaust, as well as Diamondback's heat effect) by adding
if (ins->handler_idx == WINED3DSIH_RCP || ins->handler_idx == WINED3DSIH_RSQ)
in my patch posted above instead of just the check for RCP. I went through an apitrace dump to figure it out at the time. So, if you'd mind adding in the check for WINED3DSIH_RSQ and seeing if that fixes the other texture issues, that'd be helpful.
How do I use the if (ins->handler_idx == WINED3DSIH_RCP || ins->handler_idx == WINED3DSIH_RSQ) in the terminal to run the game?
https://bugs.winehq.org/show_bug.cgi?id=45375
--- Comment #17 from Connor McAdams conmanx360@gmail.com --- You'll have to compile wine with that change.
https://drive.google.com/open?id=1R5y963bxRZ1z3b0EHulKAgmaxWp8XPwL Is an archive containing the patches already compiled in, it's the version of wine I used to use. Just run it with ./wine from the directory you decompress it into, and tell me if it fixes the issues you're talking about.
https://bugs.winehq.org/show_bug.cgi?id=45375
--- Comment #18 from Paul Gofman gofmanp@gmail.com --- (In reply to Connor McAdams from comment #15)
if (ins->handler_idx == WINED3DSIH_RCP || ins->handler_idx == WINED3DSIH_RSQ)
in my patch posted above instead of just the check for RCP. I went through an apitrace dump to figure it out at the time. So, if you'd mind adding in the check for WINED3DSIH_RSQ and seeing if that fixes the other texture issues, that'd be helpful.
Please mind that staging patch already workarounds infinity in RCP, RSQ and LOG with multiply_special = 1. See https://bugs.winehq.org/show_bug.cgi?id=34266#c34 for details, and the patch itself: https://github.com/wine-staging/wine-staging/blob/master/patches/wined3d-zer...
Your patch is still different though as it replaces the result with 0 instead of FLT_MAX.
Comment #6 suggests that the staging workaround replacing inf with FLT_MAX in RCP / RSQ / LOG does not work here, while more generic workaround with multiply_special = 2 works, while some glitches remain, which might be unrelated. Given some problems observed regardless (maybe related to VM exhaustion), I personally don't have yet the confidence that the test results are not biased by the side problems. If it really the case when multiply_special = 1 does not workaround the problem while '... = 2' does, this is very interesting case.
At this point it would be great if someone could test it with the memory problem workaround from Comment #11, to see if this will remove remaining glitches. I don't have a confidence that this is the problem here yet. Yes, one of the logs has single GL_OUT_OF_MEMORY error listed, but it is yet hard to be sure that it is not caused by some other specific problem.
It would also be helpful if someone could describe the way how to get (legally of course) this version of the game and which is the quickest way to get to the glitches in game.
https://bugs.winehq.org/show_bug.cgi?id=45375
--- Comment #19 from halome halome@blockchainworldawards.com --- Created attachment 65357 --> https://bugs.winehq.org/attachment.cgi?id=65357 log
(In reply to Paul Gofman from comment #11)
Created attachment 65314 [details] Hack to use 4GB memory
If this is a virtual memory exhaustion issue, then there is a chance it can be worked around by an attached hack (the patch in the present form is taken from Proton). The game should be run with WINE_LARGE_ADDRESS_AWARE=1 environment variable in this case.
But it would really be nice to see the log.
I ran the game using this command which include WINE_LARGE_ADDRESS_AWARE=1
env WINEPREFIX="/home/user/PlayOnLinux's virtual drives/HaloOnline" wine "C:\windows\command\start.exe" /Unix "/home/user/PlayOnLinux's virtual drives/HaloOnline/drive_c/Halo Online/eldorado.exe" &> haloonline.txt WINEDEBUG=warn+d3d9,warn+d3d,+d3d_shader WINE_LARGE_ADDRESS_AWARE=1
But it did not solve the black texture memory issue. I loaded Diamondback and all as fine then after I loaded Reactor and there was black textures in the map.
https://bugs.winehq.org/show_bug.cgi?id=45375
--- Comment #20 from Paul Gofman gofmanp@gmail.com --- (In reply to halome from comment #19)
I ran the game using this command which include WINE_LARGE_ADDRESS_AWARE=1
Did you compile Wine with the relevant patch and used that one?
Is there any way I can get the same version of the game and reproduce the issue?
https://bugs.winehq.org/show_bug.cgi?id=45375
--- Comment #21 from Connor McAdams conmanx360@gmail.com --- (In reply to Paul Gofman from comment #18)
(In reply to Connor McAdams from comment #15)
if (ins->handler_idx == WINED3DSIH_RCP || ins->handler_idx == WINED3DSIH_RSQ)
in my patch posted above instead of just the check for RCP. I went through an apitrace dump to figure it out at the time. So, if you'd mind adding in the check for WINED3DSIH_RSQ and seeing if that fixes the other texture issues, that'd be helpful.
Please mind that staging patch already workarounds infinity in RCP, RSQ and LOG with multiply_special = 1. See https://bugs.winehq.org/show_bug.cgi?id=34266#c34 for details, and the patch itself: https://github.com/wine-staging/wine-staging/blob/master/patches/wined3d- zero-inf-shaders/0001-wined3d-Add-a-setting-to-workaround-0-inf-problem-in. patch
Your patch is still different though as it replaces the result with 0 instead of FLT_MAX.
Comment #6 suggests that the staging workaround replacing inf with FLT_MAX in RCP / RSQ / LOG does not work here, while more generic workaround with multiply_special = 2 works, while some glitches remain, which might be unrelated. Given some problems observed regardless (maybe related to VM exhaustion), I personally don't have yet the confidence that the test results are not biased by the side problems. If it really the case when multiply_special = 1 does not workaround the problem while '... = 2' does, this is very interesting case.
At this point it would be great if someone could test it with the memory problem workaround from Comment #11, to see if this will remove remaining glitches. I don't have a confidence that this is the problem here yet. Yes, one of the logs has single GL_OUT_OF_MEMORY error listed, but it is yet hard to be sure that it is not caused by some other specific problem.
It would also be helpful if someone could describe the way how to get (legally of course) this version of the game and which is the quickest way to get to the glitches in game.
I'm not sure there's a legal way to get a copy of this game anymore, and with the Master Chief collection coming out on steam soon, this version of the game may end up being kind of pointless.
When I went through apitrace and found the bugs with the shaders, it seemed to be a case of expecting DX9 behavior of defaulting to 0 instead of NaN or Inf when divisions by 0 happen. It seems to be very reliant on this behavior. I don't believe there's a way to fix this without some sort of OpenGL extension to add in DX9's behavior on inf and NaN, or adding checks to every potential operation that could produce those results, which would probably cause quite a bit of slowdown.
It's been awhile since I messed around with it, but that's just what I remember.
https://bugs.winehq.org/show_bug.cgi?id=45375
--- Comment #22 from halome halome@blockchainworldawards.com ---
I'm not sure there's a legal way to get a copy of this game anymore, and with the Master Chief collection coming out on steam soon, this version of the game may end up being kind of pointless.
I think this wine needs to be patched to make this game work and the reason is because of MCC coming to steam soon. The issues that Halo Online has with wine is not the menus but gameplay which is essentially the Halo 3 engine which will be included in MCC. I would like to see Halo Online work platinum or gold before MCC comes out so that MCC has less issues in Wine and the Halo 3 engine in MCC will work in wine. By fixing these issues this can also fix other halo engines in wine such as Halo Reach engine.
Me and many would like to play MCC on our linux machines. I would like MCC to fully work someday with all of its engines, Halo CE, Halo 2, Halo 3, Halo ODST, Reach and Halo 4 in wine.
https://bugs.winehq.org/show_bug.cgi?id=45375
--- Comment #23 from Connor McAdams conmanx360@gmail.com --- (In reply to halome from comment #22)
I'm not sure there's a legal way to get a copy of this game anymore, and with the Master Chief collection coming out on steam soon, this version of the game may end up being kind of pointless.
I think this wine needs to be patched to make this game work and the reason is because of MCC coming to steam soon. The issues that Halo Online has with wine is not the menus but gameplay which is essentially the Halo 3 engine which will be included in MCC. I would like to see Halo Online work platinum or gold before MCC comes out so that MCC has less issues in Wine and the Halo 3 engine in MCC will work in wine. By fixing these issues this can also fix other halo engines in wine such as Halo Reach engine.
Me and many would like to play MCC on our linux machines. I would like MCC to fully work someday with all of its engines, Halo CE, Halo 2, Halo 3, Halo ODST, Reach and Halo 4 in wine.
Thing is, I don't think they're going to be using DX9 on MCC. It should all be DX12, at least that's what has been speculated. We'll find out once it's released I guess.
Though this is all kind of off topic. We should probably only discuss the issue at hand in this thread.
https://bugs.winehq.org/show_bug.cgi?id=45375
--- Comment #24 from Paul Gofman gofmanp@gmail.com --- I've tested the game. As already discussed above, there are two absolutely unrelated problems here, memory exhaustion and 0 * inf handling in shaders. The latter is a duplicate of bug #34266, so I suggest to make this bug about memory issue which has some specifics in this case.
1. Memory issue. I could immediately reproduce that when loading "Diamondback" level. The hack I mentioned above is irrelevant here as the game's executable already has LARGE_ADDRESS_AWARE flag. The memory allocation failures does not occur often, it seems to happen only around initializing a few big 3D textures by the game one after another. The sequence is like this:
--- 0009:trace:d3d9:d3d9_device_CreateVolumeTexture iface 0C5796C8, width 1536, height 1536, depth 8, levels 1, usage 0, format 0x35545844, pool 0x2, texture 0032F724, shared_handle 00000000. 0009:trace:d3d9:device_parent_texture_sub_resource_created device_parent 0C5796CC, type 0x4, wined3d_texture 767ACE20, sub_resource_idx 0, parent 767ACFF8, parent_ops 767ACFFC. 0009:trace:d3d9:device_parent_texture_sub_resource_created Created volume 767AD020. 0009:trace:d3d9:d3d9_device_AddRef 0C5796C8 increasing refcount to 16617. 0009:trace:d3d9:d3d9_device_CreateVolumeTexture Created volume texture 767ACDE8. 0009:trace:d3d9:d3d9_texture_3d_LockBox iface 767ACDE8, level 0, locked_box 0032F700, box 00000000, flags 0. 0009:trace:d3d9:d3d9_volume_LockBox iface 767AD020, locked_box 0032F700, box 00000000, flags 0. 0009:trace:d3d9:d3d9_texture_3d_UnlockBox iface 767ACDE8, level 0. 0009:trace:d3d9:d3d9_volume_UnlockBox iface 767AD020. 0009:trace:d3d9:d3d9_device_CreateVolumeTexture iface 0C5796C8, width 1536, height 1536, depth 8, levels 1, usage 0, format 0x35545844, pool 0, texture 0032F724, shared_handle 00000000. 0009:trace:d3d9:device_parent_texture_sub_resource_created device_parent 0C5796CC, type 0x4, wined3d_texture 767AD080, sub_resource_idx 0, parent 767AD258, parent_ops 767AD25C. 0009:trace:d3d9:device_parent_texture_sub_resource_created Created volume 767AD280. 0009:trace:d3d9:d3d9_device_AddRef 0C5796C8 increasing refcount to 16618. 0009:trace:d3d9:d3d9_device_CreateVolumeTexture Created volume texture 767AD048. 0009:trace:d3d9:d3d9_device_UpdateTexture iface 0C5796C8, src_texture 767ACDE8, dst_texture 767AD048.
---
The game does that for a few textures. Usually heap_alloc fails in wined3d_texture_gl_upload_data(), sometimes it is accompanied by GL complaining about system memory, but once 3d textures initialization is done there is no new such errors.
So this looks like more like memory fragmentation issue rather than a complete exhaustion. Besides, uploading 3d textures in wined3d can probably be made much less memory consuming (as comment in wined3d_texture_gl_upload_data() suggests), which I suppose may solve the issue for this game.
The workaround that worked for me was changing texture resolution to 'Medium' in game settings.
Another interesting workaround was to disable CSMT (HKCU\Software\Wine\Direct3D\csmt set to 0, DWORD value). With CSMT, the internal wined3d memory allocation goes in parallel with the next 3D texture creation, and the memory is exhausted. With CSMT off and thus sequential operation, I did not have memory allocation errors, so it was enough continuous memory to hold the texture + convertion buffer once, but not twice). I don't know how stable this workaround is though, did not test it much.
2. 0 * inf issue
With the memory issue worked around by setting texture resolution to medium, I briefly tested a few maps for this problem. Without any tweaks the apparently corrupted image parts were present in a few maps. With multiply_special = 2 Staging workaround (which is a more thorough one), I could not spot any apparent glitches. With multiply_special = 1 I detected only one in "Edge" map: some herbs hanging on the rocks were completely black. That was due to the overflow in POW operation in a couple of shaders. Adding a clamp to [0, FLT_MAX] range in POW solved the issue with 'multiply_special = 1'. The staging patch is updated to include the workaround for RSQ function (in addition to RCP, RSQ and LOG). If you find more glitches with the latest change in Staging and multiply_special = 1 or 2 (after working around memory issue and having log clean from that), it would be great to know.
https://bugs.winehq.org/show_bug.cgi?id=45375
--- Comment #25 from halome halome@blockchainworldawards.com --- I did a test by setting the texture resolution to 'Medium' in game settings. This still caused the black textures to appear but it took longer for it to happen.
https://bugs.winehq.org/show_bug.cgi?id=45375
--- Comment #26 from halome halome@blockchainworldawards.com --- I did another test by setting the texture resolution to 'Medium' in game settings and by setting multiply_special to 1. This still caused the black textures to appear but it took longer for it to happen.
My Previous test which had the resolution to 'Medium' in game settings and by setting multiply_special to 2 still had black textures to appear but it took longer for it to happen.
So with both tests, I got the same results. It does not seem to matter if multiply_special is 1 or 2 but by setting the texture resolution to medium it does take longer to trigger the black textures.
https://bugs.winehq.org/show_bug.cgi?id=45375
--- Comment #27 from Paul Gofman gofmanp@gmail.com --- Can you retest it with Wine 4.18 (which has some patches concerning memory usage for texture upload conversion)? I also recommend changing pulseaudio settings: disable shared memory usage. I think the easiest way to do it for testing is to kill 'pulseaudio' which is run in your user session and manually start it with 'pulseaudio --disable-shm=true'.
With those patches and disabling pulseaudio shared memory I could not reproduce the problem even with texture quality set to 'High' after loading every map one after another.
https://bugs.winehq.org/show_bug.cgi?id=45375
--- Comment #28 from halome halome@blockchainworldawards.com --- Created attachment 65480 --> https://bugs.winehq.org/attachment.cgi?id=65480 wine 4.19 logs
I did some testing with wine 4.18. I was able to reproduce the black textures. I loaded every map in alphabetical order one by one. Once I got to Reactor the map was black. I also had the texture quality on high.
I also did a second test. When I boot up the game and load Last Resort and go to the beach. The distance was when you look out into the sea but when your on the beach below a certain Z axis level the map will turn black but once you your above the z axis the black textures will disspaear. This is how I ran the game in the terminal to get these results. My cmst is set to 0, and my multiply_special is set to 2 in the registry.
env WINEPREFIX="/home/USERNAME/PlayOnLinux's virtual drives/HaloOnline" wine "C:\windows\command\start.exe" /Unix "/home/USERNAME/PlayOnLinux's virtual drives/HaloOnline/drive_c/Halo Online/eldorado.exe" pulseaudio --disable-shm=true > haloonline.txt
https://bugs.winehq.org/show_bug.cgi?id=45375
--- Comment #29 from halome halome@blockchainworldawards.com --- Sorry. The logs above are wine 4.18. NOT 4.19
https://bugs.winehq.org/show_bug.cgi?id=45375
--- Comment #30 from Paul Gofman gofmanp@gmail.com --- (In reply to halome from comment #28)
Created attachment 65480 [details] wine 4.19 logs
the log files are empty.
I also did a second test. When I boot up the game and load Last Resort and go to the beach. The distance was when you look out into the sea but when your on the beach below a certain Z axis level the map will turn black but once you your above the z axis the black textures will disspaear. This is how I ran the game in the terminal to get these results. My cmst is set to 0, and my multiply_special is set to 2 in the registry.
This looks pretty much like the issue described in Comment #24 p2, which was concerned here initially. Please note that 'multiply_special' has no effect on mainstream Wine, it is in Wine Staging only. Are you using Wine Staging to test this? The memory issue is the same between development and Staging.
env WINEPREFIX="/home/USERNAME/PlayOnLinux's virtual drives/HaloOnline" wine "C:\windows\command\start.exe" /Unix "/home/USERNAME/PlayOnLinux's virtual drives/HaloOnline/drive_c/Halo Online/eldorado.exe" pulseaudio --disable-shm=true > haloonline.txt
That's not how it works. pulseaudio has nothing to do with Wine, or even less so with game executable command line. It is host daemon which runs an instance per each user session. You can get some basic idea from 'man pulseaudio' or searching some information on the Web. It is known to be one of the major VM space users if run with its typical default parameters. To do what I suggest to try (along with the latest Wine version), you should do the following before running the game with Wine:
1. Kill currently running instance. E. g., 'killall pulseaudio'. 2. Start it from the terminal; 'pulseaudio --disable-shm=true. 3. Find the newly created process and make sure it is started: ps <pid>
https://bugs.winehq.org/show_bug.cgi?id=45375
--- Comment #31 from halome halome@blockchainworldawards.com --- Created attachment 65483 --> https://bugs.winehq.org/attachment.cgi?id=65483 log
Sorry, I forgot the & in the terminal which is why the logs were blank.
https://bugs.winehq.org/show_bug.cgi?id=45375
--- Comment #32 from halome halome@blockchainworldawards.com --- Created attachment 65484 --> https://bugs.winehq.org/attachment.cgi?id=65484 log
I entered this into the terminal...
[me@ManjaroConmputer ~]$ killall pulseaudio [me@ManjaroConmputer ~]$ pulseaudio --disable-shm=true
then I opened the GNOME System Monitor and I saw pulseaudio was set to PID 6817 with its priority set to very high, Then I opened a second terminal window and entered this...
env WINEPREFIX="/home/me/PlayOnLinux's virtual drives/HaloOnline" wine "C:\windows\command\start.exe" /Unix "/home/me/PlayOnLinux's virtual drives/HaloOnline/drive_c/Halo Online/eldorado.exe" &> haloonline.txt
I loaded Diamondback, Edge, Icebox, Reactor and then Sandtrap. Once I loaded Sandtrap the map was black.
https://bugs.winehq.org/show_bug.cgi?id=45375
--- Comment #33 from Paul Gofman gofmanp@gmail.com --- Now your last log has no sign of memory errors (which previously showed up as either the error from wined3d_texture_gl_upload_data or opengl error).
Can you maybe now do all the same, but with Wine Staging 4.18 and multiply_special set to 1 or 2?
https://bugs.winehq.org/show_bug.cgi?id=45375
PJ 420@iljkd.xyz changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |420@iljkd.xyz
--- Comment #34 from PJ 420@iljkd.xyz --- This will be so cool if this game worked when wine 4.20 was released since 420. Halo online was released on 420 in 2018. That will be dope!
https://bugs.winehq.org/show_bug.cgi?id=45375
--- Comment #35 from halome halome@blockchainworldawards.com --- Created attachment 65486 --> https://bugs.winehq.org/attachment.cgi?id=65486 log
I did four tests. All with wine 4.1-staging and with cmst at 0 and I did the pulse audio thing in the terminal before launching halo online.
Test one, I set multiply_special to 1 and I loaded the following maps in order
Diamondback Edge Icebox Reactor Sandtrap
The result was once I loaded Sandtrap, the map was black
Test two, I set multiply_special to 1 and I loaded Last Resort and went to the beach and once I was below a certain z position, the map went black. When I went back to higher ground the map was normal again.
Test three and four was the same as test one and two except I set multiply_special to 2.
https://bugs.winehq.org/show_bug.cgi?id=45375
--- Comment #36 from halome halome@blockchainworldawards.com --- **wine 4.18-staging
https://bugs.winehq.org/show_bug.cgi?id=45375
--- Comment #37 from Paul Gofman gofmanp@gmail.com --- Your log suggests that you are not using Wine-4.18 staging. It should write about it right in the beginning of the log, and also you should see "err:winediag:Setting multiply_special to <x>' later in the log.
Your graphical issue description closely matches the problem without the 'multiply_special' workaround which was solved by it, so given you don't see memory problem now I have high hopes for as soon as you get Staging used it will work flawlessly for you.
https://bugs.winehq.org/show_bug.cgi?id=45375
--- Comment #38 from halome halome@blockchainworldawards.com --- I did download Wine 4.18 and 4.18 staging within PlayOnLinux and set my HaloOnline virtual drive to wine 4.18 and then 4.18 staging. I can test it again once my system version of wine is updated to 4.18. My system version is currently at 4.17 and will take a bit for the updates to roll out since I am on Manjaro which is not as bleeding edge as Arch.
Should I delete the multiply_special and the cmst variable from the registry?
Have you done more in depth testing with Halo Online in 4.18?
https://bugs.winehq.org/show_bug.cgi?id=45375
--- Comment #39 from Paul Gofman gofmanp@gmail.com --- I am sorry, supporting PlayOnLinux and Wine installation is out offtopic here.
Just when you get it right, you should see something like "000b:fixme:winediag:start_process Wine Staging 4.18 is a testing version containing experimental patches." at the beginning of the log. And if you set up multiply_special key correctly, you should also see a message in the log as in comment #37.
BTW your log suggests CSMT is not disabled either, though I am not sure you need that. There is also message about that in log, and it works in both mainstream and staging versions).
May I suggest you to make Staging and the registry setting work (and verify that in your log), and report the test results / logs after that?
https://bugs.winehq.org/show_bug.cgi?id=45375
--- Comment #40 from halome halome@blockchainworldawards.com --- Created attachment 65526 --> https://bugs.winehq.org/attachment.cgi?id=65526 log
Manjaro has updated my Wine to 4.18. I did another test and I got the same results as of before. Once I loaded the fourth map the black textures appeared again. I had multiply_special set to 2.
https://bugs.winehq.org/show_bug.cgi?id=45375
--- Comment #41 from halome halome@blockchainworldawards.com --- Created attachment 65527 --> https://bugs.winehq.org/attachment.cgi?id=65527 log
second log except with "pulseaudio --disable-shm=true" added to the terminal command when launching the game.
https://bugs.winehq.org/show_bug.cgi?id=45375
--- Comment #42 from halome halome@blockchainworldawards.com --- Created attachment 65528 --> https://bugs.winehq.org/attachment.cgi?id=65528 log
I installed wine 4.18-staging from the manjaro repos and I did a "wine --version" test in the terminal and it said I was using the staging version.
During this test I had muliply_special set to 2 and I loaded Diamondback and Edge. I noticed the transparent texture issue was gone which was nice but when I loaded Edge I got the black texture issue.
I also noticed it took a big performance hit. The game was slow unlike before when it ran smooth.
https://bugs.winehq.org/show_bug.cgi?id=45375
--- Comment #43 from halome halome@blockchainworldawards.com --- Created attachment 65529 --> https://bugs.winehq.org/attachment.cgi?id=65529 log
I did another test using Wine 4.18-staging. I loaded three maps which was Diamondback, Edge and Icebox
Multiply special was set to 2 and I used this command to run the game
env WINEPREFIX="/home/user/PlayOnLinux's virtual drives/HaloOnline" wine "C:\windows\command\start.exe" /Unix "/home/user/PlayOnLinux's virtual drives/HaloOnline/drive_c/Halo Online/eldorado.exe" pulseaudio --disable-shm=true &> haloonline.txt
It was a little slow and there was a performance hit, the transparent textures worked but the black textures appeared on Icebox.
https://bugs.winehq.org/show_bug.cgi?id=45375
--- Comment #44 from halome halome@blockchainworldawards.com --- Another test
Wine 5.18-staging multiply special set to 1
env WINEPREFIX="/home/user/PlayOnLinux's virtual drives/HaloOnline" wine "C:\windows\command\start.exe" /Unix "/home/user/PlayOnLinux's virtual drives/HaloOnline/drive_c/Halo Online/eldorado.exe" pulseaudio --disable-shm=true &> haloonline.txt
I loaded the following maps
Diamondback Edge Icebox Recator Sandtrap Sandoff The Pit Valhalla Reactor (Crashed game)
No black textures except for when I loaded Reactor. When I loaded the other maps after the black textures went away which I never seen before since once black textures appeared they will remain on any map until you relaunch the game. When I tried to launch Reactor again the game crashed. Again transparent textures worked too and there some performace hit but I think this was better than my previous tests.
Sorry for all the logs but I figured the more data you had the better
https://bugs.winehq.org/show_bug.cgi?id=45375
--- Comment #45 from halome halome@blockchainworldawards.com --- Created attachment 65530 --> https://bugs.winehq.org/attachment.cgi?id=65530 log
Log for previous comment
https://bugs.winehq.org/show_bug.cgi?id=45375
--- Comment #46 from Paul Gofman gofmanp@gmail.com --- Please reread my comment #30 and your comment #32.
At your comment #32 you already managed to get away from memory errors, but now you're repeating earlier meaningless command line.
Also, set multiply_special to 1 instead of 2 (with the same Wine Staging 4.18 which you are now indeed running). This may help to get performance back.
https://bugs.winehq.org/show_bug.cgi?id=45375
--- Comment #47 from halome halome@blockchainworldawards.com --- [me@ManjaroConmputer ~]$ killall pulseaudio [me@ManjaroConmputer ~]$ pulseaudio --disable-shm=true [me@ManjaroConmputer ~]$ env WINEPREFIX="/home/user/PlayOnLinux's virtual drives/HaloOnline" wine "C:\windows\command\start.exe" /Unix "/home/user/PlayOnLinux's virtual drives/HaloOnline/drive_c/Halo Online/eldorado.exe" &> haloonline.txt
I had multiply special set to 1, wine 4.18-staging and this was the best results I have seen yet. I did get the black textures after I loaded every map once, Once I loaded Sandtrap the second time which was the 13th map I loaded I got the black textures.
Is there also another way to be able to no have the memory issues without killing pulseaudio? I would like prefer to be able to launch the game with one command and not in 3 commands.
https://bugs.winehq.org/show_bug.cgi?id=45375
--- Comment #48 from halome halome@blockchainworldawards.com --- Created attachment 65532 --> https://bugs.winehq.org/attachment.cgi?id=65532 log
https://bugs.winehq.org/show_bug.cgi?id=45375
ahmed ahmedq@emailonline.me changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ahmedq@emailonline.me
--- Comment #49 from ahmed ahmedq@emailonline.me --- Thank you so much to everyone who has gotten this to work especially you Paul Gofman. Is it possible to not have to kill and restart pulseaudio? Or is there a workaround to keep pulseaudio shared memory from causing the memory exhaustion issue?
https://bugs.winehq.org/show_bug.cgi?id=45375
--- Comment #50 from Paul Gofman gofmanp@gmail.com --- Yes, of course, there are configuration files for pulseaudio which allow to do it. I am sorry, guiding through this process is offtopic here, you can find the information in pulseaudio manual or search Web for that.
https://bugs.winehq.org/show_bug.cgi?id=45375
--- Comment #51 from ahmed ahmedq@emailonline.me --- Is it possible to add some patches in 4.19-staging or 4.20-staging so PulseAudio will not affect the memory of Wine?
https://bugs.winehq.org/show_bug.cgi?id=45375
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com
--- Comment #52 from Zebediah Figura z.figura12@gmail.com --- (In reply to ahmed from comment #51)
Is it possible to add some patches in 4.19-staging or 4.20-staging so PulseAudio will not affect the memory of Wine?
PulseAudio is "affecting the memory of Wine" by being loaded and functioning in the process. Such a patch would be to disable PulseAudio entirely. That's not desirable.
https://bugs.winehq.org/show_bug.cgi?id=45375
--- Comment #53 from halome halome@blockchainworldawards.com --- Do I need to add CSMT in the registry in 4.18-staging? Does it do anything when CSMT is set to 0 (DWORD)?
https://bugs.winehq.org/show_bug.cgi?id=45375
joaopa jeremielapuree@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree@yahoo.fr
--- Comment #54 from joaopa jeremielapuree@yahoo.fr --- Does the bug still occur with wine-6.5?
https://bugs.winehq.org/show_bug.cgi?id=45375
Neko-san nekoNexus@protonmail.ch changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nekoNexus@protonmail.ch
-
wine-bugs＠winehq.org -
WineHQ Bugzilla