mvx64

Agree. But compared to the new APIs, OpenGL is better in that regard. I would argue that legacy OpenGL is even better.

You can implement in software whatever you want and just handwave specific parts to GL, like rasterization. The rest of the boilerplate code will be minimal.

In new APIs you are bound to write 100s of lines of boilerplate code to get to the point. In the time you should be learning about barycentric coordinates, you are still learning about descriptor sets. And still, you don't learn about rasterization, texture mapping, clipping, face culling, because they are still fixed pipeline.

The only problem with learning with 100% cpu rendering is that you need some patience before seeing beautiful stuff because you need to learn/implement everything up until that point.

Yeah, it may not be in the spirit of 90s software rasterizing, but since you don't offload the transform, lighting, and rasterizing procedures to specialized hardware, you technically do it "with code". The parallelization goes against the spirit though.

I know I am in the minority and my uses/needs/requirements are not average, but I am perfectly fine with running Xubuntu on the following hardware: 1) 4GB 2011 Thinkpad with HDD (yeah really) and 2) 4GB 2009 Phenom desktop (was Win10 until a month ago).

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.

I found out about profiles recently and I just couldn't believe that that's the standard way to access them. Also, it's not obvious which profile you are currently on, so there are some silly but necessary workarounds like having a dummy bookmark with the profile name on each or something like that, while it could just be a string next to the address bar.

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

It would be cool indeed, I played around with !include_str and co. and works as expected. It wouldn't be possible for the user to modify the assets though, and to save the settings file.

Understandable. That's kind of the goal, the gameplay is very shallow complexity-wise, so raw responses/difficulty is one way to put some playing time into it.

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.

Nice discussions! I've seen many of these projects lately around related communities. Happy to see a trend around this, as I really think there is actual merit in the topic. My project was more of a random timesink than something that pushes the matter forward though.

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

Interesting, I will look more into this.

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?

Thanks for trying it out. It's a regular inverse square law, no tricks. The numbers (masses, distance) determine the final acceleration but not the actual trend of the curve.

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.

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

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.