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.

▲

galangalalgol 2 days ago | parent [-]

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.

▲

mvx64 2 days ago | parent [-]

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.

	▲	galangalalgol a day ago \| parent [-]
		I don't find the idea of rewriting the subset of a blas library I want to use for each project very fun, but I bet with so few dependencies a stripped binary gets pretty small.