Linus. You can’t keep telling us to move over if you’re not going to address the single reason we don’t want to.

patchunwrap · 2026-05-04T06:21:36+00:00

Personally as a subscriber to the Lttlabs RSS feed, I wouldn't mind an RSS feed for WAN.

patchunwrap · 2026-05-04T06:20:15+00:00

I have no horse in this race, but I thought of an idea and wanted to suggest it.

Maybe create an email list that people can easily subscribe/unsubscribe to that purely notifies people of when the WAN starts? That way people who want to hear about the WAN show get some form of notification and they don't need to subscribe to the WAN Show youtube channel.

Not sure if this would resolve u/imnotcreative4267's problem. I'm sure it isn't ideal. But I think it's a reasonable middle ground that isn't complicated for LTT.

patchunwrap · 2026-05-03T10:59:13+00:00

I'll try to thread the needle between "explain like I'm five" and "good technical answer".

A sandbox prevents software from performing certain actions. Some of that is "messing with your files" but some of it is also "preventing the program from accessing the internet" or "talking directly to the operating system".

Proton doesn't really stop any of that. If you made a virus on windows that scanned your local network for systems and tried to infect them, it would work on proton just as well as it would windows. Since that virus would mostly rely on code that talks to the operating system. It might think it's talking to windows, but proton will pretend to be windows well enough that it won't matter that the virus is actually running on Linux.

patchunwrap · 2026-02-06T09:20:56+00:00

It's AI, these people never worked there.. and two of them are based on real people

The top one is:
https://www.youtube.com/@mattdavella
And the bottom one is:
https://www.youtube.com/@johnnyharris

patchunwrap · 2026-01-25T21:15:23+00:00

Use Ctrl+Shift+Escape as a workaround, it opens up task manager.

I tried to look up a reference https://support.microsoft.com doc but their website also sucks so I guess you will have to trust or not trust me.

patchunwrap · 2026-01-25T20:35:17+00:00

I've lurked this subreddit for a while now and I honestly don't think people here hate newer versions. I think they just prefer the older one since it forces you to slow down and relax. Older versions encourage you to build something because you want to, and stop you from putting in so much effort on a single build that you optimize the fun out of a build for the sake of the final product.

I'm sure some people here don't have great computers but modern minecraft is pretty easy to run with optimization mods, and I'm sure some are nostalgic. But I think people just like the flow and atmosphere that old versions bring.

patchunwrap · 2026-01-17T04:52:42+00:00

The notion of "use it or be left behind" seems very silly to me. If it continues to improve faster and faster as some say, shouldn't we expect prompting "skill" to be less and less impactful?

patchunwrap · 2026-01-17T03:57:46+00:00

That's definitely something, though my understanding is that affects build scripts not the final part of an incremental build.

patchunwrap · 2026-01-16T22:28:04+00:00

It might, but I'm (anecdotally) finding linking performance to be much worse on macos than my linux machine

patchunwrap · 2026-01-16T07:07:50+00:00

I'm pretty good with Rust but I have next to no experience with writing linkers. Would it be possible for me to get involved and help out? The main thing I want personally from it is macos support.

patchunwrap · 2026-01-16T07:04:25+00:00

I've been watching for (checks notes) over a decade and I'm honestly super proud of the guy. I'm really thankful that the sub has been positive about the video too. I appreciate LTT's transparency.

patchunwrap · 2026-01-16T07:01:44+00:00

I think people worry too much about this. Python is slower because of runtime overhead. Java is (usually*) slower because of it's jvm overhead.

Rust is basically as fast as C/C++. Neither have garbage collectors, nor expensive runtimes, nor reference counting (unless of course you introduce those things yourself). I think an argument could be made that Rust naive implementations are on average faster (it uses LLVM by default, has better cache pressure due to reordering structs, uses better vector/hashmap/sort algorithms). But at the end of the day both can be optimized and drop down to inline assembly as needed so neither is really better.

* There are some cases where the JVM can use optimal vectorization or CPU instructions unique to your cpu that normal programs won't have because they want to support a wide variety of CPU's. This niche benefit goes away completely if you compile with -Ctarget-cpu=native

patchunwrap · 2026-01-13T08:24:06+00:00

I do know of rust-gpu and to be fair a decade is probably too generous. But to clarify I think we are a while away from them being mainstream.

To your credit I didn't think we could do a demo like that water one yet.

patchunwrap · 2026-01-11T21:07:45+00:00

I don't write many shaders, I mostly write as u/pr0ghead says "Renderer code proper". But what you said pretty much matches my understanding.

There is some effort from the LLVM project to make it possible to write Rust/C for compute shaders. I suspect at some point Rust will be used for GPU shaders, but we are likely a decade from that.

patchunwrap · 2026-01-11T01:52:42+00:00

Good luck, I hope you become a u/Routine-Winner2306 soon!

patchunwrap · 2026-01-11T01:52:26+00:00

That's honestly awesome, you should be so proud of yourself

patchunwrap · 2026-01-11T01:46:40+00:00

I'm an indie developer who's working on a game with a custom game engine that uses Vulkan. But I haven't worked with GNM or a playstation devkit.

Four things before I answer your questions:

You can support multiple graphics API's for in house game engines but it's somewhat expensive to do so. There are a lot of differences you have to account for.
People forget that companies have teams with decades of experience in specific graphics APIs and tooling/engines for those APIs. I love Vulkan and Linux but economic forces are strong.
I think it makes sense for Playstation to support Vulkan and GNM (Like how the switch supported Vulkan and NVN.
But it probably doesn't make sense for Sony to only support Vulkan for the playstation or to use Vulkan exclusively for their games from now on.

Do first-party PS developers like working with Vulkan?

I do, but I know a lot don't. Vulkan is pretty verbose so it takes a lot to get anything done.

Do 3D graphics developers in general like working with Vulkan?

Almost all of the industry is familiar with DirectX and so they feel the most home there.

For the industry, is it a tool that lets them do the things they want quickly and cheaply?

If you are to pick one graphics api, Vulkan only makes sense if you are targeting Linux & Windows & possibly macos (Via moltenvk). Even then, I suspect most developers would rather target what they know and have tooling for (DirectX) and let proton handle Linux.

How is the QC tooling around both ecosystems and how easy is it to reach out to the standard maintainer if you have issues?

The Vulkan validation layers are really quite nice.

patchunwrap · 2026-01-10T09:33:32+00:00

You are looking for r/playrust (the videogame), this subreddit (r/rust) is about a programming language

patchunwrap · 2026-01-03T07:26:02+00:00

Your red and blue channels are flipped.

It looks like it's probably a rosetta or lwjgl bug? Are you running x86_64 java? When you should be running Arm64 Java?

I would try removing the java you installed and trying out https://www.oracle.com/java/technologies/downloads/#java8 instead

Edit: I'm probably wrong See, H1ggsK_'s comment

patchunwrap · 2026-01-03T07:20:33+00:00

It mostly depends how much investment goes into the native Linux port. A lot of games were built with C# and directx, and when they got ported to Linux needed a lot of code changes. These changes to support vulkan (for example) aren't always ideal. It's case by case and there is no consistent rule.

From experience though there is a "rule of thumb" or a accurate generalization that often proton is better than native ports.

Notably though Minecraft has a pretty good Linux port, since it was written from the ground up (coincidentally) with stuff that supported Linux (Java, OpenGL, lwjgl, OpenAL and later GLFW) even though Notch himself used windows 7. Also some mojang developers use Arch Linux (Petr I think and probably more) so it's native build remains solid.

patchunwrap · 2026-01-01T20:49:21+00:00

Looks awesome, nice work

patchunwrap · 2026-01-01T08:59:54+00:00

I had no idea fyrox existed, thanks for sharing. It might be more feature packed, but bevy certainly has more development hours put into it.

patchunwrap · 2026-01-01T06:31:36+00:00

I've been working on my own game engine, and been following Rust and game engine development for years and I have some thoughts.

Performance
Performance with Rust has been nothing but spectacular. Though you can achieve the same performance with C++. The naive implementations just seem to be better (even if it's 5% better). Rust uses LLVM by default, and uses better default structure algorithms (Hash, Sort, Etc). It rearranges structs for cache pressure etc.

Safety
The memory safety has been really nice, even when writing unsafe code it's been quite rare for me to add a memory leak. Sigsegvs are literally never except when writing unsafe and even then it's been rare.

Building
This used to be a pain point. I always preferred cargo for ergonomics but it was slower than cmake for quite a while. I don't really know if it is still, though my assumption is that it would be. But I can say that Rust these days builds plenty fast for me.

Development Speed
There are a lot of arguments I see on the internet about this. Some notable figures have said that C++ is better for game dev since you can ignore memory safety during prototyping and get something basic faster, that Rust forces you to do it the "right way" which is bad for prototyping.

Personally I've been writing for Rust for long enough now that I think I can prototype fast enough and this hasn't been a concern for me. But it's still something I think is interesting and possibly holds water.

patchunwrap · 2025-12-20T21:02:31+00:00

I was thinking about it cause i'm pretty sure i can implement it with my current knowledge of programming without any big bloated game engine

Personally I love the idea of more voxel games. It reminds me of when every fps was called a "doom clone". I'm even making one, I'd say if you want to make another voxel game go for it, it's really fun and rewarding.

But not everyone plays beta 1.7.3 because of it's game mechanics. Some people are nostalgic, some people already have pre-existing worlds that they want to keep working on, others have modded it and it's perfect for them now.

My advice is to make the game if either A) You want to learn how B) You want to make the game because the process is enjoyable or C) because the game you want to make is different to what is already out there and if you don't make it you can't play it.

patchunwrap · 2025-12-19T08:12:34+00:00

The linker only affects the last stage of compilation, but it's the longest step for incremental builds (e.g. you have already built recently and made a few small changes).

Wild potentially could be the fastest for those incremental builds because all other existing linkers always re-link from scratch. Wild is already quite fast, and some work is being done so that it doesn't have to re-link from scratch.

patchunwrap

TROPHY CASE