It seems that you're using an outdated browser. Some things may not work as they should (or don't work at all).
We suggest you upgrade newer and better browser like: Chrome, Firefox, Internet Explorer or Opera

×
avatar
immi101: looks interesting, need to take some closer look at it sometime.
though tbh, i'm more interested in the backend than the GUI at the moment, as I'm still looking for a better way
to automate setting up a game in wine (and i'm not a fan of PlayOnLinux).

so basically it is just a laucher for steam games that I already have installed locally ?
It's not a launcher for steam games, more a launcher for all the games on a PC (even apps, if your that way inclined)
avatar
immi101: Can I use the offered wine install scripts to install a game from CD or GOG without having to register online?
I think so
avatar
linuxvangog: I want to make sure that extracting the installer without the need to run it will remain to be possible for all unusual/emergency purposes (although running it is ALWAYS the preferred and supported way of installing the game).
As long as I can extract the game data from the installers with a third-party open-source tool (could be tar, unzip or whatever), I will support whatever mean of distribution you favour ;-)
Recently replaced my 660ti with an RX 480, and I'm running into a lot of issues with games. Most of them throw out an error like the following:

desum@localhost Brutal_Legend]$ sh start.sh
Running Brutal Legend
libGL error: unable to load driver: radeonsi_dri.so
libGL error: driver pointer missing
libGL error: failed to load driver: radeonsi
libGL error: unable to load driver: radeonsi_dri.so
libGL error: driver pointer missing
libGL error: failed to load driver: radeonsi
libGL error: unable to load driver: swrast_dri.so
libGL error: failed to load driver: swrast
X Error of failed request: BadValue (integer parameter out of range for operation)
Major opcode of failed request: 154 (GLX)
Minor opcode of failed request: 3 (X_GLXCreateContext)
Value in failed request: 0x0
Serial number of failed request: 98
Current serial number in output stream: 99


This is my first AMD card, so I'm a little lost here.
avatar
king_mosiah: (…)
If you are using Debian or a derivative, you are probably missing the package 'libgl1-mesa-dri' or 'libgl1-mesa-dri:i386'.
avatar
king_mosiah: Recently replaced my 660ti with an RX 480, and I'm running into a lot of issues with games. Most of them throw out an error like the following:
I just replaced GTX 680 with RX 480 as well. What does this say:

glxinfo | grep string

On Debian and the like, make sure you have these packages installed:

libgl1-mesa-glx libgl1-mesa-dri libegl1-mesa mesa-va-drivers mesa-vdpau-drivers mesa-vulkan-drivers xserver-xorg-video-amdgpu libdrm-amdgpu1

And make sure you completely removed your nvidia driver. I.e. there should be no "nomodeset" kernel setting in grub and etc.
Post edited December 06, 2016 by shmerl
avatar
king_mosiah: (…)
avatar
vv221: If you are using Debian or a derivative, you are probably missing the package 'libgl1-mesa-dri' or 'libgl1-mesa-dri:i386'.
Fedora 25 actually. I assume the name is different since nothing comes up when I search dnf.
avatar
vv221: If you are using Debian or a derivative, you are probably missing the package 'libgl1-mesa-dri' or 'libgl1-mesa-dri:i386'.
avatar
king_mosiah: Fedora 25 actually. I assume the name is different since nothing comes up when I search dnf.
I found this: http://koji.fedoraproject.org/koji/buildinfo?buildID=821151
See various mesa-* packages there. But make sure you have both 64-bit and 32-bit versions installed.
Post edited December 06, 2016 by shmerl
avatar
king_mosiah: (…)
avatar
vv221: If you are using Debian or a derivative, you are probably missing the package 'libgl1-mesa-dri' or 'libgl1-mesa-dri:i386'.
You're right, I was missing mesa-dri-drivers.i686. I'm missing Nvidia's blob already...
avatar
king_mosiah: I'm missing Nvidia's blob already...
You won't miss it, once you'll discover you can use lm-sensors and GALLIUM_HUD with your new card and there is no annoying tearing anymore.
Post edited December 06, 2016 by shmerl
avatar
king_mosiah: I'm missing Nvidia's blob already...
avatar
shmerl: You won't miss it, once you'll discover you can use lm-sensors and GALLIUM_HUD with your new card and there is no annoying tearing anymore.
Speaking of tearing, have you been able to get Gnome/Wayland to work with your RX 480? Mine works with Plasma's Wayland session, but not the one for Gnome Shell.
avatar
shmerl: You won't miss it, once you'll discover you can use lm-sensors and GALLIUM_HUD with your new card and there is no annoying tearing anymore.
avatar
king_mosiah: Speaking of tearing, have you been able to get Gnome/Wayland to work with your RX 480? Mine works with Plasma's Wayland session, but not the one for Gnome Shell.
Since I just got RX 480, I didn't get to try Wayland yet. I didn't use Gnome in a while and I don't have it currently installed. And KDE Plasma isn't ready for gaming on Wayland, since mouse pointer containment and relative pointer support is coming only in Plasma 5.9.x.

See https://blog.martin-graesslin.com/blog/2016/10/wayland-improvements-since-plasma-5-8-release/

Without it, mouse behavior in games goes bonkers. Still, even on X situation with tearing is way better than on Nvidia blob. It's simply gone for me when using Mesa / radeonsi.
Post edited December 06, 2016 by shmerl
avatar
ssokolow: *nod* I ran across Lutris a few years ago and that's what prompted me to start my own experimental project instead of trying to extend Lutris.
avatar
immi101: looks interesting, need to take some closer look at it sometime.
though tbh, i'm more interested in the backend than the GUI at the moment, as I'm still looking for a better way
to automate setting up a game in wine (and i'm not a fan of PlayOnLinux).
That's sort of a good thing since, at the moment, I haven't pushed the new Qt GUI up yet, so it's still using the much more primitive PyGTK test UI.

Anyway, regarding the backend, I haven't finished writing unit tests for, debugging, and refactoring it by a long shot but it's basically a bunch of scraper plugins. You point the filesystem-based ones at a folder and they walk through it using heuristics to identify launcher titles, icons, and launcher commands.

(It's mainly the name inference that has unit tests right now because the other parts need a framework to make freezing filesystems into mocking fixtures convenient and I haven't gotten around to that yet.)

Automating installation of games within Wine is still a roadmap entry at best, since my current main focus is making it as dogfoodable as possible as a launcher and I already use PlayOnLinux without install scripts to manage multiple Wine versions in parallel.
Post edited December 07, 2016 by ssokolow
avatar
linuxvangog: How would you feel about GOG Linux support being 64 bit only? At the moment this decision would affect only the game installer (it would be a binary from now on, and it could be clicked safely without the risk of being opened in text editor).
Seems most games still are shipped 32-bit. In which case I don't much see the point. I've come across a number of 32-bit users in the forums. Can't you just set MojoSetup to use #!bin/bash to work around the 32-bit DASH bug for large installers?
Post edited December 07, 2016 by Gydion
avatar
linuxvangog: Hey guys,

How would you feel about GOG Linux support being 64 bit only? At the moment this decision would affect only the game installer (it would be a binary from now on, and it could be clicked safely without the risk of being opened in text editor).

Games would still be "whatever-we-get-from-developer". We always try to ask for a 64 bit binary, but it's not possible in all cases.

Do you see any potential problems with that? Give me some input :)
Generally, there's no reason to run 32-bit Linux as opposed to limits of 32-bit Windows. I'm sure GOG staff has hard time on making the old games behave. That's one of the reasons why the manual extracting (without running the binary) of games is important; to make them more future-proof. It would also allow running games on 32-bit os, if someone wants to try it. But as you wrote the manual extracting will still be possible, thanks for keeping that!

Mojosetup has been great so far, no issues.
avatar
Dolumis: Generally, there's no reason to run 32-bit Linux as opposed to limits of 32-bit Windows.
Not quite true. Some older netbooks (circa 2009) have 32-bit Intel Atom processors. They are incapable of running 64-bit OS. Due to their specific role they are still not obsolete (or were obsoleted from the get go, depending on POV ^‿^ ).