Infrastructure like this is mutually exclusive with the urban density of a real city.

If you have a highway like this, all you get is a highway, instead of a city.

Double it and pass the problem to the next generation

So what?

Living in a city with actually good public transit, it is used to achieve exactly that. To get any one passenger from any one point within the metropolitan area, to any other. To work for everyone, even though every single person is starting from a different point, and going to a different destination.

It doesn’t matter where you’re going or from where. There is a public transit stop nearby at both ends.

The fuck do you mean “a small segment of the trip”? I share this city with a stupid number of other humans, only a small number of which I go to work with every day, yet a significant portion of of the entire city population travels to work, entertainment and shopping, using the exact same transit network.

Your trip may overlap with a varying number of entirely different individuals along each segment of the route, and at each end it might just be you walking a few dozen meters… But come on! The fact that it adds up is beyond obvious!

Your argument is only valid for mass transit, that isn’t actually mass transit.

And as density goes up (read less roads and carparks), the overlaps INCREASE and the whole thing gets more efficient.

There is a train station in Tokyo, that serves the same number of people every day, as there are citizens in my entire country.

Can you even imagine what a highway interchange that could serve 5 million people within 24 hours would look like? No, because it’s a physical impossibility.

The only reason the number can get so high, is because transit systems consolidate travellers even when they aren’t going to the same places.

Double it and give it to the next generation

Pacman is the actual system package manager.

Yay is an AUR helper, a program that automates all the steps of installing something from the AUR.

The AUR or Arch User Repository is a way for individuals in the community to easily distribute software, or create software installers, without going though the work of getting something into the official repos.

Here’s the first thing I do on a new system, yay -S pamac. This will install pamac, a GUI for browsing, installing and uninstalling packages. (Both normal repos and AUR)

Generally, packages from the AUR get compiled by your system and then installed. This can be really slow, hence there is often a “-bin” version of packages that installs a pre-compiled binary.

You can also find “-git” versions of packages, these install the very latest version directly from the development repo.

Probably in addition to buying the game for 80 or 90 bucks, with a “super deluxe” version above 100.

sigh of relief

Not really. Just install bottles, usage is extremely self-explanatory as the UI is very good.

But if you need more details, the bottles docs are great.

Bottles has a wine manager that allows you to install various wine versions, and switch between them. You can also use the system installed version or even more versions installed by protonup-qt.

Winetricks is included.

No, actually.

Your game files do not need to be inside a prefix, and I generally do not set things up that way.

Same as on windows you can have your c drive, but then install games to a different drive. You can mount any file location as an additional drive in wine. There is usually already a “z” drive mounted, which gives the prefix access to the filesystem outside the prefix.

This means there’s not actually any need to place things inside the prefix, except for save files which need to be in specific locations like appdata or documents.

So to move things over and run them, you’d just copy the game files anywhere you like. To run a game, instead of a location on the c drive, you’d use the corresponding z drive path to the exe.

With bottles, this is super easy. Set up a bottle, and copy any save files into the prefix. Easily done with “browse files” from the config page of a bottle, which will open the fake c drive in a file browser.

With a configured bottle, simply navigate to the game .exe. Right click it, and select run with bottles. Bottles will ask which bottle to run it with, and that’s that. Alternatively, use the “Run executable” button found on the config page of the bottle. For ease of use, add the exe to the bottle as a shortcut.

Shortcuts can then also be added as start menu items, or even added to steam.

No need to fiddle with putting all the game files inside the fake c drive.

Setting things up this way means you have your prefix, with save files and such, separate from the game files. You can easily delete or add games, without touching the save-file-containing prefix, and move games around to wherever you need and still have them work.

You can re-use the same bottle for many games, and keep the save files for those games in one prefix.

If a given game needs a bit more massaging to work, bottles makes it very easy set up and manage additional bottles for any such games.

Well, Endeavour is just arch. If you want, you can achieve the same install that has only the things you need, by removing things instead of just adding.

IMO it starts off closer to the config most people want, so it’s less work to take it the rest of the way.

PBR isn’t shit, and it doesn’t necessarily mean targeting photorealism.

It’s just a benchmark for material rendering that means once all your assets come out the other end of production, they work consistently with each other.

You could shift that benchmark towards cartoony or painterly or whatever you like, and even with assets produced using PBR, it’s easier to “style” your game later because all your different assets are at the same starting point, and will therefore react to rendering changes consistently across the board.

Basically if your entire team is making metal materials by eyeballing it, and you then put it all together in a scene, you won’t be able to get all the different metal objects to look like metal at the same time as you make changes to the lighting in the scene, because the asset team made all of them using slightly different material parameters.

If you make your entire asset production pipeline PBR, all metal assets will behave the same, all glass materials will behave the same, flesh, fabric, fur…

You get the idea.

Short of answering any questions about a product I ask, all of them.

If I want or need something, I will come looking. Anything beyond that is the market trying to solicit demand where none need exist.

So much waste could be eliminated if that just… Stopped.

Not even close, if you actually install barebones arch, then barebones arch is exactly that, barebones. You wont even have a DE.

Endeavour is what you want. It’s just straight up arch, but with all the stuff you’d want to set up anyway done for you.

And if you want an “app-store” style app to browse packages with, and not fiddle with the command line to manage packages, install pamac. It can be expanded with AUR and flatpak support.

I adore Fires of Rubicon. They know how to design games, and how to pull off an aesthetic. That side of the studio has serious world-class talent.

But fromsoft has some big issues on the graphics tech expertise side of things.

I don’t think I’ve seen any subsurface scattering in their games, or proper multi-texture materials. I don’t think they are on a PBR workflow (physically based rendering) though they couldn’t achieve their “style” if they were. And the way they still rely on shell texturing in places they really, really shouldn’t, actually hurts.

My problem isn’t with their style. It’s that they don’t seem to know all the industry standard solutions and techniques that exist and have been developed, and shoot themselves in the foot both in terms of performance and fidelity, by achieving things in ways that an expert could immediately tell is a bad idea.

I know.

But only games running dx12/Vulkan must compile shaders.

The “normalcy” of sutters on linux is because dx7-11 games are running through vulkan, and those games were never coded to account for the way Vulkan works. Hence the shaders are compiled (by VKD3D/DXVK, not the game) during gameplay when first needed.

Like I said, if games must compile shaders during gameplay, they should do so asynchronously in order to not impact frametimes. This only applies to titles actually coded with the intention of being run under dx12/vulkan. Elden Ring in particular straight up violates the dx12 spec.

Compiling the shaders in advance also doesn’t take 30 minutes, and doesn’t require doing so for the entire game. Many games will only compile the shaders for the immediate area that a player is in. (Apex Legends in dx12 mode for example processes only the current map in rotation and lets you play when it’s done)

Games that precompile shaders when running using Vulkan/dx12 have never made me wait longer than a few minutes at most, and only at first launch.

There is no excuse.

Shader compilation stuttering only happens if a game was coded incorrectly to begin with.

Shaders should never ever be compiled during gameplay, and if it has to be done, done so asynchronously.

Either way it should never be dismissed as a problem that is “common in new games”. It’s amateurish and completely avoidable.

That’s nice. But I think most people literally just hook up the big screen with an actual display cable.

With AUR it’s as easy as installing any other package, actually.

You just install the git version from AUR.

No clue. Haven’t used it in years. I was done when I went looking for a fix for the compositor thing and found a years-old open bug report.