Earlier quoted context omitted.
If you're looking for a stable GUI toolkit, there is Slint
Unless you would like to have a tree view widget.
Migrating away from Rust
611–620 of 799 posts
Re: Migrating away from Rust
#612Earlier quoted context omitted.
Java is incredibly productive - it's fast and has the best tooling out there IMO. Unfortunately it's not a good gaming language. GC pauses aren't really acceptable (which C# also suffers from) and GPU support is limited. Miguel de Icaza probably has more experience than anyone building game engines on GC platforms and is very vocally moving toward reference counted languages [1] [1] https://www.youtube.com/watch?v=tz…
> GC pauses aren't really acceptable Java has made great progress with low-pause (~1 ms) garbage collectors like ZGC and Shenandoah since ~5 years ago.
For the competitive Minecraft player, I suspect starting their VM with XX:+UnlockExperimentalVMOptions is normal.
A casual gamer is however not going to enjoy that.
Re: Migrating away from Rust
#613Earlier quoted context omitted.
Great write-up. I do the array indexing, and get runtime errors by misindexing these more often than I'd like to admit! I also hear you on the winit/wgpu/egui breaking changes. I appreciate that the ecosystem is evolving, but keeping up is a pain. Especially when making them work together across versions.
I've always thought about this. In my mind there are two ways a language can guarantee memory safety: * Simply check all array accesses and pointer de references and panic if we are out of bounds and panic/throw an exception/etc. if we are doing something wrong. * Guarantee at compile-time that we are always accessing valid memory, to prevent even those panics. Rust makes a lot of effort to reach the second goal, but…
Re: Migrating away from Rust
#614I've ported code between engines, and that makes my productivity feel very... leisurely.
Also, it's endearing that he builds things with his brother including that TF2 map that he linked from years ago.
Re: Migrating away from Rust
#615Another failed game project in Rust. This is sad. I've been writing a metaverse client in Rust for almost five years now, which is too long.[1] Someone else set out to do something similar in C#/Unity and had something going in less than two years. This is discouraging. Ecosystem problems: The Rust 3D game dev user base is tiny. Nobody ever wrote an AAA title in Rust. Nobody has really pushed the performance issues.…
I caveat my remarks with although I've have studed the Rust specification, I have not written a line of Rust code. I was quite intrigued with the borrow checker, and set about learning about it. While D cannot be retrofitted with a borrow checker, it can be enhanced with it. A borrow checker has nothing tying it to the Rust syntax, so it should work. So I implemented a borrow checker for D, and it is enabled by addin…
#4 safer union/enum, I do hope D gets tagged-union/pattern-matching sometimes in the future, I know about std.sumtype, but that's nowhere close to what Rust offer
Re: Migrating away from Rust
#616Related: just tried to switch to Rust when starting a new project. The main motivation was the combination of fearless concurrency and exhaustive error handling - things that were very painful in the more mature endeavor. Gave up after 3 days for 3 reasons: 1. Refactoring and IDE tooling in general are still lightyears away from JetBrains tooling and a few astronomical units away from Visual Studio. Extract function…
Refactoring and IDE tooling in general are still lightyears away from JetBrains tooling How long ago was this and did you try JetBrains RustRover? While not quite as mature as some other JetBrains tools, I've found the latest version really quite good.
Re: Migrating away from Rust
#617Another failed game project in Rust. This is sad. I've been writing a metaverse client in Rust for almost five years now, which is too long.[1] Someone else set out to do something similar in C#/Unity and had something going in less than two years. This is discouraging. Ecosystem problems: The Rust 3D game dev user base is tiny. Nobody ever wrote an AAA title in Rust. Nobody has really pushed the performance issues.…
> > The lower levels are buggy and have a lot of churn > > The stack I use is Rend3/Egui/Winit/Wgpu/Vulkan The same is true if you try to make GUI applications in Rust. All the toolkits have lots of quirky bugs and broken features. The barrier to contributing to toolkits is usually also pretty high too: most of them focus on supporting a variety of open source and proprietary platforms. If you want to improve on some…
Python also has incomparably worse performance than Java or C#, both of which can do many object-based optimizations and optimize away their allocation.
Re: Migrating away from Rust
#618Another failed game project in Rust. This is sad. I've been writing a metaverse client in Rust for almost five years now, which is too long.[1] Someone else set out to do something similar in C#/Unity and had something going in less than two years. This is discouraging. Ecosystem problems: The Rust 3D game dev user base is tiny. Nobody ever wrote an AAA title in Rust. Nobody has really pushed the performance issues.…
> > The lower levels are buggy and have a lot of churn > > The stack I use is Rend3/Egui/Winit/Wgpu/Vulkan The same is true if you try to make GUI applications in Rust. All the toolkits have lots of quirky bugs and broken features. The barrier to contributing to toolkits is usually also pretty high too: most of them focus on supporting a variety of open source and proprietary platforms. If you want to improve on some…
Re: Migrating away from Rust
#619More than anything else, this sounds like a good lesson in why commercial game engines have taken over most of game dev. There are so many things you have to do to make a game, but they're mostly quite common and have lots of off-the-shelf solutions. That is, any sufficiently mature indie game project will end up implementing an informally specified, ad hoc, bug-ridden implementation of Unity (... or just use the inf…
Re: Migrating away from Rust
#620Earlier quoted context omitted.
And yet, if making your own game engine makes it intellectually stimulating enough to actually make and ship a game, usually for near free, going 10x slower is still better than going at a speed of zero.
I would bet that if you want to build a game engine and not the game, the game itself is probably not that compelling. Could still break out, like Minecraft, but if someone has an amazing game idea I would think they would want to ship it as fast as possible.
If we are talking 2d, it can be months to hack together a basic engine. 3d can be a bit harder but far from decades.
Thing is, if you designed your engine well and implemented great tooling, it should make it faster to implement the actual content of the game.
So upfront cost to be faster later. At least in theory. Obviously you might end up with subpar tooling that is worse than what a commercial could offers. But if you do something like an RPG with a lot of contend, every bit of extra efficiency in creating that content can help a lot.
Now, obviously from a purely commercial standpoint, not using an established engine makes nearly never sense. Super risky. Hard to hire outside talent. You are only justified when you have very, very specific needs that are hard to implement in a generic engine.
Also for us with an ADHD brain, hard things tend to be easier and easy things very hard, so yes the extra mental stimulation of writing an engine can help.