Quoting: Eikeespecially remembering the fireplace game for this...

It may be worth revisiting, Little Inferno was in part a warning for what the game industry could become, and has never been more relevant.

One Steam review put it quite well: "A philosophical commentary on modern day consumerism? Or a cute little burning game?... you decide :)"

I am biased though, I have bought Little Inferno on Steam, GOG, iOS, Android, the Mac App Store, and Switch, and gifted it innumerable times. Plus, my profile pic is the game's logo :grin:

View this comment - View article - View full comments

I couldn't be more excited. Every single one of Tomorrow Corporation's games are a joy to play. If you haven't played World of Goo yet, it goes insanely cheap on Steam sales and is worth picking up. Outside of Linux is a "remaster" on Android (and perhaps iOS), but I recommend sticking to the original.

All of Tomorrow Corporation's games are available on Steam, GOG, and on their website via Humble Bundle DRM free (link [External Link]), all with native Linux support on what I believe is a custom engine based on SDL2 from watching some developer videos on YouTube.

Tomorrow Corporation are the best :wub:

View this comment - View article - View full comments

Quoting: Mountain ManWhat game currently use Godot?

The two biggest ones that I am aware of are Brotato [External Link] and Cassette Beasts [External Link].

View this comment - View article - View full comments

Quoting: Purple Library GuyReally easy to get mixed up, they're both "Game + (syllable with an 'o', ending in 'e')".

In name only maybe, but not from a functional perspective. If one hasn't heard of one or both of the tools then I could see you're point.

EDIT: Although they're both maintained by separate authors, and the article here specifically notes Feral GameMode. I'm not sure it would be as easy to mix up that Gamescope is maintained by Feral Interactive...

View this comment - View article - View full comments

Quoting: BlistoFeral gamemode is not active when running games from Steam Deck game mode

I assumed it was, since it comes installed on SteamOS: https://i.postimg.cc/L6Bs4cRy/Screenshot-20231207-172622.png [External Link]

This was taken on my Steam Deck OLED, but it's also installed on my Steam Deck LCD.

I had also remembered reading leading up to the Steam Deck's launch that Feral GameMode was going to be used for some of the power management.

Quoting: Liam DaweYou're probably thinking of Gamescope.

No, GameScope is a compositor, they're very different tools for very different purposes. :smile:

It seems I was wrong either way, but they're not easy tools to get mixed up.

View this comment - View article - View full comments

Should be noted that this not only comes pre-installed on SteamOS but that it powers a lot of the Steam Deck's Game Mode performance behind-the-scenes!

View this comment - View article - View full comments

Got my Steam Deck OLED today, I think the biggest benefits that no one has really mentioned yet is how much lighter the device is (I can comfortably hold it in one hand while I grab a drink) and how much better the trackpads are (much more even to click on and less spongy with much better feedback).

The screen is also noticeably more orange-tinted (only in Game Mode?) which I was able to fix by adjusting the color temperature.

View this comment - View article - View full comments

I have been using KDE Plasma Wayland for a couple of years now, but to me, the lack of global menus for non-Qt apps is a massive showstopper from having Wayland as the default. The KDE team have gave arguments in their favour, stating that it's not a default and that a desktop-agnostic menu bar solution is the real fix, but it's the only thing I miss from X11.

I think the main problems right now with KDE Plasma Wayland are that X11 apps that apply scaling themselves look pixelated when downscaled if you have a scaled display and a display without scaling, some X11 apps that apply scaling themselves have some odd behaviours, and the Steam Overlay does not support Wayland-native games. The first two are exclusive to people with what I have seen the KDE team refer to as "mixed-scale multi-display" setups.

The "Apply scaling themselves" option in KDE allows XWayland applications to be aware of the scale factor and attempt to scale up, meaning they won't be blurry (i.e. Electron apps that don't run natively on Wayland by default, like the Heroic Games Launcher) but applications that cannot apply the scale factor will render at the "native" resolution and thus will be tiny on the scaled display, and scaled down once again to be unusable on unscaled displays (such as Wine without a DPI scaling factor applied). This option works great for fixing the blurry apps on scaled displays but results in them becoming blocky when downscaled on the unscaled displays.

For the 1st point, the Steam Client and games are the main applications suffering from this right now, and Wine is making massive strides in its Wayland support so that will get fixed soon hopefully, but older native games have no fix. Valve will hopefully eventually move the Steam Client over to Wayland and resolve the issue there too. The Steam Client currently requires the "STEAM_FORCE_DESKTOPUI_SCALING" environment variable to be set, so for my 150% scaled 4k display, I use "STEAM_FORCE_DESKTOPUI_SCALING=1.5" (for 200% you would use 2, for 125 you would use 1.25, etc). Without this, the Steam Client will render at 4k without scaling on the main display, but get scaled down and thus be very tiny on unscaled displays. Other applications have options like this, such as Electron games (or other Electron apps with no scale-awareness) allowing the "--force-device-scale-factor=1.5" option (again, adjusting 1.5 to the value you desire). But again once scaled down they look odd. These teething issues will be ironed out as Wayland-native applications become more popular.

For the 2nd point, things like the Steam Client have a couple of small graphical issues, the most notable being that the dropdown for the items along the top ("Library, Community, <username>") fade in as if they are separate windows (notably, the "Store" dropdown is unaffected). This also affects Steam's built-in menu along the top (Steam, View, Games, Etc), and affects any XWayland application with a menu bar, including Wine applications. There are some other occasional oddities, such as some XWayland applications not padding their buttons and other UI elements correctly, resulting in them becoming more cramped.

The 3rd point is minor but something not a lot of people seem to be talking about: The Steam Overlay does not work for Wayland-native games, of which there are a growing number. Any native game using a new build of SDL2 will support the "SDL_VIDEODRIVER=wayland" option. This has lower overhead and allows for games to render at the same of the current display without any of the downscaling issues mentioned above (since they're just like any other native Wayland window), and also means you can have that native rendering without having to resort to the "Apply scaling themselves" option. This option currently works for Terraria, Factorio, and Dwarf Fortress in my experience. Once Wine moves over to Wayland by default though, and once Valve adopt it in Proton, this could become an issue. However I expect Valve to address this issue before they enable Wayland for their Wine fork, and Wine landing full Wayland support is still a few months off. I couldn't find it to link to, but Valve are tracking that the Steam Overlay doesn't work on Wayland, so they're aware of it and will likely coordinate to fix these problems. I also expect the Steam Deck's Plasma Desktop to switch over to Wayland eventually given how much investment Valve have in Wayland both in their own work and the work they have sponsored, and that KDE want to make it the default for Plasma 6.

The real solution to these problems is to port to Wayland, and while I have been very happily using Wayland to solve issues I couldn't on X11 for a couple of years now, and while I support the Plasma team making Wayland the default in Plasma 6, these are some issues I ran into when I switched that I have yet to see anyone talk about in any real detail.

View this comment - View article - View full comments

My main experience with PipeWire is likely extremely insulting to what a lot of people use it for, but I switched over to it on a whim because some older native Linux games required ALSA, and I had read it was better to use PipeWire as a drop-in ALSA replacement, so I just went ahead and switched fully over to PipeWire because it gave me a much more hassle-free way to have ALSA and PulseAudio support. It was just a case of switching the packages over and installing the relevant package on Arch.

Maybe the fact that I was able to just switch over to PipeWire, and install its ALSA extension to get older native games to play audio, without noticing any difference, is a selling point to PipeWire? :smile:

Either way, the way audio plugins work on any OS is a mystery to me. But PipeWire seems to get a lot of praise as a way to facilitate proper multimedia for sandboxed application distribution, allowing an interface for audio and video sharing agnostic of X11/Wayland/XWayland (i.e. for the likes of browsers and web apps and Electron apps to allow video and screen sharing with audio too), and allowing a much more cohesive Linux Desktop audio experience with virtually no disruption to the desktop users, who may not even know they're using PipeWire.

I don't fully understand what PipeWire is or the nitty-gritty benefits but I can't say I've had any regrets about switching over to it, nor have I noticed anything working differently -- Aside from it being seamless to fix that ALSA issue.

View this comment - View article - View full comments

I'd prefer to play Diablo 2 Resurrected, in fact I'd sooner buy that again on Steam than buy Diablo 4 to be honest. Diablo 4 just isn't doing it for me.

View this comment - View article - View full comments