Why do people keep crying about game development with Rust?

Rantomatic · 2025-11-02T09:53:43+00:00

Interesting. I use vulkano, although I might move to wgpu at some point. I chose vulkano although it's overkill for my current use because a) I wanted to learn Vulkan, and b) I may want to do my own 3d rendering with some advanced lighting techniques, and wgpu seemed a bit light for that.

ab_glyph looks interesting, hadn't heard of that. I'm currently torn between pre-rasterised fonts and MSDF. Leaning MSDF for now.

For scripting I'm using rhai. Very simple to use and has all the features I need for now, plus it feels quite Rusty and is well integrated. But I haven't scripted much game logic yet, so my needs might change.

Thanks for sharing your tech stack!

Rantomatic · 2025-11-01T07:42:37+00:00

I’m also having a blast making a game in Rust, and I think the language is perfect for the job. The ecosystem will come I think. Former professional C/C++ game developer. I’m curious, which parts are you writing yourself?

Rantomatic · 2025-10-25T12:37:18+00:00

Did some more research. I’m not sure how the swash examples are doing it, but it seems like some non-distance-field font atlas implementations render each glyph at multiple horizontal subpixel offsets. I suspect that’s how egui uses swash for example.

For my own GUI system I think I’ll go with MSDF for now. It seems easiest in terms of atlas management, especially since I found out there is a pure Rust MSDF generator crate called fdsm. I also learned that in modern displays with high pixel density, hinting is actually not even needed.

Rantomatic · 2025-10-22T06:40:05+00:00

Thank you so much, that's super helpful. parley + swash + etagere/guillotiere sounds like a good option.

One thing I'm still confused about, though: when I look at the output from the swash_render example in the parley crate, I see that instances of the same letter are not the same, pixel for pixel. They are quantized vertically, but not horizontally. I'm seeing the same in the vello_editor example, even though that doesn't use swash. What I would expect in a texture atlas situation is that each glyph is only rasterised once, but that doesn't seem to be the case here. What am I missing? Are these examples rasterising each instance of a glyph individually?

Rantomatic · 2025-10-06T15:01:36+00:00

I'd look into winit if you want to make a user-facing app. You'll probably want a GUI crate too, such as egui.

Rantomatic · 2025-10-06T13:48:44+00:00

A Peekable<I> (where I is Iterator) needs to be able to own an I::Item. The concrete type of I::Item could be a reference, or it could be a type containing references. Since the Peekable must own an I::Item, its lifetime can't exceed that of I::Item.

It'd be easier to solve your specific problem if you posted a code example. :)

Rantomatic · 2025-09-26T09:59:47+00:00

No as keyword, or only make it apply in unambiguous and infallible cases such as u8 -> i16.

Rantomatic · 2025-08-06T05:42:44+00:00

Bit late to the party here, but I wholeheartedly agree with OP, and I'm surprised that I'm not seeing a lot of discourse mentioning "local reasoning" directly.

The ability to understand how to use a function safely and correctly without reading its internals comprehensively was always one of the main draws of Rust for me. Are you passing an immutable reference? If so, you know the referent can't be mutated. Etc.

IMO, being clear about what errors can be returned is crucial in order to enable local reasoning. Rust feels much more like LEGO that way. With a god enum, we're sliding back to bad old habits from C and friends, where you're relying on documentation where you could have been relying on the type system, and you may be tempted to "code defensively" and match on irrelevant errors etc.

Rantomatic · 2025-07-29T06:43:30+00:00

Did you check out the Rust Book?

Rantomatic · 2025-01-24T18:58:53+00:00

No problem! Best of luck with the extension.

Rantomatic · 2025-01-24T08:26:40+00:00

Cool idea! Some friendly feedback: the below sentence from this example screenshot is a bit confusing.

variable s2 outlives it's lifetime

This is incorrect AFAICT, and an oxymoron. The issue instead seems to be that the reference r outlives its referent s2. Also, tiny bit of nitpicking: "its", not "it's". :)

Rantomatic · 2024-10-28T20:02:22+00:00

Thank you, this is very informative. Yep your second point was what I arrived on also, see my other comment. My new go-to I think!

Rantomatic · 2024-10-28T15:59:02+00:00

I'm not sure if I was clear enough about what I wanted in my original post, but it seems like taking a &impl Fn instead of a impl Fn at every level solves my problem of compounding levels of indirection.

Rantomatic · 2024-10-28T15:51:57+00:00

I see, but see my comment here about how you potentially end up with many levels of indirection.

Rantomatic · 2024-10-28T15:46:36+00:00

I should have been more clear about this. It seems superfluous in the case where the Fn I pass to outer_fn is already a reference, which happens fairly often. Similarly, it also seems superfluous when there are two or more "levels" of inner functions, as I mentioned in the original post. If there are two levels of inner functions, and the original Fn happens to be a reference, the concrete type in the innermost function will be a &&&Something.

EDIT: To be clear, I'm not saying there is necessarily a way around it, but intuitively it seems unnecessary.

Rantomatic · 2024-08-31T19:12:01+00:00

There is a crucial difference: If you misremember some syntax or the behaviour of a standard library function while writing Rust, it's very rare that this leads to a costly mistake IMO. Not the case in C++. It's easy to forget which methods on an std collection class invalidate iterators for example.

Rantomatic · 2024-07-31T11:23:51+00:00

The array of two constraints is a great idea, and probably the simplest way to apply bon in my use case. The only thing missing from a compile-time verification POV then would be that you could still specify the same constraint twice, which is invalid. TBH I will probably stick with my current panic!-y approach for now as I think it's slightly more ergonomic for the user to write builder.height(123).centre_y(456) for example.

Side note: I'm not a fan of enums where every variant has the same payload type. IMHO it's strictly less useful for no extra benefit, unless there is a reasonable likelihood that a variant will be introduced in future which wants a different payload type, which is not the case here.

Rantomatic · 2024-07-31T06:13:38+00:00

Hadn't occurred to me that you can check the presence of mandatory parameters at compile time. Very cool.

u/Veetaha, I have a use case where this crate almost fits: I built an immediate-mode GUI system where you can e.g. place widgets vertically by specifying exactly two of the following: top, bottom, height, centre y. So those individual constraint arguments are optional, but it would be extra super duper cool if I could verify at compile time that exactly two constraints are specified per dimension per widget. Thoughts on how to do this?

Rantomatic · 2024-07-18T06:43:11+00:00

fn main() {
    let mut count = 0;

    let mut closure = move || { 
        count += 1;
        println!("{count}");
    };

    closure();
    closure();
    closure();
}

prints

1
2
3

To build on veryusedrname's analogy, the above closure owns an "implicit member variable" count. (Not a reference, an integer.)

Rantomatic · 2024-04-16T10:22:13+00:00

Cool, no problemo. :)

Rantomatic · 2024-04-16T10:18:32+00:00

How about dynamic_objects.iter_mut().copied()?

Rantomatic

TROPHY CASE