Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Any luck with wine 1.9.8 and Diablo 1?
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Gamers & Players
View previous topic :: View next topic  
Author Message
zlg
Retired Dev
Retired Dev


Joined: 11 Sep 2012
Posts: 49
Location: Earth

PostPosted: Tue May 10, 2016 2:45 am    Post subject: Any luck with wine 1.9.8 and Diablo 1? Reply with quote

I'm trying to run a Diablo 1 hack (called The Hell), and I'm running into the ddraw issue where the menu screen is black. Every ddraw.dll hack I've seen is for much older versions of wine.

I've made sure app-emulation/wine is compiled with abi_x86_32 and ACCEPT_KEYWORDS for it is ~x86 so it's the latest available. I previously tried the -9999 version as well.

I load TheHell.exe up, the intro plays as expected, sound is good, etc. I get to the menu and it's a solid black screen. I've tried all sorts of winecfg settings, ensured that DirectDrawRenderer is set to "gdi" in the application's default settings in the registry, etc.

There's a bug on winehq's bug tracker: https://bugs.winehq.org/show_bug.cgi?id=2082

The latest update is from January, for wine 1.9.2, which isn't in the tree.

I'm running ~amd64 with Nvidia graphics. The stock wine apps work fine; I have a feeling it's just the ddraw portion. If I could see the menu, I could probably get into the game to test and make sure it works as expected.
Back to top
View user's profile Send private message
BobWya
Apprentice
Apprentice


Joined: 12 Aug 2012
Posts: 228
Location: Cambridge,UK

PostPosted: Wed May 11, 2016 9:45 pm    Post subject: Re: Any luck with wine 1.9.8 and Diablo 1? Reply with quote

zlg wrote:

There's a bug on winehq's bug tracker: https://bugs.winehq.org/show_bug.cgi?id=2082

The latest update is from January, for wine 1.9.2, which isn't in the tree.

I'm running ~amd64 with Nvidia graphics. The stock wine apps work fine; I have a feeling it's just the ddraw portion. If I could see the menu, I could probably get into the game to test and make sure it works as expected.


But I've checked my locally checked out Wine git tree. The Wine 1.9.2 patch (Wine Bug 2082 you linked to) should still apply cleanly. Rather amusing workaround :lol:
Can't see why this wouldn't still work - it's such a simple work-around... Maybe some of the gdi code has been re-factored...

But if you need out-of-tree, recent builds of Wine... I'm keeping everything from wine 1.8rc1 - 9999 in my overlay (bobwya). They're pretty vanilla - I do apply NPHardness's gstreamer:1.0 patch to all the gstreamer:0.1 based 1.9.x branch (1.9.0 , 1.9.1) - in addition to the 1.8.x stable branch.
_________________
system: G751JT (ASUS-NotebookSKU); processor: Intel(R) Core(TM) i7-4710HQ CPU @ 2.50GHz; memory: 32GiB System Memory; display: GM204M [GeForce GTX 970M]; disk: 2048GB Samsung SSD 850;BD-CMB UJ172 S;1024GB Samsung SSD 850
Back to top
View user's profile Send private message
frostschutz
Advocate
Advocate


Joined: 22 Feb 2005
Posts: 2977
Location: Germany

PostPosted: Wed May 11, 2016 11:14 pm    Post subject: Reply with quote

I haven't played Diablo 1 in a while, but I've always had to patch it (that or learn the menu navigation by heart :lol:).

The patch I was using: (I'm sure it's in the bug tracker too)

Code:
--- wine-1.6.1/dlls/ddraw/ddraw.c   2013-11-15 13:30:24.000000000 -0600
+++ wine-1.6.1/dlls/ddraw/ddraw.c   2014-04-22 21:31:41.000000000 -0500
@@ -967,7 +967,7 @@
     if ((cooplevel & DDSCL_EXCLUSIVE)
             && (window != ddraw->dest_window || !(ddraw->cooperative_level & DDSCL_EXCLUSIVE)))
     {
-        hr = wined3d_device_acquire_focus_window(ddraw->wined3d_device, window);
+        hr = wined3d_device_acquire_focus_window(ddraw->wined3d_device, GetDesktopWindow());
         if (FAILED(hr))
         {
             ERR("Failed to acquire focus window, hr %#x.\n", hr);

--- wine-1.6.1/dlls/wined3d/swapchain.c   2013-11-15 13:30:24.000000000 -0600
+++ wine-1.6.1/dlls/wined3d/swapchain.c   2014-04-22 21:34:24.000000000 -0500
@@ -677,7 +677,7 @@
     TRACE("Copying surface %p to screen.\n", front);
 
     src_dc = front->hDC;
-    window = swapchain->win_handle;
+    window = GetDesktopWindow();
     dst_dc = GetDCEx(window, 0, DCX_CLIPSIBLINGS | DCX_CACHE);
 
     /* Front buffer coordinates are screen coordinates. Map them to the


It still causes draw errors in the menu but at least it's visible and usable. Or used to be. Hey, I should find the time to play it again...
Back to top
View user's profile Send private message
zlg
Retired Dev
Retired Dev


Joined: 11 Sep 2012
Posts: 49
Location: Earth

PostPosted: Sat May 14, 2016 11:41 pm    Post subject: Reply with quote

frostschutz wrote:
I haven't played Diablo 1 in a while, but I've always had to patch it (that or learn the menu navigation by heart :lol:).

The patch I was using: (I'm sure it's in the bug tracker too)

Code:
--- wine-1.6.1/dlls/ddraw/ddraw.c   2013-11-15 13:30:24.000000000 -0600
+++ wine-1.6.1/dlls/ddraw/ddraw.c   2014-04-22 21:31:41.000000000 -0500
@@ -967,7 +967,7 @@
     if ((cooplevel & DDSCL_EXCLUSIVE)
             && (window != ddraw->dest_window || !(ddraw->cooperative_level & DDSCL_EXCLUSIVE)))
     {
-        hr = wined3d_device_acquire_focus_window(ddraw->wined3d_device, window);
+        hr = wined3d_device_acquire_focus_window(ddraw->wined3d_device, GetDesktopWindow());
         if (FAILED(hr))
         {
             ERR("Failed to acquire focus window, hr %#x.\n", hr);

--- wine-1.6.1/dlls/wined3d/swapchain.c   2013-11-15 13:30:24.000000000 -0600
+++ wine-1.6.1/dlls/wined3d/swapchain.c   2014-04-22 21:34:24.000000000 -0500
@@ -677,7 +677,7 @@
     TRACE("Copying surface %p to screen.\n", front);
 
     src_dc = front->hDC;
-    window = swapchain->win_handle;
+    window = GetDesktopWindow();
     dst_dc = GetDCEx(window, 0, DCX_CLIPSIBLINGS | DCX_CACHE);
 
     /* Front buffer coordinates are screen coordinates. Map them to the


It still causes draw errors in the menu but at least it's visible and usable. Or used to be. Hey, I should find the time to play it again...


I used a similar patch, as shown in the bug tracker, that was pretty much just like that, and I still had the same problem. I even included a call to ERR() to see if that codepath would show up. My guess is because I didn't put it as a proper patch in the files/ dir that portage may not have actually compiled the modifications. I'll need to make sure my workflow is correct, or just create a proper patch and try again.
Back to top
View user's profile Send private message
BobWya
Apprentice
Apprentice


Joined: 12 Aug 2012
Posts: 228
Location: Cambridge,UK

PostPosted: Sun May 15, 2016 12:06 am    Post subject: Reply with quote

zlg wrote:

I used a similar patch, as shown in the bug tracker, that was pretty much just like that, and I still had the same problem. I even included a call to ERR() to see if that codepath would show up. My guess is because I didn't put it as a proper patch in the files/ dir that portage may not have actually compiled the modifications. I'll need to make sure my workflow is correct, or just create a proper patch and try again.


The best way to check if your user patches are being applied is to enable build logs for all your packages:
Code:
/etc/portage/make.conf

FEATURES=" ... compress-build-logs ... "
PORT_LOGDIR="/var/log/portage/build"


Code:
/etc/bash/bashrc

alias less='less -r'
alias lsdate='ls -Alhrt'


With those settings I can sort my logs quickly and view them directly/ colourised - with less (even though they are compressed)...

Then you can run your offending log through grep to test if any User patches were applied, e.g.:
Code:
gunzip -c 'app-emulation:wine-9999:20160514-104344.log.gz' | awk '{ if ($0 ~ "Applying patches") {found=1}; if (found) print $0; if ($0 ~ "User patches") {exit}; }'
 * Applying patches from /etc/portage/patches/app-emulation/wine ...
 *   wine-add_additional_x11_traces.patch ...
 [ ok ]
 *   wine-block-nvidia-xrandr-error.patch ...
 [ ok ]
 * User patches applied.


What a godsend. I was staggering about in the dark till I enabled Portage logging!! It's dead handy to be able to work out why my system just broke (after some random updates)!! 8)

Bob
_________________
system: G751JT (ASUS-NotebookSKU); processor: Intel(R) Core(TM) i7-4710HQ CPU @ 2.50GHz; memory: 32GiB System Memory; display: GM204M [GeForce GTX 970M]; disk: 2048GB Samsung SSD 850;BD-CMB UJ172 S;1024GB Samsung SSD 850
Back to top
View user's profile Send private message
zlg
Retired Dev
Retired Dev


Joined: 11 Sep 2012
Posts: 49
Location: Earth

PostPosted: Mon May 16, 2016 5:01 am    Post subject: Reply with quote

I followed your advice, produced patches myself using `diff -aurN`, emerge had no complaints. wine's not indicating that anything's going wrong, and still a black screen...

Here's a paste of the build log: http://dev.gentoo.org/~zlg/wine-build.log (warning: nearly 7MB text file)
Back to top
View user's profile Send private message
BobWya
Apprentice
Apprentice


Joined: 12 Aug 2012
Posts: 228
Location: Cambridge,UK

PostPosted: Tue May 17, 2016 9:30 pm    Post subject: Reply with quote

zlg wrote:
I followed your advice, produced patches myself using `diff -aurN`, emerge had no complaints. wine's not indicating that anything's going wrong, and still a black screen...

Here's a paste of the build log: http://dev.gentoo.org/~zlg/wine-build.log (warning: nearly 7MB text file)


I'd recommend cleaning the terminal (colour) codes from your logs before posting on a paste-bin site... :roll:

Anyhoo - so the patch applies cleanly. Obviously being a total hack - it's now totally broken.

When I get a minute I'll compile up the test case attached to Wine Bug 2082 . It'd being interesting to see how it fairs with wine-9999 / wine-1.9.10 (+staging, etc.)... Probably I'll do that tomorrow now...

Just to let you know I'm doing something(ish) 8)

Bob
_________________
system: G751JT (ASUS-NotebookSKU); processor: Intel(R) Core(TM) i7-4710HQ CPU @ 2.50GHz; memory: 32GiB System Memory; display: GM204M [GeForce GTX 970M]; disk: 2048GB Samsung SSD 850;BD-CMB UJ172 S;1024GB Samsung SSD 850
Back to top
View user's profile Send private message
zlg
Retired Dev
Retired Dev


Joined: 11 Sep 2012
Posts: 49
Location: Earth

PostPosted: Sun May 22, 2016 2:36 pm    Post subject: Reply with quote

I managed to find something that made the menus work enough to get into the game:

https://forum.winehq.org/viewtopic.php?f=2&t=22340

The file: https://www.mediafire.com/?2jicmwsx88nwsv3

The original post's mediafire link contains a hacked ddraw.dll and wined3d.dll. The patch is for wine 1.6.1's version of ddraw and wined3d, but it worked just fine with The Hell on wine 1.9.9.

I attempted to do some patching to make it work in an ebuild, but I fear it's not something easily patched due to how much has changed since 1.6.1. Regardless, the patched dlls from the mediafire link do work as long as they're put in the same directory TheHell.exe is in. Unfortunate that we have to resort to another modded file instead of proper patching...

I'll hold onto the patched dlls until the wine team finds a real fix for bug 2082... If the mediafire link ever goes down, let me know and I'll host it somewhere.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gamers & Players All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum