By fine I mean running all these at the same time: firefox with several tabs, development tools, Blender and GIMP. All snappy and fast. Even the HDD in the laptop is only an annoyance during/after a cold boot. Then it makes no difference. I daily drive both for the past 8-15 years. The laptop sits at ~10-15W idle and the i5 in it is a workhorse if needed.

Of course there are uses for better hardware, I am not dismissing upgrades. But the whole modern hw/sw situation is a giant shipwreck and a huge waste of resources/energy. I've tried very expensive new laptops for work (look up "embodied energy"), and Windows 11 right-click takes half a second to respond and Unity3D can take several minutes to boot up. It's really sad.

edit: To be honest I have to add a counter-example: streaming >=1080p60 video from YT is kind of a no-no, but that's related to the first sentence of my post.

It works really well though. Does exactly what I would expect and hope from such a feature.

[1] https://kingscrook.itch.io/kings-crook

[1] https://news.ycombinator.com/item?id=45270981

[2] https://totenarctanz.itch.io/a-scavenging-trip

Really cool news about raylib. I will seriously consider using this.

There are some methods that help a lot, like keeping a completely perpendicular or parallel viewing direction, and adjusting the distance with the corresponding set of thrusters. Even slight angles mean you have to randomly mash forward/backward/left/right and hope to keep a steady orbit, it's not gonna happen.

For what it's worth, even for me now, it would take more than 10 tries probably to beat Master on Mission 1.

Do you mean directly e-mail/contact said person?

To be honest, grepping the source, I found a couple of places with for x in &myvec. Probably tried them while learning the language, they worked and left them there.

But really, I am just more used to the old way. It visually feels more familiar, I have an explicit i to do things, and it's easier to delete/manipulate elements while in the loop and not invalidate anything. It's not that I am against an iterator if it matters and it's better, of course.

In my case, the important loops are like "for i in x0..x1 { draw(i, y); }". Is there a way to turn this into something that, for example, skips the bound checks or optimizes it in any other way?

I've become too familiar with it over testing to notice unintuitive behaviour, but I think I understand what feels off: in real world units, the gradual region you describe is very wide, and feels linear. This would make for very boring gameplay (imagine spending minutes to reach the planet). You need to keep the playable area [radiusForce0, radiusForceMax] small. So you will either map that small [r0, rmax] into real world [F0, Fmax], which means the force will be almost constant across, or "compress" the [F0, Fmax] curve so that you can fit both [zero outer space gravity, strong surface gravity] into that [r0, rmax].

That's what happens here, I probably tweaked the values for the second case. It's kind of an accelerated version of reality and the margins feel very tight, and you have to "buy into" that reality.

For example, Master difficulty in Mission 1 may seem impossible, but if you try to be gentle and find a balanced orbit, you can complete it with miniscule fluctuations in distance and minimal input.

Just rambling though, I never really actually designed or balanced the game.

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 {...}".

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.

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.

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.

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.