The game-side code, not really (I am ashamed of reading it myself). The engine-side is a bit less shameful, but I'd rather not as I mentioned elsewhere, especially on github. I may change my mind though.
That's a shame, i like how you go about using Rust to have crystal clear structure while sidestepping the unreadable side that comes from using all of its nuances.
I'd kinda like a look. My Code is dependency free where possible (up to the graphics library for making the pixels go on screen) too - and everything else is a clean pipeline. Soooo i can only speak for myself, but if you have some parts that don't make you cringe much but proud - please share!
It's less about implementation of functionality, im mostly curious about your style! :)
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).
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"
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 {...}".
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.
You mean implicitly? I am aware that idiomatic Rust strongly prefers iterators over indices for performance, but in my case, the only place where it really matters is when counting pixels to draw, and there is no kind of collection there, just x,y numbers.
Yep implicitly, for receives an IntoIterator, so it iterates either on an iterator like 0..10 or something that can be converted into an iterator like &myvec
(Note that it was a severe design flaw to make ranges like 0..10 iterators directly rather than just IntoIterator, because this means ranges can't be Copy and as such it's inconvenient to pass them around.. but fortunately they are going to fix that in a new edition)
But actually..
Do you mean you prefer writing for i in 0..myvec.len() and then accessing myvec[i], rather than using for x in &myvec or for x in &mut myvec, and using the x directly? But why?
so there is also no global state/objects. All state is passed down into the functions.
There were some cases that RefCells came in handy (like having an array of references of all models in the scene) and lifetimes were suggested by the compiler at some other similar functions, by I ended up not using that specific code. To be clear, I have nothing against those (on the contrary), it just happened that I didn't need them.
One small exception: I have a Vec of Boxes for the scenes, as SceneCommon is an interface and you can't just have an array of it, obviously.
Thanks! That seems like a nice subset for a lot of use cases. You say it isn't functional, which in rust it is hard to be pure, but if you consider it a spectrum, the style you describe is closer than most game code I've seen.
Right, it's a spectrum, you can't avoid some things (and rightly so).
Another soft rule: no member functions (except for the Scenes); structs are only data, all functions are free functions.
Also no operator overloading, so yes, lots of Vec3::add(&v1, &v2). I was hesitant at first but this makes for more transparent ops (* is dot or cross?) and does not hide the complexity.
The whole thing is around 6-7kloc and I think it would be possible to rewrite in C++ in a day or two.
I have considered getting a Mac in the past (even a very old Air) to make and, most importantly test, Mac builds, but I never got to it and cross-compiling to Mac seems like a pain, if at all possible. If you have a VM laying around though, it should work.
A good thing about the approach is that if it compiles, it should work exactly the same everywhere and with predictable/linear performance, no matter the environment or driver situation.
you're right, I wasn't aware of it. Of course you could build it and leave it as is, so we would need to accept the binary, but still - a lot of work. Makes some good projects made by devoted programmers exclusive to other platforms, sadly.
Didnt you think of making it open-source on github?
The game-side code, not really (I am ashamed of reading it myself). The engine-side is a bit less shameful, but I'd rather not as I mentioned elsewhere, especially on github. I may change my mind though.
That's a shame, i like how you go about using Rust to have crystal clear structure while sidestepping the unreadable side that comes from using all of its nuances.
I'd kinda like a look. My Code is dependency free where possible (up to the graphics library for making the pixels go on screen) too - and everything else is a clean pipeline. Soooo i can only speak for myself, but if you have some parts that don't make you cringe much but proud - please share!
It's less about implementation of functionality, im mostly curious about your style! :)
I'll see if I can produce a reasonably readable stripped down version (the lib + an example scene) and I might be back soon ;)
I love custom game engines. Looks fantastic! Will you be sharing the source?
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).
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
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"
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 {...}".
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
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.
> I have not used: iterators,
Here's a counterpoint: every time you write a for loop in Rust, you are using iterators.
You mean implicitly? I am aware that idiomatic Rust strongly prefers iterators over indices for performance, but in my case, the only place where it really matters is when counting pixels to draw, and there is no kind of collection there, just x,y numbers.
Yep implicitly, for receives an IntoIterator, so it iterates either on an iterator like 0..10 or something that can be converted into an iterator like &myvec
(Note that it was a severe design flaw to make ranges like 0..10 iterators directly rather than just IntoIterator, because this means ranges can't be Copy and as such it's inconvenient to pass them around.. but fortunately they are going to fix that in a new edition)
But actually..
Do you mean you prefer writing for i in 0..myvec.len() and then accessing myvec[i], rather than using for x in &myvec or for x in &mut myvec, and using the x directly? But why?
Without lifetimes arcs boxes or refcells do you have a lot of clones? Or a lot of unsafe? Or is it mostly single threaded?
It's all single threaded. Just structs being passed around. For example, the mesh drawing call is:
drawmeshindexed(m: &Mesh, mat: &Mat4x4, tex: &Image, uv_off: &TexCoord, li: &LightingInfo, cam: &Camera, buf: &mut Framebuffer)
so there is also no global state/objects. All state is passed down into the functions.
There were some cases that RefCells came in handy (like having an array of references of all models in the scene) and lifetimes were suggested by the compiler at some other similar functions, by I ended up not using that specific code. To be clear, I have nothing against those (on the contrary), it just happened that I didn't need them.
One small exception: I have a Vec of Boxes for the scenes, as SceneCommon is an interface and you can't just have an array of it, obviously.
Thanks! That seems like a nice subset for a lot of use cases. You say it isn't functional, which in rust it is hard to be pure, but if you consider it a spectrum, the style you describe is closer than most game code I've seen.
Right, it's a spectrum, you can't avoid some things (and rightly so).
Another soft rule: no member functions (except for the Scenes); structs are only data, all functions are free functions.
Also no operator overloading, so yes, lots of Vec3::add(&v1, &v2). I was hesitant at first but this makes for more transparent ops (* is dot or cross?) and does not hide the complexity.
The whole thing is around 6-7kloc and I think it would be possible to rewrite in C++ in a day or two.
Very cool project, can't play because on mac but looks like cool approach
I have considered getting a Mac in the past (even a very old Air) to make and, most importantly test, Mac builds, but I never got to it and cross-compiling to Mac seems like a pain, if at all possible. If you have a VM laying around though, it should work.
A good thing about the approach is that if it compiles, it should work exactly the same everywhere and with predictable/linear performance, no matter the environment or driver situation.
I believe you can build to mac targets on github though
Didn't know this, but I'd rather not use github to be honest. Isn't there also some kind of signing required to publish a Mac build?
you're right, I wasn't aware of it. Of course you could build it and leave it as is, so we would need to accept the binary, but still - a lot of work. Makes some good projects made by devoted programmers exclusive to other platforms, sadly.
It works perfectly cool through wine. Also i think adding mac builds wouldnt be hard given its simple dependencies.
Yeah it should be just a simple cargo build. But for the same reason it should be playable through any emulator/translation/VM layer as you mentioned.