e

Added more stone sprites (tiling is much less apparent), and worked on making gems shiny. Doesn’t look too good yet but it’s a start.

Added some new sprites (you can see the copper, lava, and other strange stone purple sprite here). Also tuned procedural generation some more and applied SimBuffer logic (see second image for details) and did some behind-the-scenes stuff to allow multiple opacity values in 1 frame using GPU bind group/tile buffer swapping.

Specific benchmark details: I’m seeing performance rendering from initialization at ~250ms (well within acceptable time limits), and when moving in any direction (diagonal or cardinal), the “worst” frames in terms of performance are ~5ms on my M1 Air, an improvement of 16x over a naive SimBuffer and around 4-8x (depending on zoom) with ChunkCache and no simulation buffer. Quite nice!

Glad to see progress is finally speeding up! I certainly feel like I’ve gotten a lot more done in the past 50 hours vs. the first 50. That’s the way it is once you set up the basics well I suppose :)

I iterated on procedural generation even more! Also got rid of LCH (light/chrome/hue) variation per-block as it looks kind of weird. While the art isn’t very good, the ore pockets and stone variations look a lot better now! I’m happy with the results.

Improved ore generation! The look is still pretty bad unfortunately but at least there are pockets of ores.
Screenshots show some examples as well as a heatmap. Still a lot of work to be done, but it’s acceptable for now.

Also, did more research on optimization! It turns out that there are a bunch of wasm-opt flags I missed previously: I’ve added them to build.zig now.

Images show the improved procedural generation! The first one is a heatmap showing what my modified fractal brownian motion+Worley noise outputs. You can see how the cave-style generation is slowly taking shape: it’s not there yet in terms of being able to place structures, but at least it’s something.

I’ve also made the algorithm >20 times faster by using a simple hash implementation instead of ChaCha12 for generating blocks.

Images in order: heatmap, basic terrain (slightly older version), terrain+extra features/decor.

I got a bit carried away for these two hours working on shader stuff! It should perform much better on lower-end devices now.

Started working on more procedural generation logic! As you can see, here is a (very terrible) attempt at creating some background terrain. I have a plan with where this is going, which I’ll explain more in the next devlog!

Also spent 3 hours working on a way to layer 2 background and tile layers together with opacity. I’m kind of shocked it took that long, but it will come in handy in the future when I need to make a zoom animation and mix backgrounds together.

Started working on fancy shaders for the background! Fractal brownian motion appears quite nice. Also made a few recolored iron ore sprites for testing. :)

Worked on a bunch of stuff, mostly relating to getting depths beyond 16 fully working! You can see an example of it work in the first screenshot (the world spans over 100 digits of blocks technically :O), and the explanation for how it works in the second (it’s quite a lot). Quite happy this worked out! The reason why the quadrant paths are gigantic numbers are because it’s compacting a bunch of 4-bit nibbles of data (0-15) together: the suffix array is expanded to make it easier to see but that’s technically also just a 64-bit integer.

I also successfully figured out what I want to do for allocation! I’m using a big arena allocator that’s storing the suffix array, which is a SegmentedList to prevent memory fragmentation. Although this list is going to be very small, this will certainly help me in the future when I plan to store long-term modifications!

Short devlog time, because most of this time was spent making new sprites! The iron ore took by far the longest, but the result was quite worth it, I think. Was a bit shocked that the colors (similar-looking to Terraria’s) end up looking quite decent when you zoom out a bit (definitely still room to improve though).

Some fairly small changes. Made edge flags work across chunks, eliminated unnecessary structs, and made other small changes! Finally ready to tackle seeding (I’m working on some planning documents).

As you can see from the image, the blocks across chunks are finally connected (you can tell from the lack of pixel erosion and darkening effect of the edges)! Thanks to the chunk cache, this is incredibly fast. (I ended up increasing the cache size from 64->128 to hold more data inside.)

Spent like 4 hours trying to debug an issue with non-deterministic seeding! Turned out I was getting really weird undefined behavior with BLAKE3 hashing, which is what determines how the chunks are seeded.

Ended up fixing that; currently testing procedural generation for individual chunks! You can see it unfortunately has brief lag spikes; that’s with some basic cache logic too, so I’ll have to work on performance improvements some more and cook up some procedural generation algorithms.
I have some concepts already, now that I have the basics down the amount of stuff I can do has increased a lot :)

Fixed some misc issues, switched to ChaCha12 (which supports arbitrary skipping while offering similar performance, for procedural generation in the future), started working on modification/cache tier logic. Also fixed stack size crash due to not using & and improved logging!

As you can see from the screenshot, pixel erosion and edge flag logic has been added back in. Notice how these sprites appear to have a border! I’m still working on improving this; you can see it looks pretty chunky when there’s a lot of blocks nearby. I’d also like to implement a “color mixing” feature where nearby pixels at the edge of a block blend, so connections between different-colored stone or ore blocks look much smoother. This will probably take a while though!

Added the ability to test zooming in, made small WGPU improvements with color spaces and modern Firefox support, centered player, added more CPU features, improved WGPU seeding, and performed various fixes.

Screenshotted: an example of Firefox functioning! Note how the depth is 7 already, and the active suffixes are huge. The infinite nature of the game is finally beginning to take shape!

I plan to investigate procedural algorithms and work on migrating from Xorshiro512** to ChaCha8/12 next and work on pixel erosion logic on the side. ChaCha-family algorithms are pretty good CSPRNGs, meaning I can ask what would happen if I called .next() X times quickly, and it also might be faster with SIMD, which is even better! They also easily let me have 512 bits of seeding data. Really excited about this!

Worked on a bunch of things! The README is now much more clear and outlines more details of the architecture goal I want to achieve. I also worked on inserting logging of the FPS with some tiny text in the top corners because I was debugging weird FPS issues.

It turns out that the “accumulator” approach to frames works best; basically, the way it work is: instead of having a separate requestAnimationFrame and setTimeout, you “accumulate” new ticks, including fractional ones that carry over. Since I know that rendering is the main bottleneck for now, I don’t need to bother capping the logic!

I’m honestly not even sure how not implementing this accumulator logic caused a failure; this confused me for several hours because I thought WebGPU and requestAnimationFrame were unlikely to cause bottlenecks, and the inspector agrees. Yet, it did, so I had to use this approach. Kind of silly, really; I’ve implemented this type of logic before but thought it wasn’t needed this time and got proven wrong.

Anyway, I’ve been working on the architecture bit-by-bit, and have started working on storing modifications and handling depths above 16. This is going to take a while, but it should be worth it!

Started working on more of the architecture of the project! You can see a small portion of the changes to the README I made in the attachments (you can view this on the GitHub repo), as well as a quick performance test of my code: it appears that even on Debug mode in Zig, the main bottleneck is GPU calculations; even regenerating and all 256 chunks appears to be fine on my my machine. Quite nice!

Currently, progress is going much faster than it was, say, 30 hours of devlogging time ago. At this rate I might be able to get to…barebones physics…in 5 hours. (Turns out making a fractal chunk architecture is quite difficult indeed.)

[Click to play the video, which shows a full demonstration of the changes!] Added even more documentation, fixed bugs involving player/camera/viewport, made camera position an integer and added better interpolation handling, improved logger handling for vectors, and simplified TypeScript logic! Also made the build script more robust. Wireframe rendering is also a bit prettier. :)

I also learned how to set up global keyboard shortcuts for VSCode (see second image), which is nice. Since Zig often requires you to do a lot of casting, these will probably save me a lot of time in the long run! Now, I plan to work on making sure that chunk generation is correct in the other corners of the map and making sure the fractal architecture actually works before moving on to making a ModificationStore (which stores whenever the player modifies a block).

[Click on video to play!] Worked on smoother, cleaner camera movement that’s similar to Celeste, and added custom debug logging methods. You can now render text directly to any of the 4 corners of the screen!

===

Also changed build.zig logic to be more performant and only write to enum data if important files were actually changed. This has…improved build times by about ~600ms…and took me an hour. But at least it’s significantly faster!

Added a few new sprites, improved rendering, completely redesigned chunk system, fixed bugs and issues, made constant use more consistent, and also various misc changes. Changed a BUNCH of logic behind the scenes and fixed some bugs, I’ll add it to the README once it’s fully finished! Progress has started getting significantly faster :)

Revamped chunk generation is coming along slowly, going to make more assets over time! Started working on a planning drawing with Excalidraw in Obsidian and looked into what others have made.
Turns out, there’s surprisingly little on the concept that I have, which is mainly water-focused and uses fairly repeating 16x16 textures. Only time will tell if that concept turns into reality successfully!

I’ll probably have to change the way I’m drawing with Aseprite [not included in Hackatime], currently I’m just messing with the filters and I should probably find a more robust way to do things, while using a color palette. Considering the mushrooms took me about 3 minutes it’s probably not as daunting as I thought to restrict to ~8-12 colors per sprite.

Started working on procedural generation! (Yes, it looks super weird right now, but I’ll need to actually start making sprites).

Did some misc things! Improved rendering, switching to OKLAB and better constants for rendering, and removed zig build test in favor of robust native testing.

Added some more block types to make testing nicer! Also added documentation on how to build the project.

I finally got rendering working (it was due to a sprite ID bug and operations that clamped to edge in WebGPU)! I’ve also added wireframes for debugging. Now, I can start implementing the chunk cache logic :D

Camera panning is now smooth [see video] with friction! Also started designing the datatype and system that will and looked at how WebGPU works (not counted in time). Currently working on a new Chunk algorithm. Basically, I’m currently working on an implementation (hence the broken sprites) where chunks are 16x16. The most difficult part is passing this data to TypeScript as I’ve already finished the datatypes.
@@@@@
See the second attachment for my current updated plan. After I’m done with that part of the plan, I’ll probably start working on some sprites and ask others for advice.
It turns out that making your own game engine with low-level languages is quite hard 😭

Made a bunch of changes, below:

Batch 1: Fixed native builds and build location, changed ColorRGBA to use vector internally
Batch 2: Worked on Vite build, changed JS/TS spacing to 4, added WGSL minifier
Batch 3: Added seeding options, fixed Vite more, fixed color_rgba, added more types to start sending keyboard data, actually fixed ColorRGBA
Batch 4: Added robust player and keyboard logic, in-place scratch buffer reallocation, connected tick() code between WASM and JS, better type generation

Basically, the way the keyboard logic (inputManager.ts) works is it maps multiple keys (such as W, Space, Up all to “up”) to one direction. It also has an advanced system for Simultaneous Opposing Cardinal Directions. If you press LEFT, then RIGHT, then lift RIGHT but LEFT is still held down the LEFT key remains. This code also does all of that with advanced bitmasking to get sent to Zig.

For the scratch buffer logic, I have a run_scratch_allocation_tests() function that tests scratch buffer expansion strategies in zig/memory.zig. The scratch buffer starts off at 256KiB but may in-place memory copy, saving precious WASM memory resources. I’ll never have to worry about data transfer again.

I also finally got camera panning working in the final version! (Not really a screenshot, so not shown in attachment). Attachments show:

1. the log of keyboard bits (which are powers of two) working per-frame
2. a screen-shot of the (dynamically generated!) enums.ts code on the left, which is starting to really pay off; it generates the memory addresses automatically between Zig and TypeScript! quite proud of this one
3. my notes in Obsidian (great app for planning!)

Since the camera logic works and base logic is set in-stone, I’ve learned a LOT about Zig, how to make an actually robust program, and can hopefully enjoy the documentation I set for myself later on. (This is more fun than just using Godot/Unity, right??)

Removed optimized float mode (as it’s not needed for this game), added proper buffer string reading/writing, changed seeding algorithm, improved enum auto-generation, and did a bunch of other changes!

From the first attachment, you can now see that there are plenty of new properties, including more exports! I should be able to implement the command system fairly easily by just giving some data for SCRATCH_INFO_VIEW through an enum.
The second attachment shows the dynamically generated enum file from Zig! Zig is awesome :)

Made comments more consistent, fixed Zig export location, made zoom property and added aspect ratio enforcement! As you can see from the image, the Canvas is now “logically” 480x270 but shaders still work with higher resolutions and factor in devicePixelRatio.
Should be able to start working on implementing a command buffer to communicate between TypeScript and Zig, camera, drawing test player, and having Zig generate some test tile data next.

Worked on getting WGSL working and planned out my next steps for this project! (See second attachment)

Fixed some issues where the UI would sporadically break that had been bothering me for a while now. Project should finally be stable enough.

Shown in screenshot: also learned PvZ Gardendless works on Chromium now and started playing it a lot! There’s a lot of peak things you can easily do with RuntimeFS.

Added more functions and started working on memory management! Really getting the hang of Zig now, gonna tackle getting to know WebGPU well next :)

Finally finished getting Zig to properly log things with stack traces, and got the hang of what I’m doing :D (Yes, this took 5 hours.)
Trying an approach with this project where everything is clearly documented to minimize technical debt. It’s now time for me to implement pixel art rendering with BMP files!

Performed even more fixes and added a new clearData feature to LittleExport! Also got rid of onsuccess entirely in favor of…just returning the blob from await? (Not sure how I didn’t think of that lol)

Next I’ll hopefully be able to start working on implementing StreamSaver to LittleExport to allow non-Chromium browsers to still export large amounts of data (and not be stuck with just being able to import).

Just applied even more changes; now the logs from outputting are finally fully fixed with no funny numbers! Also fixed some edge cases in LittleExport. I think this project might finally be fully complete :D

[Attached: README shows just how many options there are with LittleExport!]

Added a bunch of new stuff!

• LittleExport now uses PAX (still USTAR) to allow for huge file sizes and unlimited file name sizes
• Fixed more RAM-consuming issues
• Improved performance of CBOR for importing/exporting by using custom cbor-x flags
• Made file uploading better and faster
• Made logs and errors more consistent across the codebase
• Fixed a few crashes

Attached image shows a small portion of the in-house result of unsafeObjectToReadableJS, an optional new way to “encode” instead of using CBOR. It literally converts a complex JS object into an async function string generator, while supporting many sophisticated types.
This makes data such as from IndexedDB much more readable; see documentation here: https://github.com/plasma4/LittleExport

First devlog for Magix :D
Basically, fixed a few bugs involving certain trial Seraphins being inaccurate, resolved a mod loading bug among other things (https://github.com/plasma4/magix-fix/issues/18), fixed a bug where pressing Use Magix twice would break things and removed some old logic.

Not included in dev time, but I had some communication with the rest of our small dev team on next steps.

Attached image: did you know this project has documentation? Yeah! Check it out at https://github.com/plasma4/magix-fix/blob/main/DOCS.md (there’s so much the Basics alone take up most of the screenshot lol)

So much new stuff!
I redesigned the homepage, made sure Cloudflare Fonts was working, and started work on some incomplete (yet-to-be-published) blogs. Also figured out how to get Prism working, which renders code, and made the blog look better by capping the width of the text. (The blog will primarily focus on programming-related topics!)

Note: since I’m using submodules, a significant chunk of the commits were at this link: http://github.com/plasma4/my-site

You can see what I specifically did with the clock game here: https://galaxy.click/play/315
Attached is the sneak-peek to the new blog post I’m making. Hopefully it’ll be done soon; also planning another one :)

A few small cleanup changes here and there; MB is now 1000000 instead of 2^20, added per-file logging, and fixed a few sources of crashes.

[Attached image: you can explore the exported data and even upload files from the rfs/ folder back into RuntimeFS! This acts as a cheeky way to let you mess around with files and extract lost data. Exporting data effectively acts as a snapshot back in time, and it’s really interesting to see all the local data you’ve built up over time.]

The features work now, and everything is quite performant! I think I’m basically done with the project. See the LittleExport repo at https://github.com/plasma4/LittleExport

Uploaded is an example of what you can do with RuntimeFS; I got terraria-wasm working with custom headers.

Just fixed some issues with performance when importing a large .enc file in the GBs! Now, it’s time for me to tackle recursive crawling for LittleExport. The idea is to allow users of LittleExport, one of the components of RuntimeFS, to be able to more specifically choose what to export, all in a performant and unified manner.
Image attached shows the basic gist of things.

I’ll eventually add this to RuntimeFS to allow users to choose what to export (and maybe import), live with the async functionality, and also object presets to allow people to “export” their previous choices. This way, I don’t have to send 3GBs of data of my Terraria-WASM and other games every single time!

Fixed drag-and-drop and made errors more consistent (so now they’ll use the same logging system, and will all reset the UI).

Did a bunch of stuff!
Changed UI to use a more chill blue-ish theme to be easier on the eyes
Improved performance of a bunch of things, like exporting, importing, adding new folders
Fixed a bunch of failing edge cases
Documentation is a little more clear now
Also added hiding of non-supported buttons for some browsers and added a new feature to the plugin tool to clear the cache directly

Just fixed a few edge case bugs with the code, improved performance, and cleaned up the code in general. No longer crashes when exporting!

Also made regex replacement MUCH easier for scripts by adding a custom {{SCRIPT}} text option, which automatically inserts at intelligently at the start of head, body, or HTML.

• Made a simple homepage to show my projects
• Got my page published on Cloudflare and made image for my /projects page (not included in devlog time)
• Worked on polishing up some button issues in the Simulation miniproject
• Polished up some issues and fixed some CORS headers weirdness on FractalSky
  Next I’ll probably improve the projects page some more or add a ServiceWorker for sustained offline functionality.