NOT_A_ROBOT

Working on the save selector UI now!
bevy_ui is kinda hard, but I think I’m still gonna use it, cuz I think it’s more performant than egui.
Second image shows error handling!

I think the button texts are a little hard to read, though. I’m gonna have to improve the contrast.

I was almost done with the OPFS integration but I forgot to implement resetting the savedata so my test failed…. Whoops!

Still no dice…

I posted this in an online forum, and someone saked me if I’m familiar with OPFS: https://developer.mozilla.org/en-US/docs/Web/API/File_System_API/Origin_private_file_system
This seems like a better thing to use instead of hacking around IndexedDB, so I guess I’ll refactor yet ANOTHER time and make the web storage use OPFS instead.

Finished the build pipeline, and now nonweb storage works, but I still need to fix the issue with web storage not working.

I’m working on creating the build.rs pipeline to convert a default save in RON into compressed CBOR. However, I seem to have uncovered a bug in RON: it apparently fails to parse non-decimal integers with an integer suffix (e.g. 0xAu32). I’ve reported this to the RON devs, so I guess next I’m gonna try to work around this issue somehow.

A friend of mine suggested CBOR instead of NBT. And they seem to be right! It’s way better in terms of both perf and uncompressed sizes. Might be because there’s no mutf8 shenanigans that you have to deal with, unlike NBT. I think I’m going to use cbor4ii instead.

Got an AI agent to make me a benchmark of 7 different NBT libraries.
I used this dataset of about 400 MB of JSON as the input for the benchmarks: https://www.kaggle.com/datasets/ambassador4ik/lolzteam-contests-json-20-jul-2024
It seems valence_nbt is the best both in terms of perf and for serialized data sizes!
Clear W for valence_nbt over everyone else, I guess.
Also I’m not sure what hematite_nbt is doing to be dead last. Maybe they’re not as focused for optimizations..

(Only the library and dataset researching time was counted in this devlog; I made sure that the AI agent time was not counted whatsoever)

Finally got basic web storage tests working! But now I think I want to really make it extensible.
Right now, it’s not very extensible:

• Nonweb: I give each save exactly one file. This means to save/load, the program will need to read/write the entire save file.
• Web: I give each save exactly one object in the IndexedDB object store. Same concern applies here, but with objects instead of files.
• Both: Uses JSON serialization/deserialization. This is readable, but can sometimes lead in pretty big savefiles. For instance, my Kerbal Space Program main save files is about 12 megabytes in size, and that’s not including quicksaves. It all really adds up.

The plan:

• Nonweb: Give each savefile one save directory. This means I’ll be able to easily extend it later on. Also, use NBT data (like Minecraft) since it’s packed (binary) but still extensible/moddable.
• Web: Restructure the IndexedDB object store, so that one one save can be split across multiple objects. This means I’ll have to change the current key layout to use compound keys, like ["save_name", "object_kind", "discriminator"], where save_name is the name of the save, object_kind describes the inner data’s relation to the save (e.g. main save, quicksave, etc.), and discriminator is to discriminate between two objects with the same save_name and object_kind (it would not be very cool to only be allowed one quicksave!). Also, use NBT data for the inner data, but use a JSON wrapper because IndexedDB wants it to be like that.

Working on implementing save storage resetting! Featuring: a heuristic-based directory-deletion risk assessment algorithm so that the game doesn’t “accidentally” wipe C:\Windows (lol)

Working on web save storage! I’m using IndexedDB for this since files can get BIG.

Improved runtime perf by 33%
(Numbers are from Ungoogled Chromium with 20× slowdown)

Also documented it in README

Finshed save subsystem initialization and error handling for non-web platforms!

Working on storage setup logic! Now the game will make a save directory upon startup.
I’ve not finished error handling yet, though.

More work on save data validation and deserialization!

Working on adding a system to load state from a TOML file!
Saving is not yet planned, though. This is for easier syncing with NASA Horizons.

Solved!
Who’d’ve thought the real problem was in the far-away terrain collider handler?

Lol.
Lmao, even.

I’m keeping the Verlet integration tho. Δt⁴ error for the price of two Δt² substeps is hella worth it

I made a basic implementation of Velocity Verlet to address the inaccuracy. It seemed to work in the integration test, but the orbits in the produced binary still seemed unstable/spiraling. I’ll need to figure out why that happens.

I’m having this issue where the vessel just flies away instead of staying in a stable orbit. I guess I’ll try to debug it.

Finished the speedometer!
What next?
We’ll see!

Working on the logic for formatting the speedometer!
I also refactored the SI prefix to its own enum

Working on the UI for the speedometer!
Sorry I’ve been taking kinda a break lately. For some reason I’ve been getting distracted by other stuff.
I’ll try to be more active in the future.

Added keybinds to altimeter for switching modes! Also, improved the control mode UI a bit.

Mobile altimeter done!

Nevermind, a more pressing issue: the altimeter covers too much screen space on mobile!
Now I’m trying to make it more responsive.

Finished the altimeter!
Next I guess I’ll try to hook it up to the menu control mode.

Implemented switching between reference frames!

Added display for different selectable reference frames:

• Above Sea Level
• Above Ground Level
• From Planetary Centre

Working on calculating the altitude!
Getting the distance to the centre of the celestial body and getting the sea-level altitude is easy. Getting the ground-based altitude is not quite easy…

UI done! Time to make logic to update its value.

Finished the altimeter inner formatting logic! Next, I’ll need to make it actually show up in game.

Improved visibility and fixed some bugs with the overlay!
Next I guess I’ll try an altitude display.

The prograde/retrograde overlay now works! I just need to make it clearer and maybe add a needle.

Added a test for importing icons

Added a basic svg to png processing build.rs pipeline! Now hopefully I can start using regular ImageNode.

bevy_vello had issues with Z-indexing, so I’m trying out bevy_prototype_lyon now and sadly it doesn’t appear to have a UI version; just a Sprite version that can’t quite be positioned using Node.
I think I’ll have to make a build script to rasterize SVGs into PNGs, then use that for the icons.

Made the icons work! Not quite visible at the moment though, so I’ll have to figure out a way to improve its visibility.
I used bevy_vello for this, but maybe I should’ve used bevy_svg instead?

Working on adding prograde/retrograde markers to the oribar!
Right now I got something scrolling with the oribar. Next I’ll need to actually get the motion of the vessel and use that. Not to mention the SVG icons I need to use for the icons.

Switched to JetBrains Mono for the oribar instead of WDXL

Added a needle and indicator to the oribar!
Would be cooler if it used a monospace font, though.

Added numbers to the oribar!

Added a basic rotation indicator that I call the Oribar (Orientation bar)!
It’s based on a similar principle to KSP’s navball but for 2D instead of full 3D.

Created a GitHub CI pipeline for this project!
It’s now available on https://not-a-normal-robot.github.io/hack-club-space-program/

Did a round of small refactors and changed the background of the main menu to Surface instead of pure black.

Fixed some issues with buttons not triggering properly upon click

Got tab switching working! But it’s a little buggy, so I’ll need to fix some stuff.

Improved the look a little bit, but I haven’t quite finished the tab switching handling.

I got article loading working! Next up, I have to get tabs working.

The main element is now scrollable! Next, time to add some sections and texts.

I just needed to use Display::Grid on the root element, and structure things a little differently, and now the aside is looking scrollable and responsive!
Next, I need to make the main element scrollable.

Trying to add scrolling, but it seems it doesn’t work yet. I need to figure out how to constrain the text container’s size somehow.

Added main and aside parts in the about menu (also responsive)!
The main part is for the texts, and the aside part is for the list of tabs, but I haven’t implemented it; I was focusing on the layout and responsiveness.

Made the about menu more responsive!

Apparently I just forgot to add in a camera.
After a bit more cooking, I managed to make a very empty UI layout for the about page!

I improved my activation detection (pointer click or enter/space on tab-selected button)!
On a side note, I tried to add an about page but something seems to have gone awry… The window no longer updates when I press it for whatever reason.

Rewritten focus changing code!
Now, the focusable data resource is only updated every time one is removed or added.
It also uses a HashMap and Vec combination for fast O(1) lookups, at the cost of O(n) insertions (which is fine because n is often small-ish)

Fixed issue in test harness that caused essential systems to not run and tests to fail

Added an i18n library for better future translations!
Currently, only English is supported, but this will make future translations a lot more feasible.

The library I used is i18n-embed.

Added tab-navigation + pressing the button using Enter/Space. (Easy to make, but man did it take a while to refactor using a macro)
Also, made the control UI in the game scene use the new fonts since I removed the default font (I’m not gonna use it)

Working more on the main menu!
I’m trying to figure out how to vertically centre the text in the button, but still make it light up on hover/press.

Got font loading to work!
Next: Color scheme, title logo

Main menu functionality done
Next: Fonts, color scheme

Designing a main menu prototype!
Right now it’s already pretty responsive, but I’ll need to add fonts, functionality, and of course, improve the color scheme

Finished the control flow for the main menu (and possibly other scenes), but I haven’t added a proper UI for it.

Here’s me switching back and forth between the main menu and the game scene, note how the state resets every time I go to the game scene
(Saving and loading isn’t implemented yet)

Added camera movements! (+ resetting it)

Added a way to switch what the camera is attached to!

Tried to make a multithreaded WASM build, but it’s apparently not supported yet, doesn’t work on Chrome, and isn’t any faster on Firefox.
Oh well.

Added a loading screen for the web build

Added a wasm-opt step

Rewrote the web build script in TypeScript

First signs of the WASM version working! How exciting!

Improved terrain colliders a little
rn I’m working on compiling the game to WASM so that’s cool

Collisions now work! Mostly!
Just need to add a bit more padding so it’s always underneath the vessel.

After a LONG time trying to debug, terrain colliders seem to… acknowledge the intersection and NaN its way out of there. No clue why that is. I’ll have to spend more time debugging.

Added two more tests; new logic module now has two functions left untested (which I should get to unit-testing soon enough)

I can’t just feed Rapier the tens of millions of terrain colliders per planet, of course! I’m experimenting a way to detect the range at which a vessel resides, and only generate the detailed terrain colliders at those ranges. No visuals or anything yet, but the tests are going well, for now.

Terrain rendering finally works! Now time to implement terrain colliders, I guess.

After more debugging and trying things out, I can confirm the problem is likely to do with the update_lod method for whatever reason.

Wrote a unit test for something and it seems like that could be the issue!

The terrain system still needs work… Not quite sure what’s happening here.

Uhhh what is happening?

Did quite a bit of work integrating the terrain generator to the mesh.

I haven’t seen its generation yet but all the tests pass. I’ll try to see if the rendering works fine in the actual application. After that I’ll need to somehow handle terrain collisions. (i.e. lithobraking, ha!)

Worked on the terrain rendering system! Nothing to show yet in terms of render output, but I’ve been making progress on shaping the code for it.

Refactored the entire terrain code, and the tests still work! (Hooray!)
Okay, NOW I think it’s time to integrate it with the celestial bodies.

Reworked how tests work!

Index buffer seems to work well! Time to hook it up to the rest of the codebase?

To make the index buffer I’ll need to decide on the primitive topology to be used here.
Although TriangleStrip seems to reduce index length, it seems to increase the number of tris drawn. And also it seems to be more complex overall, so I’m going with TriangleList.

Implemented the vertex index getter! Time to work on the mesh stitcher!

I think I’ve figured out all there is for generating the LoD terrain, now I just need to figure out a way to stitch them all into a mesh.
For this I’ll need to figure out how to get the index of the beginning and end of each LoD level somehow. Back to Desmos I go!

Implemented the Desmos algorithm in Rust!
I just need to figure out how to stitch the LoD parts to a single Mesh.

Made a prototype of the LoD algo in Desmos! Time to put it to Rust I guess.

Currently thinking a lot about terrain generation and LoDs.
I think I’ll make one with 6 levels of LoD, each being 128 vertices and the next LoD being 16× smaller (therefore 16× finer) than the previous one.
This means the highest one will be sized at 1/16777216 of a revolution, and each vert would be spaced out with 1/128 of that.. This is less than a meter for a Jupiter-sized planet.

Made a basic control to rotate the camera!

I did some refactoring and stuff and plan to add basic camera controls! I’m thinking it should be modal kinda like Vim.

Tried to hopefully reduce the amount of imprecision that happens with the current rail to sv thing, but it ended up making things worse. Oh well.

Fixed! Apparently I was applying some position/velocity adjustments twice.

The test revealed a flaw! I’ll have to find the cause and fix it.

After a lot of thinking and discussing with gpt I think I’ve managed to formulate a good algorithm to update the state vectors of on-rails objects. I’ll still have to write tests for this, though!

Still working on implementing on-rails movement propagation.
During which time I found this peculiar issue where since I don’t derive Copy on my Orbit structs, some things are just not possible in constant-time.
For this reason I’m adding a copy feature flag to my keplerian-sim orbit library so that users can opt in to deriving Copy.

There’s nothing wrong with the friction, it’s just that round objects tend to move like that…
Sometimes I’m reminded how much common sense I’m seemingly missing

The problem? The celestial body’s too small and too massive. It’s like it was a black hole!

Anyways, I’m now using a celestial body akin to the Earth. It kinda works? But the friction seems too low for whatever reason. I’ll have to figure out why.

Tried to implement Newtonian gravity. I guess it’s a little too strong? I’ll have to figure out what went wrong, because the velocities are extremely high for whatever reason..

I think I’m done for the day. I implemented writing the “on-rails mode” information. Haven’t done anything with that value yet, though. I’ll still need to test it first before adding more stuff on top.

Working on writing from state vectors into on-rails information! I decided there can be three types on on-rails state:

1. None: Does nothing
2. Orbit: Orbits around the parent body
3. Surface: Attached to the surface

Commit still pending, and tests are also yet to come!

Currently trying to design how I’d implement on-rails and orbits in general (hence the errors)

Project shipped! It’s available on https://not-a-normal-robot.github.io/EndOfTime/

I gave up and used my own implementation instead—this time, handling leap years better

Looks like how I handle the mixed mode was quite naïve and not quite correct, because it doesn’t handle leap years correctly. I’m planning to use date-fns (https://date-fns.org/v4.1.0/docs/differenceInYears) instead to correct for this issue, however, integrating Closure Compiler with NPM packages seem a little more complicated than expected, so I’m trying to modify my build script to account for this.

Added favicon

Improved the CSS again

Improved the CSS

Fixed mixed mode, it works now!

Worked on JS micro-optimizations, now it’s at 2660 bytes minified from 2713 (~2% improvement). I guess I’m too much of a perfectionist—

Got the countdown working partially. There are spacing issues and the Unix counter isn’t ticking up yet

Basic UI done, functionality incomplete

Made a basic project template, time to work on it

Refactored entity creation using a builder pattern. That way I don’t leave out certain things by accident.
Maybe now I can work on adding Keplerian orbit physics?

Broke up the code into smaller, more manageable files

After more bugfixes, rigorous code examination, refactoring, and retesting, all tests on the reference frame logic is now complete! Now I should work on integrating Keplerian orbits with it.

Found the issue! Just needed to make the celestial body KinematicVelocityBased instead of Fixed.

Okay in the test the collisions work kinda fine but in the binary it barely does anything…?

This is really weird

After some careful analysis adding dbg! prints and stepping through the code, it seems like it’s got to do with Rapier’s collision detection mechanism. No clue why it’s triggering here, the objects should not have overlapped. In fact, it should never overlap.

Fixed a bug where rigid-space velocity doesn’t get updated from root-space velocity. Still gotta figure out what’s wrong in this test, though. No clue where it’s getting that number from.

Fixed that, as well as a bug where root velocity gets applied to the root position but doesn’t use delta-time. Still got more stuff to figure out, though!

I’ve encountered one of the possibly-many problems I need to solve: I forgot to update/generate the rigidspace position from the root position. Whoops!

I’ve yet to make the origin-shifting algorithm work, so I’m looking to try to debug it. However, I believe it’d be easier to debug in a more minimal environment, so I’m preparing a custom integration test framework. to step through the simulation and see what’s going on. This is also useful to prevent future regressions. So far, it’s looking great!

More work on reference frame conversions!

Got a basic window working in Bevy! I’m new to this, so I’m taking my time reading tutorials and whatnot.

Refactored benchmarks, fixed documentation errors, and added some missing features. Now the Criterion benchmark reports show throughput amount!

All checks pass, and keplerian_sim v0.7.0 is now live! https://crates.io/crates/keplerian_sim

I made clippy stricter, and there were lots of errors, but I’m working through them right now! https://github.com/Not-A-Normal-Robot/keplerian-sim/pull/34

More tests, more subtle bugs. This time, GitHub Copilot found this bug that slipped through testing, and so I added a testcase for it.

I’m glad I decided to make unit tests. I caught a subtle bug before pushing to crates.io.

All tests pass! Only the doctests though. I have yet to make new unit tests for the 2D orbit logic.
Next up:

• Make 2D unit tests
• Refactor the code

Before I can work on the game I’ll need to modify my keplerian orbit library (https://crates.io/crates/keplerian_sim) to have specialized 2D orbit structs. It’s currently very much in the experimental stage at the moment.