I took all the small independent patches that applied to the multiplayer management code and combined them into a major rewrite of the multiplayer class. Surprisingly, and for no apparent reason after doing that, my tests didn’t show any bugs. Therefore, I consider the mod finished. To be honest, I can’t really do more testing as other people’s availability is a significant constraint.

I added a README and a license to the project; it is now under LGPL-3.0.

Another random screenshot, but I didn’t have any friends on hand to illustrate the multiplayer. My mod isn’t doing this; it’s another mod I’m using to help me debug.

I’ve documented the optimization techniques used in the app.

v1.2.2 - Statistics!

I’ve added a statistics and scoring system to the game!

It does exactly what you’d expect: it tracks your wins, losses, and average play time, while keeping Normal and Hard modes separate.

Of course, all stats are saved, so you won’t lose your data when closing the app (:

Aside from that, I did some refactoring here and there, minor tweaks, etc.

This is officially the last content update for the game. It’s finally feature-complete!

I was fed up with hardcoding text display in the menus, so I refactored the entire menu rendering system. To do this, I built a component rendering module with a simplified Layout system.

I probably over-invested in this new system, it was a huge sink in terms of time and brainpower, but I truly hated how I was handling UI text before.

v1.1.0 - The States saving!

This version introduces a game state saving system! When you quit the game while in the middle of a match, it is automatically saved. As soon as you relaunch the game, it reloads and you can continue playing as if nothing happened. Your game time will not be affected.

This is very useful, especially if you are working on your Hard Grid and suddenly need to calculate 1 + 1well, you can now exit the game, do your math, and come back. Or, if you don’t want anyone to see you playing Minesweeper, you can close it without losing your current progress.

The principle is simple: when you exit the game, it saves all the important parameters of the current match into a minesweeper_game.sav file. Then, when the app launches, if the file exists, the data inside is loaded.

Technically, this feature was not easy to implement at all! Fortunately, I had already planned the game’s structure from the beginning to potentially add this feature, which saved me from having to build something flimsy or rewrite part of the engine.

I realized there was an error, there was a dummy version of the file-reading functions in eadkp (the lib I wrote and am using here), so I ended up doing some bug hunting.

In any case, this was an addition I was dreading, but it all came together nicely in the end, so it’s all good (:

Refactored documentation and guide to be clearer for people outside the NumWorks community.

Translated the documentation into English.

Moved the documentation to the GitHub repot wiki section.

v1.0.0

First version of Minesweeper for the Numworks calculator.

New features:

• Added a rust.yml workflow to automatically include the compiled package (NWA) in every release and tag.
• Added a README (you just gotta have one).
• Added a LOGO (I didn’t have one yet ¯_(ツ)_/¯ ).

Test video on the real hardware! (It worked on the very first try!)

I added explanatory text and the final time to the EndGame screen. I also added a ‘Hard’ mode with the largest possible grid (small cells and 15% mines).

I added a timer and the theoretical number of remaining mines.

I added the title bar rendering for both the game and the main menu. I also refactored part of the code for these bars and moved the rendering functions into a separate file.

I improved a few details, like centering the grid on the screen, fixing the main menu text alignment, and adding a background to the main menu.

I also made some code improvements, such as reducing memory fragmentation by eliminating unnecessary heap allocations and deallocations whenever possible.

I added the Game End screen (won and lose). Also, when you lose, all the mines are revealed.

I’ve implemented the system that reveals all empty tiles (I don’t know what this system is called, but there you go).

Next step: the Game Over system!

I added mine rendering

I’ve added the main interactions (reveal, flag). I also fixed a bit-shift bug in how I was storing the number of adjacent mines, as well as a bug in the randint function of my eadkp library used here.

So, you can’t tell just by looking at it, but I’ve written the state management code and the cell display logic (which was more complicated than expected!).

I’ve also coded the cursor movement. Now, I’m going to tackle the interaction system.

I added:

• Background rendering
• Cell margins
• Different cell rendering based on size (large or small)

And fixed:

• Cell sizing

I am currently creating a Minesweeper game for the Numworks calculator.

Well then! It turns out I might have forgotten to install Wakatime in my
Docker container, so a good portion of my coding time wasn’t tracked ):
You can easily add at least 2 more hours to the total.

First off, I spent 2 days thinking about the code structure. Since there’s
no engine, no multi-threading, and especially some nasty screen tearing
that forces me to only update what’s necessary, I can’t redraw the whole
screen every time (that’s my main constraint).

First, I coded a State system to manage what to render (menu, game,
game over). Then, I built an event-driven graphical rendering pipeline.
Everything works through a shared object, allowing all components to
access the same data (position, score, etc.).

I admit the current rendering isn’t great (I forgot the background
instruction, sorry), but you’ve got to have the vision! This is literally
the first test render (by the way, my code worked in only two tries,
which is remarkable).

Fixed the Dockerfile (the one I use in the template) to include the Numworks linker dependencies. I had cleaned up the dependencies earlier, but I guess I shouldn’t have! :)

Updated the ‘demo link’ to point to the beta1 release.

Just to clarify, the build tools like the justfile (a cmake equivalent) were created by me for this project’s needs, and then reused or adapted for the project template that uses my lib.

IMPORTANT: I forgot to mention that this library must operate under extreme
constraints!
The Numworks calculator features a Cortex-M7 and only allocates
64KB of RAM to external applications. This library must use as little of
that 64KB as possible (which is already very limited) to leave maximum
resources for the application using it.

I could have applied for the “Optimization” category, but I already knew
what I was getting into, so I didn’t, sniff. However, I am using methods
like zero-copy via segmented file writing functions, as well as optimized
randomization algorithms like Xorshift32 and Lemire’s algorithm.

Changed the image loading method (updated the loader in the eadkp library), updated the license application terms (switched eadkp to LGPL), and made minor documentation and code fixes.Changed the image loading method (updated the loader in the eadkp library), updated the license application terms (switched eadkp to LGPL), and made minor documentation and code fixes.
(fix script removing befor .git)

Added documentation files: CODE_OF_CONDUCT.md, CONTRIBUTING.md, SECURITY.md,
and included a demo video of the base application.

v0.18.0: random and images

I have finalized the last elements before moving to Beta.

• Image System Refactor: Optimized and modularized the system. You can now choose whether an image is stored in RAM (for speed) or kept in Flash (slower, but saves RAM).
• Random Module Refactor: Improved the internal implementation of the Xorshift32 algorithm and implemented Lemire’s algorithm for unbiased sampling.
• Removed the requirement for cargo-nightly.

These two refactors were (normally) the last remaining major API changes. I am now moving to Beta 1 and marking the project as feature-complete. Once I have thoroughly verified everything and completed the documentation, it will move to a full release. This will happen over time as it gets battle-tested by other projects.

I wanted to implement cargo-release, but their system is too rigid for my specific needs. Instead, I’ve created a .sh script that aligns better with my requirements. However, please ensure that the script is as secure as possible and that it reverts to the original state if any error occurs.

Alpha 4 (v0.13.0): Switched to LGPL-3.0 License!

I have officially moved the project to the LGPL-3.0 license! LGPL-3.0 allows you to use this library in your own projects without the license “contaminating” your entire codebase. This means your project’s license remains independent of this library.

I have also (mostly) translated all code comments into French, as the NumWorks community is almost exclusively French. Additionally, I’ve added two new functions to input (is_alphanumeric and to_alphanumeric) to easily convert keyboard input into strings.

v1.12.0 is Here! - Important update: Storage sub-module refactor!

After 67 days of working on refactoring the calculator’s storage management sub-module, it’s finally done!
The logic in storage.rs has been entirely rewritten to be faster, more secure, and more modular. It’s been a long journey, but I finally made it!

-> Release here

For this third overhaul of storage.rs, I had to create a new sub-module: epsilon.rs. This module contains the structures and representations of Epsilon’s system objects. Thanks to this centralized logic, fixing a mapping error on an object will now have an immediate effect across the entire project. This is a huge plus!

This refactor forced me to dive even deeper into the calculator’s memory structure and gain a thorough understanding of its layout.

Minor Changes:

• Updated README
• Synced justfile
• Updated example files
• Added Errors enum
• Added Rust CI workflow

I can now focus on adding new features to the library’s API !

Seems I’ve fixed the infinite loading issue!

BUT, because why not, I found more major bugs. Most are fixed, but one is a real wall:

Under unknown conditions, the host gets timed out from their own server. I’ve ensured that if the server cuts out, clients now return to the menu with an error message. The base game didn’t handle this, leaving everyone stuck on infinite loads—mind-blowing, since handling connection loss is Networking 101.

Problem is, I can’t find the cause of the host timeout yet. Limited tester availability and the bug’s random nature are slowing me down.

Other issues: Laser Triggers are totally desynced 🤷, and conveyor belts are broken even in solo…

List of fixes/patchs applied:

• Fix #12: Simplified (removed the code causing HarmonyX warnings)
• Fix #13: Computer.ReceiveVirtualFunctionExecute() - Checks bounds before access
• Fix #14: Computer.ReceiveVirtualEventInvoke() - Checks bounds
• Fix #15: Computer.ReceiveVirtualObjectDestroy() - Checks bounds
• Fix #16: ObjectManager.ApplyAllGUS() - Absorbs NullRefs during shutdown
• Fix #17: Automatic recovery and menu return if the server crashes or disappears.
• Fix #18: Proper disconnection handling (prevents infinite loading and shows clear error reasons).
• Fix #19: Improved stability and error prevention for Spline/Curve calculations.
• Fix #20: Added safety nets to prevent crashes during control point processing.
• Fix #21: Final security layer to catch remaining errors in curve refreshing.

Sorry for the random image, I didn’t really have any ideas for a proper illustration for this devlog.

I wrote a Python script to check the date format in the save files to see if they’ve been patched by the mod

The main issue with Mechanica’s multiplayer is the infinite loading when a player joins a game that has already been created.

I conducted extensive tests and collected logs to identify the causes of this problem. I decompiled the game code and used profiling tools to pinpoint failure points.

This allowed me to discover several major issues, some of which were much harder to identify than others. So far, I have identified and theoretically fixed 12 problems, ranging from simple precautions to logging improvements to help identify new issues in the future.

I also wrote a PowerShell build script to automatically compile the mod and update it in the game.

The patches I applied are as follows:

1. Date reading issue

   • Fixed saved dates with incompatible formats between players.

2. New game creation issue

   • Corrected date formats when creating new games.

3. Save sorting issue

   • Fixed incorrectly sorted saves caused by invalid date formats.

4. Corrupted lobby data

   • Prevented crashes caused by corrupted Steam data.

5. Inventory loading issue

   • Prevented crashes when loading inventories with invalid Steam IDs.

6. Network errors

   • Logged network errors without interrupting sessions.

7. Premature disconnection

   • Blocked unintentional disconnections when the game is not paused.

8. Lobby transition issue

   • Prevented UI crashes during lobby state changes.

9. Lobby refresh issue

   • Prevented crashes during lobby UI refreshes.

10. Lobby connection issue

    • Prevented crashes when attempting to join a lobby.

11. Player connect/disconnect issue

    • Prevented crashes during player connection or disconnection events.

12. Disconnection without saving

    • Logged and validated premature disconnections.

Version 0.10, 0.11, 0.11.1 and 0.11.2 :

• Removed conditional imports, unnecessary since std already provides alloc when OS=YES.
• Cleaned up imports in the setup macro.
• Switch to 0.11.2-alpha.2
• Publish 0.11.2 to crates.io

Adding a project initialization automation script, independent of cargo-generate!

By using a simple command:
bash <(curl -s https://raw.githubusercontent.com/Oignontom8283/eadkp_template/main/bootstrap.sh)
(Make sure to have curl and git installed), you can start a new NumWorks application using EADKP in the blink of an eye!

OR use:
git clone https://github.com/Oignontom8283/eadkp_template.git project_name
cd project_name
chmod +x ./bootstrap.sh && ./bootstrap.sh

PS: I was tired of manually reconfiguring everything every time, so here it is! (:

Improving the application visuals from the default template code!

Changes:

• feat: Added a subtitle
• feat: Added a footer
• fix: Readjusted the centering of the logo, title, and subtitle
• fix: Moved the rendering code to a pre-display section before the loop to fix a hardware horizontal sync issue.

Refactoring of the default template demonstration code ! (1/2)
AND adding a function (push_image()) to the eadkp library.

Testing the simulator on Linux (Ubuntu-based) !

• Fixed the Docker start command in start.sh from docker-compose to docker compose.
• Added settings.json and extensions.json to recommend the Rust-Analyzer extension and its specific configuration for Numworks.

Functional Simulator !

The simulator has been tested and debugged :

• Fixed incorrect app compilation path:
  ./target/release/target/libsimulator.so -> ./target/release/examples/libsimulator.so
• Updated default app name in source code.
• Added information message displayed prior to simulator execution.

Testing compilation and exporting the compiled application to NWA format for the calculator 🥳 !

• In Cargo.toml: The [target] sections for “device” and “simulator” have been replaced with [[example]]. This changes how builds are managed, now using the --example flag instead of --target.
• In cargo-generate.toml: The justfile has been added to the exclusion list when generating a new project.
• In justfile:
  • Build, check, and send commands now use --example device or --example simulator instead of the previous --target flags.
  • Added a just target command to ensure the thumbv7em-none-eabihf Rust target is correctly installed before building.
  • The export command now uses the correct path for the generated binary (target/thumbv7em-none-eabihf/release/examples/device).
  • The export command now displays a success or error message depending on whether the file move was successful.
  • Added a target recipe to install the required Rust target.
  • The justfile is now excluded during new project generation.

‘cargo generate’ is finally working correctly 😊.

Update templates and fix docker config :

• Use {{project-name}} placeholders for better compatibility
• Enforce snake_case via project_name_case
• Exclude assets/ from variable substitution
• Fix docker-compose paths and remove obsolete Dockerfile

Initial template code. Implementation of the Cargo template system (Untested 😕).

Fix MAJOR compilation ISSUES in the eadkp::builder::setup() script and embedded dynamic allocator imports within the setup macro.

Code preview of the future template using the library (after bug fixes):

Moved build script inside the EADKP library:
- The build script has been moved into the EADKP library for easier usage and project integration.

• C/C++ support testing
• Binary generation optimization:
  • Unused C/C++ code is no longer compiled or linked, reducing final binary sizes.
• C/C++ support in the simulator:
  • C/C++ code will now be compiled and linked when running in the simulator, rather than only on the physical device.
• Support for c/ and cpp/ folders for C/C++ code.
• EIF file extension change:
  • EIF files now use the .eif extension instead of .bin.
• Added Micro and Nano text editors to the Docker image to facilitate editing files directly from the shell.