http://bugs.winehq.org/show_bug.cgi?id=29582
Bug #: 29582 Summary: Star Wars Battlefront (I and II) "Loading" screen very slow. Product: Wine Version: 1.3.36 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: daniel.santos@pobox.com Classification: Unclassified
The "Loading" screen takes so long (in SW Battlefront II) that I can't connect to network games because when it finally finishes loading the level, I get a message that says "lost connection to host" (presumably because it timed out). I haven't timed it, but it seems to be about 2 minutes, whereas running it on windows takes roughly 5-10 seconds.
WINEDEBUG=+relay did show that PeekMessageA was being called about 2700 times a second (probably not a big deal) but then GetForgroundWindows was being called right after that (a wineserver call). I suspected that as a possible culprit, but haven't dug in too deeply yet.
I'll do some profiling on this later and try to get some better info. Maybe I can find a hack-around to positively isolate the cause.
http://bugs.winehq.org/show_bug.cgi?id=29582
--- Comment #1 from Daniel Santos daniel.santos@pobox.com 2012-01-09 21:31:49 CST --- Oh, I forgot to mention that aside from the progress bar having nothing to do with reality (i.e., it doesn't appear to reflect the actual status of the "loading", rather it just progresses a tick every second until it's full), the GUI is flawless during this slow loading, updating very prettily making the program look like it's doing plenty (just like "loading" screens are supposed to do). Also, there is very little disk activity, but one CPU is at 100%.
http://bugs.winehq.org/show_bug.cgi?id=29582
--- Comment #2 from Daniel Santos daniel.santos@pobox.com 2012-01-11 00:49:17 CST --- Created attachment 38323 --> http://bugs.winehq.org/attachment.cgi?id=38323 sad little hack for swbf2 loading performance probs
fuck! (sorry for the language) These programmers are fucking idiots!
I injected a hack and decreased loading times to about 30% of what it was taking before (still not as fast as on windows). Basically, all it does is when PeekMessageX is called and no messages are returned, it sets a timer to prevent it from making the wineserver call again for 1 millisecond. Also, calls to GetForgroundWindow return a cached value (this part has a minor bug in it, but works enough for the test). The synopsis? It makes unneeded calls to PeekMessageA and GetForgroundWindow 24k per second each!
So I guess we're dealing with a special ed case here.
http://bugs.winehq.org/show_bug.cgi?id=29582
--- Comment #3 from Daniel Santos daniel.santos@pobox.com 2012-01-13 01:44:28 CST --- hmm, it would appear that this can actually be due to a failed call to SetFilePointer where the return value appears to be ignored by the app. The GUI thread 0x0009 appears to interact with thread 0x0023 for loading data and signaling each other back and forth. It would appear that the GUI thread is supposed to be waiting for something to happen, but thread 0x23 signals their semephore and leaves it that way, leading the GUI thread to burn the CPU hitting PeekMessageA, GetForegroundWindow
waiting for
Note: due to an incomplete timestamp mod, timestamps on trace statements (in milliseconds) are roughly 49.25 seconds behind other timestamps (which are in microseconds) and server traces are timestamp-less.
708.860908:0023:Call KERNEL32.SetFilePointer(000000e0,00000000,00000000,00000000) ret=0067ad93 758.129:0023:trace:ntdll:NtSetInformationFile (0xe0,0x6d2e8f8,0x6d2e8f0,0x00000008,0x0000000e) 0023: get_handle_fd( handle=00e0 ) 0023: *fd* 00e0 -> 34 0023: get_handle_fd() = 0 { type=1, cacheable=1, access=00120089, options=00000068 } 708.860934:0023:Ret KERNEL32.SetFilePointer() retval=00000000 ret=0067ad93 708.860940:0023:Call KERNEL32.ReadFile(000000e0,04a07800,00020000,06d2ea04,00000000) ret=0067adbb 758.129:0023:trace:file:ReadFile 0xe0 0x4a07800 131072 0x6d2ea04 (nil) 758.129:0023:trace:ntdll:NtReadFile (0xe0,(nil),(nil),(nil),0x6d2e908,0x4a07800,0x00020000,(nil),(nil)),partial stub! 758.129:0023:trace:ntdll:NtReadFile = SUCCESS (131072) 708.861018:0023:Ret KERNEL32.ReadFile() retval=00000001 ret=0067adbb
It's after this that it begins cycling on PeekMessageA, GetForegroundWindow, WaitForSingleObject and ReleaseSemephore. It doesn't do it forever, after some time, it proceeds, but this is one place that it transitions from apearing to behave normally to definitely misbehaving.
I'm not yet sure why the call to SetFilePointer failed. I believe this call should have caused it to seek to the beginning of the file (where the file pointer should have already been since it was just opened).
http://bugs.winehq.org/show_bug.cgi?id=29582
--- Comment #4 from Daniel Santos daniel.santos@pobox.com 2012-01-14 01:49:07 CST --- well, it would appear that I'm wrong about the call the call to SetFilePointer -- it returned zero because that was the low-order of the file pointer position (oops). Either way, the app definitely enters a race condition of some sort. In another sample, I found a thread spinning calling WaitForSingleObject on a semaphore followed by ReleaseSemaphore on that same handle for about a solid second. Isolating the root cause (from Wine's end of it) of this race condition looks pretty difficult.
Also, I was slightly off on my numbers. My hack only reduced load time by about 45%. Normally it takes about 80 seconds to load and the hack reduced it to 45 seconds. Setting the misbehaving thread's priority lower doesn't help because that thread appears to be what opens the data files (that are "loaded"), even though it passes those handles off to another thread to actually read them (strange). It appears to be the coordination between those two threads that's going awry.
http://bugs.winehq.org/show_bug.cgi?id=29582
Maxime Alves maxime.alves@free.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |maxime.alves@free.fr
--- Comment #5 from Maxime Alves maxime.alves@free.fr 2012-03-19 17:23:38 CDT --- Same situation here, only installed vcrun to make the game work, but the loading screen last like 5 minutes. The only log messages I get are :
fixme:d3d:resource_check_usage Unhandled usage flags 0x8. fixme:d3d:wined3d_buffer_preload Too many declaration changes or converting dynamic buffer, stopping converting fixme:d3d:resource_check_usage Unhandled usage flags 0x8.
distro : debian squeeze i386 wine version : 1.4
http://bugs.winehq.org/show_bug.cgi?id=29582
arthur.huillet@free.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |arthur.huillet@free.fr
http://bugs.winehq.org/show_bug.cgi?id=29582
Jonathan Haller one.who.stands.alone@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |one.who.stands.alone@gmail. | |com
--- Comment #6 from Jonathan Haller one.who.stands.alone@gmail.com 2012-10-02 14:18:00 CDT --- Same situation here, xubuntu 12.04 AMD64, wine 1.5.14. I am surprised nobody has confirmed this yet...
The game not working online is solely due to the servers dropping the connection since the client takes so long to load, for swbfront2 this is a fairly critical bug.
http://bugs.winehq.org/show_bug.cgi?id=29582
--- Comment #7 from Daniel Santos daniel.santos@pobox.com 2012-10-03 12:40:51 CDT ---
The game not working online is solely due to the servers dropping the connection since the client takes so long to load, for swbfront2 this is a fairly critical bug.
Yeah, that was my point, despite so much working in this game, this bug makes removes a full half of its functionality.
The silly part of this is that the app appears to be beating its self to death on something other than loading, thus starving the thread that's actually trying to do the loading. Or, if the loading isn't occurring in an actual background thread (that belongs to the app), whatever other thing it's caught up on is keeping it from loading. In one iteration of my in-process wine kernel, I had this thing loading up in 5 seconds (even though I broke plenty of other stuff with that hack) -- this proved that it wasn't a problem with actually loading slowly, but with the app slowing its self down as it tries to load the level data.
I'll take another look at this in a few months, I'm too bogged down with another project to spend much time on it at the moment.
http://bugs.winehq.org/show_bug.cgi?id=29582
ignacio rodríguez ninovolador@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ninovolador@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=29582
Micah John mjmiller98@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mjmiller98@gmail.com
--- Comment #8 from Micah John mjmiller98@gmail.com 2013-08-29 12:41:35 CDT --- Please let us know when you do, and keep us updated!
http://bugs.winehq.org/show_bug.cgi?id=29582
Jack Coventry deadrose2009@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |deadrose2009@gmail.com
--- Comment #9 from Jack Coventry deadrose2009@gmail.com --- Sorry for being a massive noob but how to I add the hack to the port?
https://bugs.winehq.org/show_bug.cgi?id=29582
--- Comment #10 from austinenglish@gmail.com --- (In reply to Jack Coventry from comment #9)
Sorry for being a massive noob but how to I add the hack to the port?
http:://wiki.winehq.org/Patching
https://bugs.winehq.org/show_bug.cgi?id=29582
--- Comment #11 from Jack Coventry deadrose2009@gmail.com --- Thanks for getting back so quickly, sorry for bugging you but I have one more question, where exactly does this diff file start and end. Thankyou!
https://bugs.winehq.org/show_bug.cgi?id=29582
--- Comment #12 from Jack Coventry deadrose2009@gmail.com --- FYI this is what I get when I try it patching file dlls/user32/focus.c Hunk #1 succeeded at 36 (offset 1 line). Hunk #2 succeeded at 366 (offset 2 lines). Hunk #3 succeeded at 380 (offset 2 lines). patching file dlls/user32/message.c Hunk #2 succeeded at 3751 with fuzz 1 (offset 201 lines). Hunk #3 FAILED at 3774. 1 out of 3 hunks FAILED -- saving rejects to file dlls/user32/message.c.rej patching file dlls/user32/user_main.c Hunk #1 succeeded at 328 (offset -3 lines). patching file dlls/user32/user_private.h patch unexpectedly ends in middle of line Hunk #2 succeeded at 41 with fuzz 2 (offset 5 lines).
http://bugs.winehq.org/show_bug.cgi?id=29582
Dara Adib daradib@quietapple.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |daradib@quietapple.org
--- Comment #13 from Dara Adib daradib@quietapple.org --- Created attachment 48931 --> http://bugs.winehq.org/attachment.cgi?id=48931 sad little hack updated without changes
(In reply to Jack Coventry from comment #12)
FYI this is what I get when I try it patching file dlls/user32/focus.c [...] Hunk #3 FAILED at 3774. 1 out of 3 hunks FAILED -- saving rejects to file dlls/user32/message.c.rej
That (hacky) patch was made for an older version of Wine from over two years ago. Wine has changed in the meantime so part of the patch doesn't apply correctly.
I updated Daniel's patch for master and it also works with 1.6.2. At least I think I updated the patch correctly. I didn't make any changes. Battlefront I seems to work well for me with the patch applied to 1.6.2.
Cheers, Dara
https://bugs.winehq.org/show_bug.cgi?id=29582
Ben Malovrh bnmlvrh20@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bnmlvrh20@gmail.com
--- Comment #14 from Ben Malovrh bnmlvrh20@gmail.com --- Yo! How do you convert the hack file and apply it. Im really new at this. Someone please help.
https://bugs.winehq.org/show_bug.cgi?id=29582
Ronny Schmatzler schmatzler@googlemail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |schmatzler@googlemail.com
--- Comment #15 from Ronny Schmatzler schmatzler@googlemail.com --- Created attachment 50823 --> https://bugs.winehq.org/attachment.cgi?id=50823 Hack updated for 1.7.37
Patch updated for 1.7.37 - works fine in Battlefront 2. :)
https://bugs.winehq.org/show_bug.cgi?id=29582
Mel Irizarry melirizarry@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |melirizarry@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=29582
mrdeathjr28@yahoo.es changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mrdeathjr28@yahoo.es
https://bugs.winehq.org/show_bug.cgi?id=29582
Daniel Santos daniel.santos@pobox.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #38323|0 |1 is obsolete| | CC| |daniel.santos@pobox.com
--- Comment #16 from Daniel Santos daniel.santos@pobox.com --- Created attachment 52285 --> https://bugs.winehq.org/attachment.cgi?id=52285 GetForegroundWindow hack plus hybrid (wineserver/native) semaphores
Thanks for keeping up with this hack guys!
Today I have a present for you -- this rather large patch speeds up load times even further. (This isn't the in-process wineserver patch set either.) This patch applies cleanly to 1.7.51. After patching you're supposed to be able to configure with --enable-hybrid-sync, but I think missed something in configure.ac and it's not working. So instead you can either edit your include/config.h (in the build directory) and add this:
#define ENABLE_POSIX_SYNC 1
or add -DENABLE_POSIX_SYNC=1 to your CFLAGS.
This patch contains both the previous hack as well as an experimental hybrid semaphores patch set that I'm working on. After the actual files are cached, loading is now almost instantaneous -- faster than on Windows!
https://bugs.winehq.org/show_bug.cgi?id=29582
--- Comment #17 from Daniel Santos daniel.santos@pobox.com --- (In reply to Daniel Santos from comment #16)
Created attachment 52285 [details] GetForegroundWindow hack plus hybrid (wineserver/native) semaphores
One thing to be aware of is that this patch suffers from a bug caused by glibc's NPTL implementation of of semaphores not being ABI friendly, so this will only work if you build the 32-bit only version of wine (if you have a normal wow 64/32 build, it will fail).
Anyway, it looks like the hack portion of this will not be necessary any longer as a proper fix is now in wine-staging: https://www.winehq.org/pipermail/wine-bugs/2015-March/410444.html
The best way to apply this is to clone the wine-staging repository and apply the patches using this command:
.../path/to/patches/patchinstall.sh --backend=git server-Shared_Memory
https://bugs.winehq.org/show_bug.cgi?id=29582
--- Comment #18 from Daniel Santos daniel.santos@pobox.com --- I forgot to add that you have to set an environment variable to enable the patch set as well:
STAGING_SHARED_MEMORY=1
https://bugs.winehq.org/show_bug.cgi?id=29582
Joe thorpejoe4@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |thorpejoe4@gmail.com
--- Comment #19 from Joe thorpejoe4@gmail.com --- I've been trying to compile wine with the patch for wine 1.7.37 for many hours now. Despite a lot of research, i've only managed to apply the patch (well, i think i did). But then i compiled (./configure && make) and just encountered errors.
I don't think diagnosing the errors is the solution here, because there's probably a bunch of things i did incorrectly. So what should the process be?
Also, what's happening with this patch? In terms of progress.
https://bugs.winehq.org/show_bug.cgi?id=29582
--- Comment #20 from Joe thorpejoe4@gmail.com --- (In reply to Joe from comment #19)
I've been trying to compile wine with the patch for wine 1.7.37 for many hours now. Despite a lot of research, i've only managed to apply the patch (well, i think i did). But then i compiled (./configure && make) and just encountered errors.
I don't think diagnosing the errors is the solution here, because there's probably a bunch of things i did incorrectly. So what should the process be?
Also, what's happening with this patch? In terms of progress.
To add to that. This is on OSX, so perhaps the patch is for linux only?
Also my method for getting a patch file was: 1: copy the text from the attachment in #15 into a text document 2: save as focus_new.patch 3) copy to ~/wine-git/dlls/user32 4) rename to focus_new.c 5) diff -u focus.c focus_new.c > focus.c
https://bugs.winehq.org/show_bug.cgi?id=29582
--- Comment #21 from Joe thorpejoe4@gmail.com --- Created attachment 52938 --> https://bugs.winehq.org/attachment.cgi?id=52938 output of patch attempt
Trying to apply the patch in osx using the method in http://wiki.winehq.org/Patching
An error occurred after running patch -p1 < focus.diff
https://bugs.winehq.org/show_bug.cgi?id=29582
--- Comment #22 from Daniel Santos daniel.santos@pobox.com --- (In reply to Joe from comment #20)
To add to that. This is on OSX, so perhaps the patch is for linux only?
Ahh, well my apologies then. There are a few things I should state about the experimental posix semaphores patchset:
1. It's only been tested on Linux 2. It will only work if you build a 32-bit only wine build (wineserver has to be 32-bits). 3. It has been abandon in favor of a different route.
Also, if you want the very last revision of this patch set, you can get it from this thread: http://comments.gmane.org/gmane.comp.emulators.wine.devel/103479 Unfortunately, I ran git send-email wrong and the new patches didn't go under the correct sub-thread, so they are patches 1-9 dated September 14 (and they "rev 3" header message is at the bottom of the thread).
On the bright side a new experimental patch set to address this problem is forthcoming, but again it is untested on OSX and there is at least one mechanism that I know of that has to be coded for the BSD kernel because they don't have futexes (that I know of), so these will likely replaced by ksemaphores, but I haven't looked deeply into it yet. Lastly, there's some more work needed for ARM and PPC.
Hopefully the combination of Sebastian's shared memory patch set and the new "hybrid semaphores" will fix this problem (as well as many others).
https://bugs.winehq.org/show_bug.cgi?id=29582
--- Comment #23 from Joe thorpejoe4@gmail.com --- (In reply to Daniel Santos from comment #22)
(In reply to Joe from comment #20)
To add to that. This is on OSX, so perhaps the patch is for linux only?
Ahh, well my apologies then. There are a few things I should state about the experimental posix semaphores patchset:
- It's only been tested on Linux
- It will only work if you build a 32-bit only wine build (wineserver has
to be 32-bits). 3. It has been abandon in favor of a different route.
Also, if you want the very last revision of this patch set, you can get it from this thread: http://comments.gmane.org/gmane.comp.emulators.wine.devel/103479 Unfortunately, I ran git send-email wrong and the new patches didn't go under the correct sub-thread, so they are patches 1-9 dated September 14 (and they "rev 3" header message is at the bottom of the thread).
On the bright side a new experimental patch set to address this problem is forthcoming, but again it is untested on OSX and there is at least one mechanism that I know of that has to be coded for the BSD kernel because they don't have futexes (that I know of), so these will likely replaced by ksemaphores, but I haven't looked deeply into it yet. Lastly, there's some more work needed for ARM and PPC.
Hopefully the combination of Sebastian's shared memory patch set and the new "hybrid semaphores" will fix this problem (as well as many others).
Okay, firstly thank you, perhaps i can be helpful, by testing the patch on OSX? Perhaps even fixing any issues that arise due to OSX?
I've just tried to compile wine by going: git clone git://source.winehq.org/git/wine.git wine-git brew install --only-dependencies --devel wine
And that failed, so i'll have to fix that, so that we'll know whether it's the patch that's the problem or not.
Once i do get that working, which patch would i apply, and how? And as for 32bit wine, how would i do that?
Sorry for being such a noob at this, but i'm afraid it can't be helped right now.
https://bugs.winehq.org/show_bug.cgi?id=29582
--- Comment #24 from Joe thorpejoe4@gmail.com --- Update: I've successfully compiled wine (ie ran ./configure CC="clang" CXX="clang++" CFLAGS="-std=gnu89 -g" && make . Without errors)
I don't know where to go from there, but i guess i can try with the patch now.
https://bugs.winehq.org/show_bug.cgi?id=29582
--- Comment #25 from Daniel Santos daniel.santos@pobox.com --- (In reply to Joe from comment #24)
Update: I've successfully compiled wine (ie ran ./configure CC="clang" CXX="clang++" CFLAGS="-std=gnu89 -g" && make . Without errors)
I don't know where to go from there, but i guess i can try with the patch now.
One more thing I forgot to mention is that the shared memory patch (which solves only about 35% of the problem) currently will not do anything on OSX because it depends on a feature that's only in the linux kernel (memfd), so don't bother with that one, but there's still the old hack to work around the problems that the shared memory patch would have fixed (I guess that's bundled in the last patch I posted to this report). Good Luck!
https://bugs.winehq.org/show_bug.cgi?id=29582
Arthur Huillet arthur.huillet@free.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|arthur.huillet@free.fr |
https://bugs.winehq.org/show_bug.cgi?id=29582
--- Comment #26 from Joe thorpejoe4@gmail.com --- (In reply to Daniel Santos from comment #25)
(In reply to Joe from comment #24)
Update: I've successfully compiled wine (ie ran ./configure CC="clang" CXX="clang++" CFLAGS="-std=gnu89 -g" && make . Without errors)
I don't know where to go from there, but i guess i can try with the patch now.
One more thing I forgot to mention is that the shared memory patch (which solves only about 35% of the problem) currently will not do anything on OSX because it depends on a feature that's only in the linux kernel (memfd), so don't bother with that one, but there's still the old hack to work around the problems that the shared memory patch would have fixed (I guess that's bundled in the last patch I posted to this report). Good Luck!
Okay, thanks for the heads up. Could you please help me with what i said in comment 23?
I don't even know where to download the .diff file (or how to make it, since i don't know where the text is. The link in comment 22 didn't shine any light on that.
And then 32bit wine?
https://bugs.winehq.org/show_bug.cgi?id=29582
--- Comment #27 from Austin English austinenglish@gmail.com --- (In reply to Joe from comment #26)
And then 32bit wine?
32-bit Wine is the default. Essentially, don't add --enable-win64 to configure.
https://bugs.winehq.org/show_bug.cgi?id=29582
--- Comment #28 from Joe thorpejoe4@gmail.com --- (In reply to Austin English from comment #27)
(In reply to Joe from comment #26)
And then 32bit wine?
32-bit Wine is the default. Essentially, don't add --enable-win64 to configure.
Okay thank you. And for getting the patch (preferably for 1.7.55, since that's the latest version). How do I do that?
I've been looking through the documentation for far too long, but I can't figure it out.
Thanks for helping me.
https://bugs.winehq.org/show_bug.cgi?id=29582
--- Comment #29 from Daniel Santos daniel.santos@pobox.com --- (In reply to Joe from comment #28)
Thanks for helping me.
Well, considering that it will be a while before my new patch set will have a chance to be finished and make it through the process, I'll get the old hack and the most recent posix semaphore patch set rebased and post it tonight.
https://bugs.winehq.org/show_bug.cgi?id=29582
--- Comment #30 from Joe thorpejoe4@gmail.com --- (In reply to Daniel Santos from comment #29)
(In reply to Joe from comment #28)
Thanks for helping me.
Well, considering that it will be a while before my new patch set will have a chance to be finished and make it through the process, I'll get the old hack and the most recent posix semaphore patch set rebased and post it tonight.
Oh okay. I didn't mean to rush you, i just thought that it was there, but that i couldn't find it.
I really do appreciate your help. I've got a LAN party coming up where SWBF is going to be the focus of it, and it's my job to get it working.
https://bugs.winehq.org/show_bug.cgi?id=29582
Daniel Santos daniel.santos@pobox.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #52285|0 |1 is obsolete| |
--- Comment #31 from Daniel Santos daniel.santos@pobox.com --- Created attachment 52963 --> https://bugs.winehq.org/attachment.cgi?id=52963 updated patchset (GetForgroundWindow hack + posix semaphores) rebased onto wine-1.7.55
Rebased for 1.7.55
This fixes one tiny issue in the semaphore patch set (thanks to madewokherd). Note that the posix-based semaphore patch set is still dead as I'm working on an alternative, but it will work if you build a 32-bit only build. Using this patch is not supported by anyone, etc.
Instructions: get the 1.7.55 sources apply this patch Configure as normal, except add --enable-hybrid-sync and do NOT add --enable-win64 or --with-wine64
So for the lazy: mkdir ${HOME}/proj cd ${HOME}/proj git clone git://source.winehq.org/git/wine.git wine cd wine <copy patch file here> patch -p1 < swbf-hacks-20151130.patch mkdir build cd build ../configure --enable-hybrid-sync [add anything else you need] make
Then use this for your wine command to run what you just built instead of what's installed globally: WINEPREFIX={$HOME}/whereever ${HOME}/proj/wine/build/loader/wine some_crap.exe
You may get a crash in run32dll when your wine instance is updating -- this is a known problem in the patch set (fixed in the new one), but it doesn't seem to cause a problem with the game running.
https://bugs.winehq.org/show_bug.cgi?id=29582
super_man@post.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |super_man@post.com
https://bugs.winehq.org/show_bug.cgi?id=29582
Béla Gyebrószki gyebro69@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |NEW URL| |http://store.steampowered.c | |om/app/6060/ CC| |gyebro69@gmail.com
--- Comment #32 from Béla Gyebrószki gyebro69@gmail.com --- Still an issue in wine-2.2-256-g89b7529.
Star Wars Battlefront II (Steam).
https://bugs.winehq.org/show_bug.cgi?id=29582
winetest@luukku.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winetest@luukku.com
--- Comment #33 from winetest@luukku.com --- The patch needs rebase.
patching file configure Hunk #1 succeeded at 816 (offset 6 lines). Hunk #2 succeeded at 2320 (offset 133 lines). Hunk #3 succeeded at 3439 (offset 141 lines). Hunk #4 succeeded at 6890 (offset 141 lines). Hunk #5 succeeded at 7299 (offset 192 lines). patching file configure.ac Hunk #2 succeeded at 461 (offset -3 lines). Hunk #3 succeeded at 652 (offset -1 lines). patching file dlls/ntdll/loader.c Hunk #1 succeeded at 3302 (offset 21 lines). patching file dlls/ntdll/ntdll_misc.h Hunk #2 succeeded at 268 (offset -2 lines). patching file dlls/ntdll/om.c patching file dlls/ntdll/server.c patching file dlls/ntdll/sync.c Hunk #3 succeeded at 434 with fuzz 1 (offset 12 lines). Hunk #4 FAILED at 451. Hunk #5 succeeded at 504 (offset 11 lines). 1 out of 5 hunks FAILED -- saving rejects to file dlls/ntdll/sync.c.rej patching file dlls/ntdll/tests/threadpool.c Hunk #2 succeeded at 571 (offset 12 lines). Hunk #3 succeeded at 1800 (offset 243 lines). Hunk #4 succeeded at 1816 (offset 243 lines). Hunk #5 succeeded at 1830 (offset 243 lines). Hunk #6 succeeded at 1864 (offset 243 lines). Hunk #7 succeeded at 1877 (offset 243 lines). Hunk #8 succeeded at 1889 (offset 243 lines). Hunk #9 succeeded at 1920 (offset 243 lines). patching file dlls/user32/focus.c Hunk #2 succeeded at 368 (offset 2 lines). Hunk #3 succeeded at 382 (offset 2 lines). patching file dlls/user32/message.c Hunk #3 succeeded at 3764 (offset 8 lines). Hunk #4 succeeded at 3788 (offset 8 lines). patching file dlls/user32/user_main.c Hunk #1 succeeded at 332 (offset 1 line). patching file dlls/user32/user_private.h patching file include/config.h.in Hunk #2 succeeded at 804 (offset 39 lines). patching file include/wine/server_protocol.h Hunk #1 succeeded at 1311 (offset 3 lines). Hunk #2 succeeded at 1345 (offset -8 lines). patching file server/Makefile.in patching file server/object.h Hunk #1 succeeded at 93 (offset 3 lines). patching file server/protocol.def Hunk #1 succeeded at 1135 (offset 32 lines). Hunk #2 succeeded at 1163 (offset 32 lines). patching file server/request.h Hunk #1 succeeded at 955 with fuzz 2 (offset 37 lines). Hunk #2 succeeded at 973 with fuzz 2 (offset 37 lines). patching file server/semaphore.c Hunk #4 FAILED at 97. Hunk #5 FAILED at 149. Hunk #6 succeeded at 166 (offset -4 lines). Hunk #7 FAILED at 231. Hunk #8 FAILED at 251. Hunk #9 succeeded at 255 (offset -23 lines). 4 out of 9 hunks FAILED -- saving rejects to file server/semaphore.c.rej patching file server/signal.c Hunk #1 succeeded at 99 (offset 1 line). Hunk #2 succeeded at 241 (offset 1 line). Hunk #3 succeeded at 284 (offset 1 line). Hunk #4 succeeded at 297 (offset 1 line). Hunk #5 succeeded at 327 (offset 1 line). patching file server/thread.c Hunk #1 succeeded at 656 (offset 3 lines). Hunk #2 succeeded at 671 (offset 3 lines). Hunk #3 succeeded at 740 (offset 3 lines). patching file server/thread.h patching file server/trace.c Hunk #1 succeeded at 1662 (offset 70 lines). Hunk #2 succeeded at 1699 (offset 70 lines).
against 2.5-git.
https://bugs.winehq.org/show_bug.cgi?id=29582
--- Comment #34 from Daniel Santos daniel.santos@pobox.com --- (In reply to winetest from comment #33)
The patch needs rebase.
Awesome bot! :)
I will not be maintaining the POSIX semaphore patch set as I have a better replacement in the works (well, it's been sitting for most of the last year, but I plan on completing it in the next few months). Using POSIX synchronization is a no-go for Wine because it's design is flawed in that they cannot be used to interact in between 32- and 64-bit code. Further, the way they use shared memory doesn't offer much integrity guarantees for when one process misbehaves. One process can corrupt the object in shared memory causing another to crash, which isn't acceptable for Wine.
For now it's best to use the older hack and Ronny Schmatzler's rebase is the latest (I'll try to rebase that soon).
https://bugs.winehq.org/show_bug.cgi?id=29582
chriscoolie3@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |chriscoolie3@gmail.com
--- Comment #35 from chriscoolie3@gmail.com --- (In reply to Daniel Santos from comment #34)
(In reply to winetest from comment #33)
The patch needs rebase.
Awesome bot! :)
I will not be maintaining the POSIX semaphore patch set as I have a better replacement in the works (well, it's been sitting for most of the last year, but I plan on completing it in the next few months). Using POSIX synchronization is a no-go for Wine because it's design is flawed in that they cannot be used to interact in between 32- and 64-bit code. Further, the way they use shared memory doesn't offer much integrity guarantees for when one process misbehaves. One process can corrupt the object in shared memory causing another to crash, which isn't acceptable for Wine.
For now it's best to use the older hack and Ronny Schmatzler's rebase is the latest (I'll try to rebase that soon).
Definitely waiting on this patch man! Thanks for all your work on this.
https://bugs.winehq.org/show_bug.cgi?id=29582
Wyatt Ward wyatt8750@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |wyatt8750@gmail.com
--- Comment #36 from Wyatt Ward wyatt8750@gmail.com --- So, has any additional work been done on these patches since May?
I am not quite experienced enough with POSIX to be of much use, but what is the "alternative method" to the semaphore patches, anyway?
This bug is still driving me insane.
https://bugs.winehq.org/show_bug.cgi?id=29582
w@saylo.rs changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |w@saylo.rs
https://bugs.winehq.org/show_bug.cgi?id=29582
Daniel Santos daniel.santos@pobox.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #52963|0 |1 is obsolete| |
--- Comment #37 from Daniel Santos daniel.santos@pobox.com --- Created attachment 58899 --> https://bugs.winehq.org/attachment.cgi?id=58899 Updated for SWBF I and II for wine-2.9 (still slow)
Sorry for the neglect guys. I've updated the patch for wine-2.9, but things in Wine have changed quite a bit and it's very slow again (50 second load time on my older Phenom machine). I don't know the cause of that, but I'll experiment with this on an older version of Wine later on. There may be some things that are implemented properly now that were just skipped before, but that correct implementation happens to be slow.
https://bugs.winehq.org/show_bug.cgi?id=29582
Anton Romanov theli.ua@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |theli.ua@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=29582
Maxim gamer1119@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gamer1119@gmail.com
--- Comment #38 from Maxim gamer1119@gmail.com --- I would love to help but don't know where to begin. What can I look at to start tackling this issue? I'm driven mad with wanting to play this properly on Linux and I don't get how it can't for a 12yo game.
https://bugs.winehq.org/show_bug.cgi?id=29582
Anton Romanov theli.ua@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|theli.ua@gmail.com |
https://bugs.winehq.org/show_bug.cgi?id=29582
--- Comment #39 from Daniel Santos daniel.santos@pobox.com --- (In reply to Maxim Stewart from comment #38)
I would love to help but don't know where to begin. What can I look at to start tackling this issue? I'm driven mad with wanting to play this properly on Linux and I don't get how it can't for a 12yo game.
Well, you're in a little bit of luck. I never brought the EA remakes, because despite the stunning graphics, the game design its self was horrid. I saw an update on Steam and presumably multiplayer functionality has been restored without having to resort to GameRanger or some crap like that. Locking in multiplayer lobby functionality to a fixed provider (that can shut it down whenever they please) is hostile towards consumers anyway -- there is no technological reason to not allow the user to select a different lobby server. Maybe one day we'll get legislators who actually understand technological ethics and ban this type of crap in future products, but I guess I'm dreaming now....
ANYWAY, I'm in the final stages of a patch set and you are welcome to try it.
git clone https://github.com/daniel-santos/wine git checkout hybrid-sync
When you run wine, you need to set a few environment variables to enable the patch:
STAGING_SHARED_MEMORY=1 STAGING_SHM_SYNC=1 WINEPREFIX=<your_prefix> \ wine GameData/BattlefrontII.exe
I'm in the process of re-running the tests, and I haven't tested this on swbf in a while (I should probably do that soon!). Now I have to un-suspend my tests and go back to having direct 3d tests flash different colors on my monitor until it finally manages to trigger a seizure -- *then* I'll know it's finally ready.
https://bugs.winehq.org/show_bug.cgi?id=29582
--- Comment #40 from Maxim Stewart gamer1119@gmail.com --- (In reply to Daniel Santos from comment #39)
(In reply to Maxim Stewart from comment #38)
I would love to help but don't know where to begin. What can I look at to start tackling this issue? I'm driven mad with wanting to play this properly on Linux and I don't get how it can't for a 12yo game.
Well, you're in a little bit of luck. I never brought the EA remakes, because despite the stunning graphics, the game design its self was horrid. I saw an update on Steam and presumably multiplayer functionality has been restored without having to resort to GameRanger or some crap like that. Locking in multiplayer lobby functionality to a fixed provider (that can shut it down whenever they please) is hostile towards consumers anyway -- there is no technological reason to not allow the user to select a different lobby server. Maybe one day we'll get legislators who actually understand technological ethics and ban this type of crap in future products, but I guess I'm dreaming now....
ANYWAY, I'm in the final stages of a patch set and you are welcome to try it.
git clone https://github.com/daniel-santos/wine git checkout hybrid-sync
When you run wine, you need to set a few environment variables to enable the patch:
STAGING_SHARED_MEMORY=1 STAGING_SHM_SYNC=1 WINEPREFIX=<your_prefix> \ wine GameData/BattlefrontII.exe
I'm in the process of re-running the tests, and I haven't tested this on swbf in a while (I should probably do that soon!). Now I have to un-suspend my tests and go back to having direct 3d tests flash different colors on my monitor until it finally manages to trigger a seizure -- *then* I'll know it's finally ready.
Oh man are the graphics beautiful; the sound design is awesome too but the game play is boring and just a standard FPS cluster bomb. I bought the first game but refuse to get the second. I also agree with the bull surrounding multilayer servers. Anyway, THANK YOU for working on this patch!! I would give you the biggest kiss and hug of all time if I could! XD Now, I'm using the Steam version of BF2 and running that through PlayOnLinux. I've tried figuring out how to import wine version that aren't hosted by PoL but am sadly lacking in Google foo or brain power and am still unclear as to how to do this. Got any advice? I already requested PoL to make a wine version with the patch but have gotten no word or update from them. Anyway, I'll try again (it's been about a year since I last tried) to get this working my end and will give you whatever info I obtain if successful. =]
https://bugs.winehq.org/show_bug.cgi?id=29582
--- Comment #41 from Daniel Santos daniel.santos@pobox.com --- (In reply to Maxim Stewart from comment #40)
Oh man are the graphics beautiful; the sound design is awesome too but the game play is boring and just a standard FPS cluster bomb. I bought the first game but refuse to get the second. I also agree with the bull surrounding multilayer servers. Anyway, THANK YOU for working on this patch!! I would give you the biggest kiss and hug of all time if I could! XD Now, I'm using the Steam version of BF2 and running that through PlayOnLinux. I've tried figuring out how to import wine version that aren't hosted by PoL but am sadly lacking in Google foo or brain power and am still unclear as to how to do this. Got any advice? I already requested PoL to make a wine version with the patch but have gotten no word or update from them. Anyway, I'll try again (it's been about a year since I last tried) to get this working my end and will give you whatever info I obtain if successful. =]
Well, graphics and sound alone won't do it for me -- it's like coca-cola where you get a lot of pop, zip, fiz, but no substance or bang. It's just so sad they'll put all that work and talent into inventing new ways of making amazing graphics and then attach a crap game to it. It's like painting a masterpiece only to cut it out of the frame, rub a glue stick on the back and sticking it to the trunk of a beat-up 1978 monte carlo with fading paint and a busted muffler. I mean, it's their masterpiece and they can do whatever they want with it, but damn!
Anyway, I tested it it's working great with SWBF2. The computer I tested on is old (quad-core Phenom) and with the patch disabled it takes 87.5 seconds to load vs 12.3 seconds with. I only tested an old retail DVD version and not the recently patched one from steam, but I doubt much has changed structurally in the program its self.
I don't think this patch will be in PoL or Wine anytime soon because it's a *massive* change with around 8k new lines of code (not counting 2k lines of debugging and verification code) and altering a lot of how the wineserver works (which is at the core of Wine). My best hope is to have it in wine-staging within a month or two, but it still needs a lot of cleanup. However, I presume that something like the little hack patch could end up in PoL -- I haven't used it much and I'm not sure how their "connectors" work.
As far as integrating it with PoL, I don't know how you can do that. To my knowledge, you would just have to build it. There is a guide here: https://wiki.winehq.org/Building_Wine, but it's not very easy for the uninitiated. :o Then again, after you do it the first time it will get easier the next time you need to build it for some reason. The only thing you would do differently is get the sources from my github account and checkout the "hybrid-sync" branch.
As an afterthought, I have not yet tested building only 32-bit (with a 32-bit server), but that will be fine as long as I didn't break something. :D
https://bugs.winehq.org/show_bug.cgi?id=29582
--- Comment #42 from Maxim Stewart gamer1119@gmail.com --- (In reply to Daniel Santos from comment #41)
Well, graphics and sound alone won't do it for me -- it's like coca-cola where you get a lot of pop, zip, fiz, but no substance or bang. It's just so sad they'll put all that work and talent into inventing new ways of making amazing graphics and then attach a crap game to it. It's like painting a masterpiece only to cut it out of the frame, rub a glue stick on the back and sticking it to the trunk of a beat-up 1978 monte carlo with fading paint and a busted muffler. I mean, it's their masterpiece and they can do whatever they want with it, but damn!
Anyway, I tested it it's working great with SWBF2. The computer I tested on is old (quad-core Phenom) and with the patch disabled it takes 87.5 seconds to load vs 12.3 seconds with. I only tested an old retail DVD version and not the recently patched one from steam, but I doubt much has changed structurally in the program its self.
I don't think this patch will be in PoL or Wine anytime soon because it's a *massive* change with around 8k new lines of code (not counting 2k lines of debugging and verification code) and altering a lot of how the wineserver works (which is at the core of Wine). My best hope is to have it in wine-staging within a month or two, but it still needs a lot of cleanup. However, I presume that something like the little hack patch could end up in PoL -- I haven't used it much and I'm not sure how their "connectors" work.
As far as integrating it with PoL, I don't know how you can do that. To my knowledge, you would just have to build it. There is a guide here: https://wiki.winehq.org/Building_Wine, but it's not very easy for the uninitiated. :o Then again, after you do it the first time it will get easier the next time you need to build it for some reason. The only thing you would do differently is get the sources from my github account and checkout the "hybrid-sync" branch.
As an afterthought, I have not yet tested building only 32-bit (with a 32-bit server), but that will be fine as long as I didn't break something. :D
You had me hee-hawing at a master piece being cut out and glued to the car. I just imagined The Scream by Munch being cut out by a kid who's 5 and grinning stupidly with glue stick glue in his mouth. XD
Now, I don't think that the Steam version changed much either even after the updates. Still, it's worth my asking you since you coded the patch and know more about what's going on with it. Anyway, I compiled the wine version in 32bit given that when I ran the ./configure command it complained about not having some 32bit dev-libs needed. I hadn't thought to pass an argument to the command to prep it for 64bit instead. My machine is 64bit but I assumed that you had made the version 32bit for some reason. Shame on me for being presumptuous and on top of that building the version in a VirtualBox. <sigh> Anyway, I looked through the info for PlayOnLinux and I did find where they're storing their Wine versions. Their layout is quite different from the compile directory but I assume it follows standard layouts that a normal Wine install would have. I bet you I could just run the Steam game from cli and use the command you gave instead of going through PoL itself.
Here is what I did for compile in VirtualBox running 32bit Ubuntu 16.04 LTS 1. Make sure to add or uncomment the sources URIs in /etc/apt/sources.list 2. sudo apt-get update 3. sudo apt-get build-dep wine 4. git clone https://github.com/daniel-santos/wine 5. git checkout hybrid-sync 6. cd /the/location/of/wineBuildDir/ 7. ./configure // Add a switch to build in 64 bit else just leave as is. 8. make 9. make install // Optional since we can run from the build dir.
TO-DO 10. STAGING_SHARED_MEMORY=1 STAGING_SHM_SYNC=1 WINEPREFIX=<your_prefix> wine GameData/BattlefrontII.exe
First, did I do it wrong? Second, if no, then I need to test the compiled version and get back to you. But, from the looks of it, nothing went wrong during the compiling of your Wine version in 32bit. Now, I gotta do it for the 64bit version. Quick confirmation, the WINEPREFIX is the location path for my virtual drive containing my Steam and game, yes? So, it'd be the master folder of the drive folder called drive_c or is it drive_c itself?
https://bugs.winehq.org/show_bug.cgi?id=29582
ignacio rodríguez ninovolador@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|ninovolador@gmail.com |
https://bugs.winehq.org/show_bug.cgi?id=29582
--- Comment #43 from Maxim Stewart gamer1119@gmail.com --- OK here is an update with what I did. I did both 32bit and 64bit builds so will list the steps I took.
Build process:
1. sudo add-apt-repository ppa:ubuntu-wine/ppa OR 1. Make sure to add or uncomment the sources URIs in /etc/apt/sources.list 2. sudo apt-get update 3. sudo apt-get build-dep wine 4. git clone https://github.com/daniel-santos/wine 5. cd /the/location/of/wineBuildDir/ 6. git checkout hybrid-sync 7. ./configure OR configure --enable-win64 8. make 9. make install // Optional since we can run from the build dir.
To run from winebuilddir cd wineBuildDir/loader/ // This location has the Wine exe. 10. STAGING_SHARED_MEMORY=1 STAGING_SHM_SYNC=1 WINEPREFIX=<your_prefix> wine GameData/BattlefrontII.exe
My specific usage examples for "launching" 32bit & 64bit:
32bit: STAGING_SHARED_MEMORY=1 STAGING_SHM_SYNC=1 WINEPREFIX="/home/abaddon/.PlayOnLinux/wineprefix/z:/" ./wine "C:\Program Files\Steam\steamapps\common\Star Wars Battlefront II\GameData\BattlefrontII.exe"
64bit: STAGING_SHARED_MEMORY=1 STAGING_SHM_SYNC=1 WINEPREFIX="/home/abaddon/.PlayOnLinux/wineprefix/z:/" ./wine64 "C:\Program Files\Steam\steamapps\common\Star Wars Battlefront II\GameData\BattlefrontII.exe"
For 32bit I get the following errors.
0012:err:module:import_dll Library mscoree.dll (which is needed by L"C:\windows\Microsoft.NET\Framework\v4.0.30319\mscorsvw.exe") not found 0012:err:module:attach_dlls Importing dlls for L"C:\windows\Microsoft.NET\Framework\v4.0.30319\mscorsvw.exe" failed, status c0000135 000f:err:service:process_send_command service protocol error - failed to write pipe! 000f:fixme:service:scmdatabase_autostart_services Auto-start service L"clr_optimization_v4.0.30319_32" failed to start: 1053 wineserver: ERROR: shared memory corruption detected: 0xf758d008 should be fdfdfdfd, found aaaaaaaa ... // the wine server error repeats multiple times thus I am putting dots 000d:err:menubuilder:RefreshFileTypeAssociations failed wait for semaphore wineserver: shm_slab.c:530: shm_cache_free: Assertion `!cache->count' failed.
This error could be because I am lacking the proper mscoree.dll (or so it seems) and I've been trying to figure out how to fix this with no success so far. I am still doing research on how to get the library included properly. The winserver error is of interest to me because you had said that much of your changes were there. So the error might not be tied to the other issue. I'll defer to your judgment since you know the system more than I do.
For 64bit I get a message about not being able to load a 32bit wine containers but that's not surprising after I looked into Wine's build instructions and they said much the same as a warning.
My system info if needed:
uname -a: Linux abaddon 4.4.0-96-generic #119-Ubuntu SMP Tue Sep 12 14:59:54 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
lsb_release -a No LSB modules are available. Distributor ID: LinuxMint Description: Linux Mint 18 Sarah Release: 18 Codename: sarah
https://bugs.winehq.org/show_bug.cgi?id=29582
--- Comment #44 from Daniel Santos daniel.santos@pobox.com --- (In reply to Maxim Stewart from comment #42)
You had me hee-hawing at a master piece being cut out and glued to the car. I just imagined The Scream by Munch being cut out by a kid who's 5 and grinning stupidly with glue stick glue in his mouth. XD
Thanks in turn for the laugh! :)
wineserver: ERROR: shared memory corruption detected: 0xf758d008 should be fdfdfdfd, found aaaaaaaa ... // the wine server error repeats multiple times thus I am putting dots 000d:err:menubuilder:RefreshFileTypeAssociations failed wait for semaphore wineserver: shm_slab.c:530: shm_cache_free: Assertion `!cache->count' failed.
This error could be because I am lacking the proper mscoree.dll (or so it seems) and I've been trying to figure out how to fix this with no success so
No, it's a bug in my last release. I'll be releasing again today or tomorrow. So after that, just change into your /the/location/of/wineBuildDir/ and run this to update the sources instead of git clone and checkout:
git fetch git reset --hard origin/hybrid-sync
You would normally do "git pull", but I'm committing in a "non-fast-forward" fashion, so you have to do a hard reset.
But for help with general building and the like, please visit #wine on irc.freenode.net. But here's a few helpers anyway.
- sudo add-apt-repository ppa:ubuntu-wine/ppa OR
- Make sure to add or uncomment the sources URIs in /etc/apt/sources.list
- sudo apt-get update
- sudo apt-get build-dep wine
That sounds right, I'm on a different Linux distro and I haven't played with Ubuntu or Debian in a while
- cd /the/location/of/wineBuildDir/
- ./configure // Add a switch to build in 64 bit else just leave as is.
You only need the 32-bit version and it's probably simplest to just build it w/o --enable-win64 or --with-wine64, but if you want to build the 32- and 64-bit versions, here's a quickie.
1. First configure the 64-bit in one directory with --enable-win64, 2. build it, 3. In a separate directory, configure and build the 32-bit using --with-wine64= to tell it where you built the 64-bit version.
For example:
mkdir build/32 build/64 cd build/64 CFLAGS="-O2" ../../configure --enable-win64 (any other arguments) make -j5 cd ../32 CFLAGS="-m32 -O2" ../../configure --with-wine64=../64 (any other arguments) make -j5
This is known as an out-of-tree build and most projects prefer that you use that instead of building in-tree where the source code and output are mixed in the same directories.
- make
It's faster if you add -j<n> where n is the number of CPU cores (times two if you have hyperthreading) plus one. e.g., make -j5
Quick confirmation, the WINEPREFIX is the location path for my virtual drive containing my Steam and game, yes? So, it'd be the master folder of the drive folder called drive_c or is it drive_c itself?
WINEPREFIX is the directory under drive_c. You'll also see things like system.reg, user.reg, dosdevices, etc. in that directory.
https://bugs.winehq.org/show_bug.cgi?id=29582
--- Comment #45 from Maxim Stewart gamer1119@gmail.com --- (In reply to Daniel Santos from comment #44)
(In reply to Maxim Stewart from comment #42)
You had me hee-hawing at a master piece being cut out and glued to the car. I just imagined The Scream by Munch being cut out by a kid who's 5 and grinning stupidly with glue stick glue in his mouth. XD
Thanks in turn for the laugh! :)
Of course!
I've gone and done as you recommended and done the "git fetch" and "git reset --hard origin/hybrid-sync" and reconfigured and rebuilt the binaries out of tree.
I run BF2 with this command: STAGING_SHARED_MEMORY=1 STAGING_SHM_SYNC=1 WINEPREFIX="/home/abaddon/.PlayOnLinux/wineprefix/z:/" ./wine "C:\Program Files\Steam\steamapps\common\Star Wars Battlefront II\GameData\BattlefrontII.exe"
I get to a black screen for a bit and then it seems to crash. Here is its output: https://paste.ubuntu.com/26414912/
I've also run the compiled wine version without enabling the options like so: WINEPREFIX="/home/abaddon/.PlayOnLinux/wineprefix/z:/" ./wine "C:\Program Files\Steam\steamapps\common\Star Wars Battlefront II\GameData\BattlefrontII.exe"
I get the following output: https://paste.ubuntu.com/26414930/
I hope these stay up long enough for you to get to them. I can also post them on my Google Drive for you to view too. Anyway, I'll let you look over them for further guidance since what I think might be wrong might not be what you think is wrong.
https://bugs.winehq.org/show_bug.cgi?id=29582
tokktokk fdsfgs@krutt.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fdsfgs@krutt.org
https://bugs.winehq.org/show_bug.cgi?id=29582
--- Comment #46 from Maxim Stewart gamer1119@gmail.com --- OK, Here is what I did after install Ubuntu 16.04.4 (was previously on Mint 18) and it works.
I first installed Wine 1.8 which setup it's default stuff. (The compiled Wine references the .wine archive and settings there. I couldn't find Wincfg in the compiled program so used the system wine to do configurations. The biggest thing for me was needing to set Pulseaudio because once SW: BF2 was launched it wouldn't detect audio unless I set Pulseaudio. In addition, you need to change the game's sound settings to use Software Emulation than Hardware. As maps wont have sound but the menus will.) I then installed PlayOnLinux and used it to install Steam. I IGNORED the PoL SW: BF2 installer and went straight to Steam. Once in Steam I then downloaded SW: BF2. While that was downloading, I did the following:
1. wget https://dl.winehq.org/wine-builds/Release.key sudo apt-key add Release.key sudo apt-add-repository 'https://dl.winehq.org/wine-builds/ubuntu/'
2. sudo apt-get update
3. sudo apt-get install flex bison gcc-multilib g++-multilib wine-devel \ libx11-dev:i386 libfreetype6-dev:i386 libasound2-dev:i386
4. git clone https://github.com/daniel-santos/wine 5. cd /the/location/of/wineBuildDir/ 6. mkdir -p bin/{wine32,wine64} 7. git checkout hybrid-sync git fetch git reset --hard origin/hybrid-sync
8. cd <wineBuildDir>/build/wine32
CFLAGS="-m32 -O2" ../../configure // Note: -02 means use compiler optimize // level 2 && -00 means no optimization // -03 I think is the highest. // --with-wine64=../64 (any other arguments) // -m32 means do 32bit build
9. make -j<number of CPU cores + 1> // Hyper threading doubles your core count so take note. Example: make -j7 // I have a hex core AMD processor
[ Launch ]
10. cd loader/
11. WINEDEBUG=fixme-all STAGING_SHARED_MEMORY=1 STAGING_SHM_SYNC=1 WINEPREFIX="/home/<YOUR USER NAME>/.wine" ./wine "C:\Program Files (x86)\Steam\Steam.exe" -no-cef-sandbox
NOTES: Ignore the warnings when configure is done. Other libs that are stated missing seemed to make the game load in a stuttering way when I installed them. In addition, installing alsa might help with wonky audio issues but it's been a crapshot for me.
sudo apt-get install alsa-base alsa-tools alsa-tools-gui alsa-utils alsa-oss // Reboot after install
To summaries, I think when I was on Mint 18, the wine package build tools were wonky. It IS working and loading the game quickly now since I am in Ubuntu 16.04.4!! THANK YOU Daniel Santos for all the guidance while I was working on trying to compile and get this working!
https://bugs.winehq.org/show_bug.cgi?id=29582
Nikolay Borodin monsterovich@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |monsterovich@gmail.com
--- Comment #47 from Nikolay Borodin monsterovich@gmail.com --- Wine from this repo https://github.com/daniel-santos/wine crashes on start-up. Is there patch for latest wine version or any other fix?
https://bugs.winehq.org/show_bug.cgi?id=29582
--- Comment #48 from Nikolay Borodin monsterovich@gmail.com --- (In reply to Nikolay Borodin from comment #47)
Wine from this repo https://github.com/daniel-santos/wine crashes on start-up. Is there patch for latest wine version or any other fix?
nvm, it works I built binaries for lazy:
https://drive.google.com/open?id=16sTi0tPmNEnoDeUuY6K1_VugEsH3QPJu
https://bugs.winehq.org/show_bug.cgi?id=29582
joaopa jeremielapuree@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree@yahoo.fr
--- Comment #49 from joaopa jeremielapuree@yahoo.fr --- Does the bug still occur with vanilla wine-4.5?
https://bugs.winehq.org/show_bug.cgi?id=29582
victor@tuxayo.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |victor@tuxayo.net
--- Comment #50 from victor@tuxayo.net --- (In reply to joaopa from comment #49)
Does the bug still occur with vanilla wine-4.5?
Still happens with Proton 4.11-10 based on wine-4.11
So we can safely suppose that it happens also with vanilla wine-4.11
https://bugs.winehq.org/show_bug.cgi?id=29582
--- Comment #51 from Béla Gyebrószki gyebro69@gmail.com --- It should be noted that Wine-Staging with esync enabled considerably reduces loading times in SW:Battlefront II. In vanilla Wine 5.0-rc2 loading a map takes 120-125 seconds for me, in Wine-Staging it takes only 35-40 secs. On a fsync-enabled kernel and Staging patched with the fsync patches (but esync is disabled) also loads a map in about half a minute.
https://bugs.winehq.org/show_bug.cgi?id=29582
Anya animegirl@stronzi.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |animegirl@stronzi.org
https://bugs.winehq.org/show_bug.cgi?id=29582
--- Comment #52 from joaopa jeremielapuree@yahoo.fr --- Does the bug still occur with plain wine-7.0-rc2?
https://bugs.winehq.org/show_bug.cgi?id=29582
Chris schM0ggi@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |schM0ggi@web.de
https://bugs.winehq.org/show_bug.cgi?id=29582
--- Comment #53 from Chris schM0ggi@web.de --- Hi,
I've stumbled over this while searching on the web about the exact problem. Running the classic Battlefront 2 via Wine is giving me long loading times when creating or joining a game. While creating a game is fine in the end, joining a server (LAN game in my case) is not possible (interesting enough, on the map Coruscant it is possible in 70/30% of the times). The error "connection to host lost" appears. As I understand it from the comments, the long loading time is the reason of this (connection timeout).
I'm running Fedora 37 with the latest Wine-staging 8.2. The problem is present here. Seeing as it was reported with Wine version 1.x and after all this years, I fear there is no fix for that? And I assume the hack you guys are talking about doesn't work with the newest Wine?
I have to admit, I didn't test it yet with Proton through Steam, as I have the GOG version. But I can easily do this with adding it as a "non-steam game" and setting the compatibilty to Proton.
https://bugs.winehq.org/show_bug.cgi?id=29582
--- Comment #54 from Chris schM0ggi@web.de --- I ran some tests with Proton. I can happily say, that using Proton (current 7.0.6) does fix it completely. Loading times are fast and on the same level like in Windows. No more problems regarding joining games.
I did also a test with the current custom wine_ge build. https://github.com/GloriousEggroll/wine-ge-custom
Loading times are much lower than with with vanilla Wine-staging 8.2, but not as quick as with Proton. But more importantly, with wine-ge, I guess due to the fast enough loading times, joining a game does work without problems.
I ran my tests with several bigger maps like Hoth, where loading times with vanilla Wine were the longest.
Strongly advise, that wine devs talk to Valve and/or Glorious about that.
https://bugs.winehq.org/show_bug.cgi?id=29582
--- Comment #55 from Maxim Stewart gamer1119@gmail.com --- Ditto that Proton 7.0.6 is legit making it work properly. <3 Though, I think Wine have helped in making that happen. Now if only I can get the mod tools to work locally too. =P I could then probably legit just delete my GPU Passthrough setup.
https://bugs.winehq.org/show_bug.cgi?id=29582
Neko-san nekoNexus@protonmail.ch changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nekoNexus@protonmail.ch
https://bugs.winehq.org/show_bug.cgi?id=29582
Alex Henrie alexhenrie24@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |alexhenrie24@gmail.com Summary|Star Wars Battlefront (I |Star Wars Battlefront (I |and II) "Loading" screen |and II) "Loading" screen |very slow. |very slow, causes | |multiplayer timeout
--- Comment #56 from Alex Henrie alexhenrie24@gmail.com --- I'm adding "causes multiplayer timeout" to the title of this bug report because I spent several hours today trying to figure out what was causing the "Connection to host lost" error, not realizing that it was related to the long loading times. Running the game with Wine Staging and WINEESYNC=1 fixed multiplayer for me.
https://bugs.winehq.org/show_bug.cgi?id=29582
Alex Henrie alexhenrie24@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bellamorte42@gmail.com
--- Comment #57 from Alex Henrie alexhenrie24@gmail.com --- *** Bug 43874 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=29582
soredake broaden_acid002@simplelogin.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|broaden_acid002@simplelogin | |.com |
-
wine-bugs＠winehq.org -
WineHQ Bugzilla