[mvx64]

Thanks! For several reasons, most probably and regrettably no, for now at least.

More than happy to talk about any specific part however (e.g. how scenes are handled, the code itself, or how particular features are implemented or optimized).

[nextaccountic]

You talked about using Rust as a better C so I just wanted to ask, do you define any enums with payloads? (also called "sum types" or "tagged unions" in other languages) (edit: also called "algebraic tyeps" and there's an article about it in the front page, though this is a slight misnomer)

Things like

    enum Something {
        One(String),
        Two(i32),
    }

Also, how is your usage of Option? (one such enum)

I think this plus pattern matching is the foundation of Rust's superpowers. It's also very old tech and absolutely not Rust's invention, present in languages like OCaml and SML. Hence the early Rust slogan, "technology from the past, come to save the future from itself"

[mvx64]

Actually yes! I use it when passing a texture into a draw function. I have a TexOrColor enum, and when calling the function you either provide an &Image or a &Color. Before that, if I wanted a colored textureless model, I passed a dummy 1x1 texture to sample from.

And of course, Options and pattern matching are easily the best part of the language and very powerful. I am obsessed with things like "let x = if {...}".

[galangalalgol]

Could you talk more about the subset of rust you settled on?

You said you didn't explicitly use simd, but did you do anything to help the optimizer autovectorize like float chunking

[mvx64]

It's a very procedural style. I have not used: iterators, lifetimes, Arcs/Boxes/RefCells and whatnot, any kind of generics, data structures other than vecs/arrays, async, and many more. Also avoided functional style, builder patterns...

I only used traits to more easily implement the scenes; a Scene needs to implement a new(), a start() and an update(), so that I can put them in an array and call them like scenes[current_scene_idx].update() from the main loop.

Also, I used some short and simple closures to avoid repeating the same code in many places (like a scope-local write() closure for the menus that wraps drawtext() with some default parameters).

The vast majority of the time is spent in the triangle filling code, where probably some autovectorization is going on when mixing colors. I tried some SIMD there on x86 and didn't see visible improvements.

Apart from obvious and low-hanging fruit (keeping structs simple, keeping the cache happy, don't pass data around needlessly) I didn't do anything interesting. And TBH profiling it shows a lot of cache misses, but I didn't bother further.