Patreon Logo Support us on Patreon to keep GamingOnLinux alive. This ensures all of our main content remains free for everyone. Just good, fresh content! Alternatively, you can donate through PayPal Logo PayPal. You can also buy games using our partner links for GOG and Humble Store.
Latest Comments by dreamer_
dosbox-staging, a 'soft' forking of DOSBox to work on advanced features has a first release
6 May 2020 at 2:54 pm UTC Likes: 17

Quoting: CurupiraHow does it compare to DOSbox-ECE?
ECE is not really a fork, but rather a collection of important patches (for users it does not matter, but it means ECE cannot improve on code inherited from SVN - unlike dosbox-staging, which is "proper" open-source project).

Out of patches distributed via ECE:

- We include pixel-perfect mode (this feature was removed from ECE; code author is dosbox-staging maintainer)
- We include a better version of CD-DA work (author is also dosbox-staging maintainer)
- Integrated NukedOPL already
- Scalers 4x and higher are not needed any more since glshader=sharp is integrated now
- We provide a number of features not available in SVN nor ECE (see changelog), most importantly moved on to SDL2

What we're missing from ECE:

- FluidSynth integration (we'll work on this for next stable release)
- MT-32 integration (in plans)
- 3dfx emulation (work is slowly starting)
- "Improved" PC speaker emulation - we won't integrate this, this work is unfinished, borderline broken

Other patches distributed by ECE are really trivial changes, we'll integrate them sooner or later ;)

Overall ECE is an extremely important project, as it kept alive these important out-of-tree patches for years - we're taking them, cleaning up, improving, and properly integrating into dosbox-staging code (one by one).

xow, a Linux driver for the Xbox One Controller wireless dongle has a new release up
28 Jan 2020 at 7:27 am UTC Likes: 1

Quoting: MayeulCWell, C code is just there to tell the kernel how the thing works, the hard part is figuring that out. Even if it was written in C, you'd still have to rewrite most of it to leverage the kernel interfaces anyway. And being license-compatible, you're free to open two editors side-by-side, and start using exactly the same algorithms, instead of reverse-engineering them from the hardware, or driver (would have been a shame to have to reverse-engineer an open source driver...).
Unfortunately, xow depends on a closed-source binary blob, that is covered by this "super helpful" license:
https://github.com/medusalix/xow/blob/master/LICENSE-FIRMWARE [External Link] :(

xow, a Linux driver for the Xbox One Controller wireless dongle has a new release up
24 Jan 2020 at 4:08 pm UTC Likes: 3

Quoting: PompesdeskyAny chance this would help in case of Bluetooth connection with Xbox One controller ? Mine keeps connecting/deconnecting indefinetely, I could never get it to work.
Bluetooth connection to Xbox One S controller (I presume that's the one you are talking about) works (almost) out of the box… except you need to switch a specific bluetooth driver option. Create file /etc/modprobe.d/bluetooth.conf and place following line inside:
options bluetooth disable_ertm=1

Restart computer or reload module after creating the file. If you want to learn what this file is, documentation is in manual pages: man modprobe and man modprobe.d

Quoting: GuestNot even sure how to go about github things..... so how would I install this? Did do a search etc...but not much helping.
Instructions are right there in the README.md file. If you don't know how to follow them, then I would advise not to install it and wait for your distribution to prepare a package instead. This is an experimental driver developed outside of the kernel - if you don't know what you're doing, you could easily break your Linux installation.

xow, a Linux driver for the Xbox One Controller wireless dongle has a new release up
24 Jan 2020 at 2:58 pm UTC Likes: 4

Quoting: MayeulCSomeone (I would if I had time and an xbone controller) should really upstream that into a kernel module (it's GPLv2 as well).
Heh, I just looked up the source code... It's C++, so this particular project will provide userspace driver support at best. :( Unless the project will be rewritten in C, it won't be accepted in kernel.

Boxtron, the Steam Play tool to run games through a native DOSBox on Linux has a new release
19 Jan 2020 at 10:27 am UTC

Quoting: TheRiddickIs there a list of games that have been tested with this somewhere?
Reports (Steam) [External Link], [Reports (GOG)](https://github.com/dreamer/boxtron/wiki/Compatibility-reports-(GOG)

I am regularly testing with some GOG games - an included script `install-gog-game` helps with installation and adding a GOG game to Steam (otherwise there are some Steam client bugs, that need to be worked around).

Boxtron, the Steam Play tool to run games through a native DOSBox on Linux has a new release
17 Jan 2020 at 11:17 pm UTC Likes: 2

Quoting: heidi.wengerBoxtron now with also a flatpak! So it's even more straight forward then! What about Luxtorpeda? Will a flatpak come soon also?
Flathub does not advertise it on the page nor through Gnome Software for some reason - but it's installable via terminal, and even without specifying full reverse domain, simply:
$ flatpak install Boxtron

… which is great :). I had reports from the community it works fine, but couldn't test it myself, as Steam inside Flatpak refuses to start for me.

As for Luxtorpeda… I don't think Flatpak will arrive anytime soon: (1) I am pre-occupied with dosbox-staging and don't have much time to work on Luxtorpeda (2) Flatpak/Flathub is problematic for packaging software written in Rust at the moment (this is a problem I did not expect at all).

Factorio is leaving Early Access in September next year
17 Nov 2019 at 1:28 pm UTC Likes: 1

Good. I am postponing the purchase, because I avoid "early access" games. When I'll have time to spend on this game, I want it to be polished and include all game mechanics. Looking forward to buying/playing it in a year :)

Boxtron, the Steam Play compatibility tool for DOSBox brings more improvements in another update
30 Oct 2019 at 6:01 am UTC Likes: 2

Quoting: michaldybczakHow do I know that a certain game is better to run with Boxtron? Is there some indicators that suggest us to check a specific title on some list?
I hope any DOS game will work a bit better via Boxtron than other methods ;)

Here's a list of all DOS games we found on Steam: "Powered by DOSBox" curator page [External Link].
You can also check our compatibility reports list [External Link].

Boxtron, the Steam Play compatibility tool for DOSBox brings more improvements in another update
21 Oct 2019 at 11:21 pm UTC Likes: 7

Quoting: hardpenguinPerformance is not an issue in majority of DOSBox titles on modern systems.
Unfortunately, that's not the case. During development, I had a chance to compare ~70 DOS games (65 games in my library and several GOG titles), and see how do they work through Boxtron vs Protonized DOSBox or Native DOSBox included with the game. In the slight majority of cases, the performance via Proton suffers… sometimes a lot… and that's not all. Some examples of games and issues they had:

  • X-COM series - performance in Proton 4.11 is so bad, that game is unplayable; in the past game was "playable" but crashed with Steam Overlay on. Bad performance is actually caused by DOSBox config bundled with the game - Boxtron fixes that by ignoring some bad options picked by the game distributor… and turns on MIDI music by default.
  • Descent 3 2 - game refuses to start and hangs at "black screen". With Boxtron it runs perfectly.
  • Tomb Raider I - game does not work via Proton at all - Boxtron starts game in software mode (but it still suffers from DOSBox bugs); Boxtron + dosbox-staging fixes those bugs and is able to play the music in-game as well (via bundled mp3 decoder)
  • X-Wing, Tie-Fighter - both suffer from DOSBox being misconfigured - in Proton the games have maybe 15-20FPS during flight, in Boxtron it is smooth 70FPS during flight
  • Stargunner - the game suffers from DOSBox problems (on Windows and Linux), causing the game to run too fast - by changing cycles you can make the game run at ~30FPS, but it won't be smooth experience. Boxtron + dosbox-staging offer smooth 70FPS.
  • Alone in the Dark series - input issues, Boxtron + dosbox-staging resolve it
  • Larry games - do not go fullscreen properly, they work perfect in Boxtron
  • Hexen: Deathkings of the Dark Citadel - game is missing music because distributor uploaded unpatched version to Steam, Boxtron applies patch on the first run
  • Retro City Rampage DX - this is NOT a DOS game, but it includes DOS prototype version (except you would need to unpack it manually and run outside of Steam). When you'll select Boxtron, it will run DOS prototype for you
  • Fallout - Boxtron downloads an official game patch and brings back DOS version removed by Bethesda
  • Megarace 2 - distributor uploaded broken, untested files as "Linux version" - Boxtron makes the game playable (but it suffers from DOSBox bugs), Boxtron + dosbox-staging makes the game perfectly playable

etc, etc…

Interestingly, GOG games can also be improved - e.g. GOG version of Mortal Kombat 3 does not have Linux version (I suspect because there are severe performance issues in DOSBox - they are visible between fight rounds). With Boxtron and dosbox-staging it is perfect - the game is as responsive as it was on my 486DX2 in 90s :).

Out of my 65 Steam DOS games, only 3 are not playable out of the box (2 games from mid-80s, which work too fast and 1 game, which refuses to start (The Dame Was Loaded) - but this one works in Proton, I hope to address this for future Boxtron version.

NVIDIA have released the big new Linux Beta driver 440.26 today
17 Oct 2019 at 5:34 pm UTC Likes: 5

Quoting: sub
Quoting: linuxcitylinus can't throw up that middle finger anymore this is a pretty damn good release.
Get back to why he thought rising that middle finger was appropriate.
Not sure, that "pretty damn good release" changed anything of that. :)
It was never about GPU desktop drivers. It was about the overall attitude of NVIDIA corporation towards kernel, and specifically about NVIDIA chipsets for Android market. Soon afterwards NVIDIA actually started cooperating more and big chunks of Tegra platform got upstreamed in the kernel. So given this context: Linus' outburst was appropriate and successful.