Asklemmy

I was having similar thoughts about Nim and portability when I saw this Github project (it uses APE but it's more like a runtime for software? though I'm not sure if actual usage is easy like other frameworks/libraries etc). Though honestly I will probably sooner do something with Godot or Raylib via bindings instead, which is unfortunate because the 2D polygonal style is not well supported* unless you keep it really simple.

I'm thinking about tinkering with low-poly 3D+mostly untextured models (vertex colors, see vertex color skyboxes as an inspiration for the style/concept) to sidestep the 2D issue (as it's well-established in 3D). My mousewheel is currently broken, though. And I'm not totally happy about the idea of using Blender, though any 3D editor opens up more options (in-engine stuff is cool, but probably locked-in).

It's also difficult finding discussion about Nim on the fediverse, particularly when people don't explicitly say nim-lang. That and often Kbin doesn't properly federate Mastodon replies so potential conversations are just broken. And I haven't seen other languages that come close to the same feel, some scripting languages might be OK if their performance wasn't a problem (and often there are options to help, but it also makes me question if it also wrecks their compatibility with bindings when it's a different thing).

* = 1. Godot 4 has a still-in-PR-stage feature that can be used for art but may not perform well enough to be used for an entire project with MSAA, also still no Nim bindings. Also even then, the editors could be better (vertex colors and internal vertices).
2. I am not aware of polygonal tools for Raylib at all, started making a text format and loader but got bogged down on details. And it would be even more basic than Godot's polygons, no animation aside from just making multiple frames and swapping (or maybe some basic transform effects, but this would all need to be done manually while Godot has in-engine animation).

Regarding the assembly and cracking stuff, I've actually taught myself that (not RISC-V, but x86, arm, and a little mips and PPC). The way I did it, was largely practice by doing. Specifically, I tried to almost every weekend put some time into competing in CTFs. Focus on the reversing challenges, look for writeups on similar challenges, fail, and once the CTF has ended, read the writeups and try solving again. Rinse and repeat, each weekend you'll slowly get better and better.

Additionally, start messing around with an assembly debugger. For me, being able to step through instruction by instruction and watch as the values of the registers change, made everything sort of click. Start with making your own program in c, then debug the assembly, and pay attention to how your c code got converted to assembly.

There's also some decent books out there, I like NoStarch (there's a malware book and also hacking: the art of exploitation, the malware book is more reverse engineering, but both should be decent starting points for assembly).

Btw, picoctf is a good starter one that is hosted year round.

Here is an alternative Piped link(s):

this video does an excellent introduction to the kinds of calculations done for 3D scenes

Piped is a privacy-respecting open-source alternative frontend to YouTube.

I'm open-source; check me out at GitHub.