Depthwell

[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)

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!