[SOLVED] DOOM 2016 and wine 2.8 (AlienBOB package)
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I've run into a particularly vexing problem when attempting to run DOOM 2016 with Wine. As it's a Steam game, I've tried using PlayOnLinux to set up the Steam client and run DOOM. No joy. It crashed sometime during my work shift yesterday.
Now I've tried doing it manually.
I've been told I have to set a couple of variables to let Wine know it's a 64-bit executable. Here's what I type in:
fixme:winediag:start_process Wine Staging 2.8 is a testing version containing experimental patches.
fixme:winediag:start_process Please mention your exact version when filing bug reports on winehq.org.
fixme:heap:RtlSetHeapInformation 0x340000 0 0x33fd30 4 stub
Segmentation fault
I've Googled for solutions, and every website that deals with it says it should work. But it doesn't for me. I'm at my wit's end. Installing Windows is not an option for me, for various reasons. I'd appreciate all the help I can get.
I downgraded WINE to 1.9.23 (14.1), and now my DOOM Wine instance is not crashing. However, in the process of preparing to launch DOOM, it caused my system to panic. I suspect it has to do more with my odd RAM configuration than a software configuration. I'll probably have to upgrade to a quad-channel RAM kit before I attempt another go at it.
EDIT: Lesson learned - sometimes the newest version of software is not the best; it pays to stick with the old if it still meets your needs.
Last edited by 1337_powerslacker; 06-04-2017 at 10:18 PM.
In the process of trying to save money, I cobbled together some RAM modules I had lying around, which totaled 32GB, and put them in my system. Initially, I had stability and freezing issues, but I went into the mobo BIOS, and dropped the speed to 1066 from 1333. I have been satisfied with the performance of the system from that point until just recently. I have been giving serious thought to how I actually use my system, and why my system had always harbored instability, but I didn't really pay attention to the odd freeze and erratic behavior; my biggest use of the CPU power was a kernel compilation, but that doesn't stress the RAM. However, running a semi-modern game like The Talos Principle at the highest setting, when my system froze at normal settings, I knew something was wrong. Then I began thinking about all the other times I had observed this behavior from my computer, and I then realized that all of these symptoms had but one root cause: The mix-and-match RAM configuration I had.
As I have been experimenting the past few days on getting DOOM to run on my PC, I had to admit that having fast RAM, perfectly matched to each other, would work wonders for performance, and more importantly, stability, for my system. Having said that, I am looking forward to getting the RAM kit tomorrow (6/6) and getting my gore on!
I was running a SLI NVIDIA rig for a while and one of my games would slow down after ~5 minutes of play to the point where I'd get killed, then the game would speed back up.
Turned out that one of the cards had a stuck fan. That particular game would stress the pair enough that one of them would overheat and shutdown. After it cooled down, it would start to work again.
Having written that, I've found that a solid power supply would do wonders for RAM stability; sometimes overpowering the RAM would help as well.
I was running a SLI NVIDIA rig for a while and one of my games would slow down after ~5 minutes of play to the point where I'd get killed, then the game would speed back up.
Turned out that one of the cards had a stuck fan. That particular game would stress the pair enough that one of them would overheat and shutdown. After it cooled down, it would start to work again.
Having written that, I've found that a solid power supply would do wonders for RAM stability; sometimes overpowering the RAM would help as well.
Thanks for replying. I'd just about given up hope of seeing anyone say anything.
I have a pair of GTX 970s, in SLI, and they have performed amazingly well, given their age. I bought them in December of 2015, and as yet, I see no need be to upgrade, as they continue to meet my needs, and probably will for some time.
I used to have as my signature, my system specs. My PSU is a SeaSonic, 1050W, Platinum. I have had zero issues with its performance. I know from hard experience in the past that inferior power supplies can cause a computer to misbehave in all sorts of ways. I've learned my lesson, and when I designed this system, I went for one of the best. It has given me no cause for regret.
As for the RAM, I ordered a kit recommended by ASUS (my mobo manufacturer). It's a G.SKILL Ripjaws Z Series 32GB kit. From what I've gathered from the reviews, I'll have cause for assurance that my RAM will do what it's designed for, and do it with the stability and quality that G.SKILL is known for.
Having said that, I'll keep what you said in mind. It's certainly worth considering.
Thanks again!
Last edited by 1337_powerslacker; 06-06-2017 at 06:00 AM.
Timothee "TTimo" Besset ported the id Tech4 engine to Linux (he also ported id Tech3).
ID Software were acquired by ZeniMax (the parent company of Bethesda) in 2009.
Over the years, most of the key ID people left, including Besset, Carmack and Hollenshead...
The GPL source code releases of 2005 and 2011 (for id Tech3 and id Tech4 respectively) are unique and like the Linux ports, part of history and without the likes of Carmack and Besset, are unlikely to be repeated by ZeniMax. A few minutes searching for info about ZeniMax on potential source releases or Linux ports will probably depress you.
There really is little point in buying expensive "gaming hardware" and then trying to run id Tech 5 or 6 based proprietary games (which you've presumably paid for) under wine... and the same really goes for any modern games. You need to face facts and just dual boot with Windows.
It'd be cool if you didn't spread bs. The doom 2016 steam version has a platinum rating at winehq and there are more than a few documented examples of people getting it to work. Windows is not necessary.
As for the op's issue, seems the best bet is to investigate the segmentation fault with gdb and report to the correct upstream. Perhaps wine in this case?
Multilib, nvidia.ko, wine-staging, steam, denuvo. Any of these things could be the cause, but none of them are shipped on slackware DVD.
Have the same problem on wine-stable? Does it still happen if you compile wine for your machine instead of using a binary?
Does it happen on different distribution? Just saying there are plenty of things that can go wrong here other than Alien's package.
Multilib, nvidia.ko, wine-staging, steam, denuvo. Any of these things could be the cause, but none of them are shipped on slackware DVD.
Have the same problem on wine-stable? Does it still happen if you compile wine for your machine instead of using a binary?
Does it happen on different distribution? Just saying there are plenty of things that can go wrong here other than Alien's package.
I don't know what the big deal is bringing this topic here. There's a lot of very knowledgeable Slackers who might be able to help solve the problem. It isn't known if the problem is Slackware-related or not... but it could be. Just because something isn't shipped on the Slackware DVD doesn't mean we shouldn't try and help... otherwise this forum would be pretty empty if we only supported what came on the DVD.
It'd be cool if you didn't spread bs. The doom 2016 steam version has a platinum rating at winehq and there are more than a few documented examples of people getting it to work. Windows is not necessary.
If you're going to start personal attacks, then be prepared to back up your claims. I have not said that people have not gotten it to "work". wine is a lottery and what works today may not work in the future. Then there's a fine line between platinum and garbage. That's the nature of the wine development model.
If you're into gaming and buy proprietary closed source games, engineered and compiled to run on MS windows, which don't have a Linux port available, it's practical and logical to just keep a windows install for that, install the latest graphics drivers and get the best performance with the game running natively... that may upset some of the MS hating Linux evangelists out there, but sadly it's true.
I don't know what the big deal is bringing this topic here. There's a lot of very knowledgeable Slackers who might be able to help solve the problem. It isn't known if the problem is Slackware-related or not... but it could be. Just because something isn't shipped on the Slackware DVD doesn't mean we shouldn't try and help... otherwise this forum would be pretty empty if we only supported what came on the DVD.
I'd understand if this was ioDooM from SBo or something with actual source available. That could technically get fixed, and it's perfectly legal to do so.
But steam on wine is unsupported by steam devs and tampering with it is forbidden by EULA, so it isn't clear to me what do you expect these knowledgeable slackers to do about it.
It can work fine one day & break the next day with no apparent reason, even if one build worked fine the next build may not and there's no option to roll back a patch.
Legally, all we can do is shout at it. But if you want to support it, good luck.
I'd understand if this was ioDooM from SBo or something with actual source available. That could technically get fixed, and it's perfectly legal to do so.
But steam on wine is unsupported by steam devs and tampering with it is forbidden by EULA, so it isn't clear to me what do you expect these knowledgeable slackers to do about it.
It can work fine one day & break the next day with no apparent reason, even if one build worked fine the next build may not and there's no option to roll back a patch.
Legally, all we can do is shout at it. But if you want to support it, good luck.
Seriously, if this is all you can come up with, why are you writing here? I don't give a sh@t if it is "legal" or not. This guy prompted for help, and if you can't help don't bother to write. If you consider this thread to not be appropriate in this forum why don't you send a message to the moderators? Jezzzuz.
Ontopic: I am really interested to buy this game and will try it on my Slackware rig. I can pm you later on how it went considering this bullshitting in this thread.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.