z3py is going through python’s interpreter to talk to the c++ core of z3; this creates a performance bottleneck as the system size grows. The native input language of z3 is smt2, so coding in plain old python with type hints and then transpile to smt2 would, ideally, help with the bottleneck enabling solving of increasingly complex systems.
That’s how I understand it at least! Someone please correct me if I’m off base.
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! :)
Yes its truly noteworthy project. They exploited Canon cameras by first managing to blink red charging LED. Then they used the LED blinks to transmit the firmware out. Then they built custom firmware which boots right from SD (thus no posibility to break the camera). The Magic Lantern firmware for example allows many basic cameras to do RAW 4K video recording (with unlimited length) - feature which is not even in the high-end models. But it has much more features to tinker with.
There's a fun step you're missing - it's not firmware. We toggle on (presumably) engineering functionality already present in Canon code, which allows for loading a file from card as an ARM binary.
We're a normal program, running on their OS, DryOS, a variant of uITRON.
This has the benefit that we never flash the OS, removing a source of risk.
