No prob!

Nope. Wrong.

Its not a pre bundled flatpak, that runs on top of the core, atomic OS.

Its part of the core, atomic OS, an integral part of it, installed as an rpm package at basically a lower level.

According to the github page for Bazaar (which I may not be fully understanding correctly), it seems like Bazaar is designed for GNOME primarily, and then there is essentially a seperate thing, basically a kind of plugin or sort of like a patch, that is layered over top of the main Bazaar, which enables it to work with/in KDE.

Bazaar proper:

https://github.com/kolunmi/bazaar

Bazaar is fast and highly multi-threaded, guaranteeing a smooth experience in the user interface. You can queue as many downloads as you wish and run them while perusing Flathub’s latest releases. This is due to the UI being completely decoupled from all backend operations.

It runs as a service, meaning state will be maintained even if you close all windows, and implements the gnome-shell search provider dbus interface. A krunner plugin is available for use on the KDE Plasma desktop.

The krunner plugin:

https://github.com/ublue-os/krunner-bazaar

A KRunner plugin for searching and installing Flatpak applications through the Bazaar store.

Sorry, I’m not a fequent KDE user, I may be misunderstanding something here.

No, it actually does not run the flatpak version.

Steam is essentially treated as part of the core Bazzite OS.

Bazzite runs more or less the latest Fedora version of Steam, and then has a ton of custom scripts, as well as accompanying core-Fedora library utilities to accomodate integrating Steam more fully into Fedora, so that things like Gaming Mode/Desktop Mode, various other under-the-hood things basically work as they do in SteamOS.

Doing it the way they do it, this makes it so you can use the various u-just terminal commands and pre-packaged flatpak apps to tweak things that basically affect or touch or may touch Steam.

So uh, right now, on my Bazzite Steam Deck, if I do:

rpm -qa | grep "steam"

(which is basically Fedora-speak for 'show me all installed libraries that have “steam” in them)

I get:

steam-1.0.0.85-3.fc43.i686

So that would be the current, Fedora 43 version of Steam, from the Terra repo, I think… its not the 44/Rawhide version.

Where the Terra repo is the community repo, sort of roughly analagous to the AUR, compared to mainline Arch libraries.

https://fedora.pkgs.org/43/terra/steam-0:1.0.0.85-3.fc43.i686.rpm.html

That command also lists out a number of steam-related utility libraries, which comprise parts of the core, ‘no touchy’, atomic part of Bazzite.

Limo is more or less MO2, but linux native, doesn’t require itself to be run through Proton… it just works in a slightly different way.

Why does it work in a slightly different way?

Basically, because Linux is not Windows.

The main problems you will run into are mods that are themselves designed only to run/work in a Windows environment…

An example would be something that goes through the core game files itself, and edits the actual huge archive/library files of the game, by means of basically a Windows batch script, or something like that.

You can’t actually fix that with a linux mod manager, but you can find workarounds to essentially convert the results of something like that into a linux version of the mod, and then use that in the linux mod manager.

You can run a batch file or exe like that through something like Bottles… if it works for unpacking a compressed Repack kind of uh, ‘acquired’ game, it’ll likely work for a mass archive edit type of thing.

Other examples would maybe be certain kinds of ‘script extension’ type mods that require you have whatever version of visual studio installed, for them to hook into and work.

Often, you can use ProtonTricks to add the equivalent of those dependencies to your game’s Proton config, and it’ll work fine, but sometimes either Proton hasn’t quite yet caught up to fully translating some dependency, or the mod authors will just forget to list a dependency.

Yeah the whole problem with Nexus, a bunch of its kind of mega contributors, prominent community members, from a linux perspective…

… is that basically none of them know anything about how Linux actually works; they’re so used to the Windows paradigm that they don’t even understand the kinds of things they’re taking for granted.

Like uh, try finding mod tools, modder resources, for very popularly modded games on Nexus, that actually fully work on Linux.

BodySlide, the sort of utility tool for tweaking character bodies and clothes in I think just all Bethesda games in the last 20 years at this point… is maybe a good example of that… gotta run that through Proton and basically just hope it works, hope you can figure out the equivalent dependencies it will need via custom Proton configuration through ProtonTricks or something like that.

Ok, so you are building your own engine, that makes a lot more sense, and you do realize that… the editor itself is actually quite substantial a task, to get everything coherent and also functional.

Honestly, best of luck to you!

No clue if you’ve seen these before, but maybe they could be helpful?

https://david-delassus.medium.com/trying-out-sdl3-by-writing-a-c-game-engine-c9bb13156b74

https://github.com/linkdd/sdl-game-engine

https://blog.conan.io/2023/07/20/introduction-to-game-dev-with-sdl2.html

Limo.

https://github.com/limo-app/limo

Its linux native, available as a flatpak.

Vortex is a shitshow, the NexusMods people have no idea how to write anything for linux.

I was able to use Limo to fully do a FONV, Viva New Vegas setup, uh, 2 years ago now.

As well as mod Cyberpunk 77 with it.

You have to actually RTFM though, but its a versatile and very useful tool once you figure it out.

I’m sorry, but I’ve never heard anyone say Godot is fairly unkind to older hardware before.

Sure, yeah, if somebody is futzing around in 3D, in the Forward+ renderer, and has no idea what they are doing, yeah.

But… broadly?

How… old of hardware are you talking about?

Like, 15+ years old?

Also, SDL isn’t … a game engine.

Its… a rendering/input/output layer/library.

Sure, if you want to write your own game engine, you could use SDL… but… that’s a bit much to ask of a novice indie dev, who wants to complete a 3D game that’s maybe roughly as or more graphically advanced than say, Fallout New Vegas, in under what, 3, 4, 5 years?

As far as I can tell (I am use Bazzite), the main problem with Bazaar was basically that it was kind of undercooked, had some bugs, both surface level and under the hood, when they first pushed it as the bundled app store for Bazzite.

But its been some months now, and they seem to have been ironed out?

I guess possibly a ‘downside’ could be that it only handles flatpaks, as opposed to also allowing other kinds of direct package installs, but the whole idea of Bazzite is ‘no touchy core os, use flatpak’.

Or, ok, Bazaar is either GNOME only, or GNOME first, whereas Flathub pretty well supports KDE and GNOME, so, if you prefer KDE, I can see the reasoning there for preferring Flathub.

Steam Deck runs everything up to a PS3 and Xbox 360, and the Switch.

Almost everything a generation prior to ran runs with 0 problems, PS3/360/Switch can be hit or miss somewhat, depending on the game.

A Steam Deck will also run MGS5 and Titanfall 2.

Its entirely possible to make new games that look that good and will run on comparable hardware, just gotta, you know, have an optimized engine, render pipeline, game.

Hell you can get a solid, never dips below 45 FPS on CyberPunk 77 with a Deck, with med/high settings, then sync the VRR to a 45/90 split.

Highly religious people are ordained by God, donchaknow?

They can do no wrong, because its not wrong if it’s furthering God’s plan.

A sane world would see psychology broadly recognize this as a persistent delusion and classify them as some kind of insane, grandiose, religiously-informed malignant narcissism.

No, we are not.

We can go back to the basics, focus on not graphical realism, and/or, invent new rendering paradigms that lead to new art styles, and compute with less overhead, have modest system requirements.

It isn’t impossible.

Look at MGS5, Titanfall 2.

Shit looks pretty good, its a decade old, from before all this modern graphical absurdity.

There has literally never been a better time to become an indie dev, make a small team.

No publisher, no marketing.

Just don’t overpromise, and don’t take people’s money untill you actually have a minimum viable product.

Godot is completely open source, and completely free, and quite capable as an engine.

No one is coming to save us, but ourselves, if we choose to.

Having a stable set of individuals with a deep understanding of ‘how things work’ is so totally anathema to the modern paradigm of ‘every coder is is a contractor, basically’.

Everybody wants to do software development, but doesn’t want to foster software developers.

So, they try and build machine god to replace us, and as most of us predicted… didn’t work out so well, but goddamnit, they’ll burn a trillion dollars before they let their ego take a hit.

… oh well, I guess.

I mean, on the one hand, its SQLite.

On the other hand…

… arguably the entire point of a database language is to efficiently handle complex workloads.

And then when you remember that… this was a project, in development, that cost time, money, energy, made RAM prices go up by maybe ¢22 per GB all on its own…

This is an insane negative return on investment.

Like imagine if you paid the same amount of money to … people, a contracted firm, and they handed you this.

You’d potentially be firing them or suing them for breach of contract, blacklisting them as far and wide as you could.

I mean, the entirety of DLSS, and Realtime Raytracing, has been an ongoing insult to the more technical aspects of game engine design snd optimization.

Now everyone else can experience the level of disgust that people who’ve been figuring out all kinds of tricks and hacks that become either a ‘secret sauce’ or an industry standard rendering method, that those people have been experiencing since Nvidia started this whole mess.

Howabout we just figure out a more effective and also faster way to do AA, eh?

You know, not go down the TAA branch of the tech tree, that lead us to where we are now?

Oh or hey, howabout this:

Actually improve NPC AI in video games, decision making / behavior models, maybe a little submodule on a GPU that’s optimized to run some kind of standardized genetic learning algo data format, or maybe figure out a way to do Goal Oriented Action Planning in the shader buffer, somehow, you know the kind of AI that’s so awesome in FEAR?

In fairness to LLMs, (which I run locally) I’ve been able to use them for like, bits of code that are roughly 200 lines or less.

Or like, feed it a code base and say hey, make sure all the comments are formatted the same way.

But uh, for… trying to engineer an entire system?

Nope nope nope, they get very confused, very fast, as overall conplexity increases.

Wow.

2000x worse, huh?

I mean… I’m impressed that it runs, passes unti tests, and ‘works’, but is also that much worse.

That’s a kind of achievement.

Not a useful kind, but… impressively bad.

I’m going to go with ‘Aha! I did an intentional misdirect!’

… yep. Mhm.

(cough)

derp

Maybe don’t make a habit out of this, Mr T-Rex.

Oh hey, no prob!

Yeah, the… fragmented-by-design nature of lemmy can be a bit confusing… I don’t even know how many different mobile client apps there are at this point, and many instances have differing layouts for the web browser version.