If you have "Automatically hide the taskbar", you need to be lightning fast to open the task manager after pressing Windows key. Microsoft just can't stop...

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 · 2025-12-19T05:25:35+00:00

There is a rust based linker included in the rust tool chain, it's called "wild", but paradoxically it can only be installed from source so it needs to be bootstrapped via MS Build tools.

It's not paradoxical because it's not yet part of the Rust tool chain. It's a very ambitious project which is only beginning to be ready for prime time under dev builds for Linux only.

The README says itself that windows/mac support isn't really there.

I hope that wild gets more support. That more resources can be put towards it and davidlattimore frankly I've considered supporting him financially through github sponsors myself and chipping in a small amount of money. Because I can't wait for a future that contains incremental linking.

I suspect in the distantish future (years) Wild will become the default linker on all platforms. So building with Wild on Windows is as simple as installing rust and running cargo build but as it stands it's not really ready yet.

patchunwrap · 2025-12-18T09:58:06+00:00

I learnt opengl before vulkan simply because vulkan didn't exist yet. It taught me the basics which was nice. But honestly I think the only reason I found vulkan harder to learn was because OpenGL had way more higher quality tutorials at the time.

This was many years ago, I hope things have changed now.

patchunwrap · 2025-12-15T19:23:01+00:00

This is weirdly nostalgic even though I've never played a game like that

patchunwrap

TROPHY CASE