Right now the debug lib draws a little HUD that's two lines, but that takes up more screen real-estate than I would like.

Change it such that all the info is on a single line.

It's not obvious what the controls for the game are, so we should add a modal that defaults to displayed, and lets the user know what they can do.

I've tested with a few different MESA versions and they're unilaterally varying degrees of broken. Some almost work properly, some get a black screen, I've even had reports of system hangs and instability.

I'm not sure if the cause is driver bugs, application bugs, or ..

It would be nice if this loaded a simple model and drew some "hello world" text to the screen .. just so the user knows it's working. Right now it's almost a totally blank screen, which (to me at least) smells like it's broken.

Right now the debug HUD buttons (when you hit F1) are large, and not obviously buttons.

I'd prefer if they had less padding, and maybe a border.

This is how much code the Error macro produces:

More concerning is Assert, which is similar. This is contributing a sizable amount of bloat to the builds which we should avoid.

I'm actually not sure why the heck I made them macros in the first place .. should probably just replace them with some variadic functions and a single FormatString call

https://learn.microsoft.com/en-us/windows/win32/sysinfo/acquiring-high-resolution-time-stamps

Right now all geometry pushed into the 3d immediate buffers are in camera space (called render space in the code), but that has some problems. Namely, the camera has to be updated before any of that geometry gets pushed. While this was a servicable approach for quite some time, there is a new constraint that the camera must be updated after the UI is drawn (to avoid a frame of camera jank when the UI captures input), which means there is now a frame of UI jank on the immediate geometry that the UI draws (things like the highlighted voxel, selection region, etc). The solution to this is using camera-independent coordinates in the immediate buffer, then transforming into camera space in the shader, like a real program.

i am on Arch linux(endeavour os)

command used :

Archlinux

sudo pacman -S freeglut libx11

Common

git clone --recursive https://github.com/jjbandit/bonsai bonsai && cd bonsai
./scripts/make.sh

cmd logs :

[iamacat@iamacat-ms7c89 bonsai]$ git clone --recursive https://github.com/jjbandit/bonsai bonsai && cd bonsai
./scripts/make.sh
Clonage dans 'bonsai'...
remote: Enumerating objects: 24300, done.
remote: Counting objects: 100% (7399/7399), done.
remote: Compressing objects: 100% (1920/1920), done.
remote: Total 24300 (delta 5633), reused 7182 (delta 5422), pack-reused 16901
Réception d'objets: 100% (24300/24300), 69.60 Mio | 5.85 Mio/s, fait.
Résolution des deltas: 100% (18038/18038), fait.
Sous-module 'include/bonsai_debug' ([email protected]:scallyw4g/bonsai_debug) enregistré pour le chemin 'include/bonsai_debug'
Sous-module 'include/bonsai_stdlib' ([email protected]:scallyw4g/bonsai_stdlib) enregistré pour le chemin 'include/bonsai_stdlib'
Sous-module 'scripts' ([email protected]:scallyw4g/bonsai_build_scripts) enregistré pour le chemin 'scripts'
Clonage dans '/home/iamacat/bonsai/bonsai/include/bonsai_debug'...
[email protected]: Permission denied (publickey).
fatal : Impossible de lire le dépôt distant.

Veuillez vérifier que vous avez les droits d'accès
et que le dépôt existe.
fatal : le clonage de '[email protected]:scallyw4g/bonsai_debug' dans le chemin de sous-module '/home/iamacat/bonsai/bonsai/include/bonsai_debug' a échoué
Impossible de cloner 'include/bonsai_debug'. Réessai prévu
Clonage dans '/home/iamacat/bonsai/bonsai/include/bonsai_stdlib'...
[email protected]: Permission denied (publickey).
fatal : Impossible de lire le dépôt distant.

Veuillez vérifier que vous avez les droits d'accès
et que le dépôt existe.
fatal : le clonage de '[email protected]:scallyw4g/bonsai_stdlib' dans le chemin de sous-module '/home/iamacat/bonsai/bonsai/include/bonsai_stdlib' a échoué
Impossible de cloner 'include/bonsai_stdlib'. Réessai prévu
Clonage dans '/home/iamacat/bonsai/bonsai/scripts'...
[email protected]: Permission denied (publickey).
fatal : Impossible de lire le dépôt distant.

Veuillez vérifier que vous avez les droits d'accès
et que le dépôt existe.
fatal : le clonage de '[email protected]:scallyw4g/bonsai_build_scripts' dans le chemin de sous-module '/home/iamacat/bonsai/bonsai/scripts' a échoué
Impossible de cloner 'scripts'. Réessai prévu
Clonage dans '/home/iamacat/bonsai/bonsai/include/bonsai_debug'...
[email protected]: Permission denied (publickey).
fatal : Impossible de lire le dépôt distant.

Veuillez vérifier que vous avez les droits d'accès
et que le dépôt existe.
fatal : le clonage de '[email protected]:scallyw4g/bonsai_debug' dans le chemin de sous-module '/home/iamacat/bonsai/bonsai/include/bonsai_debug' a échoué
Impossible de cloner 'include/bonsai_debug' pour la seconde fois, abandon
bash: ./scripts/make.sh: Aucun fichier ou dossier de ce type
[iamacat@iamacat-ms7c89 bonsai]$ 

Windows created with WindowLayoutFlag_StartupSize_InferHeight and WindowLayoutFlag_StartupSize_InferWidth can open a larger window than the screen can fit.

It would be nice if the code that did the window setup stdlib/src/ui/ui.cpp:2366 would be smarter about how large it would make a window. The screen dimensions are accessable through the renderer2d *Group in that function as Group->ScreenDim.

The fix should be as simple as clamping MaxClip to Basis-ScreenDim. For bonus points, there's a global called DefaultWIndowSideOffset .. you could work that in such that there's a nice border between the max edge and the edge of the OS window.

Right now games have to provide an implementation for every thread queue job, most of which are identical across games, and have nothing to do with the game.

We should have a system that provides default implementations of the jobs, and something that lets us override the default .. probably a compile-time #define for each job which users set to 1 if they want to override .. or something like this.

Could probably metaprogram the defines such that we don't have the annoying manual step of going to add that every time we add a new thread job.

This is problematic for the UI sprites, which get pushed onto a global array in the order they're traversed, then indexed by static offests.

The directory traversals should probably return a tree structure of some sort the user can traverse themselves. The trees should be the same across platforms.

It would be very useful to have a streaming datastructure that allocates blocks of elements and, when the current block fills, allocates another block of elements. The blocks either get chained together in a linked list. For example:

<block0 (1024 elements)> -> <block1 (1024 elements)> -> <block2 (1024 elements)> -> null

A better method would be to keep another contiguous buffer that stores the block pointers, and gets re-allocated every time the array resizes. This either requires each "Blocked Array" structure to have it's own arena (not great), or to heap-allocate the contiguous buffers. Unfortunately, the heap implementation in Bonsai is pretty janky. #8

There's already an implementation for this in "include/bonsai_debug/debug.h". Look for debug_context_switch_event_buffer_stream. It's put to use in "include/bonsai_debug/headers/win32_etw.cpp".

The task at hand is to copy-paste that implementation and make it generic (using a void* at first), then metaprogram the implementation using poof.

It would be real nice if shaders supported hot reloading, such that you could edit the shader and the changes appeared.

There is code that creates shaders already. The majority of the work here is to write code that polls the text files for changes and reloads when it detects a .. new timestamp?

I took a crack at a fancy LoD system a while back (which kinda-worked), but it's pretty straight-forward to implement the same meshing algorithm(s) on a coarser LoD of voxels, which would buy us a lot for a little work.

When a window opens that has no content the window's not sized correctly.

A better look would be something like this

The code that handles the minimum size for a window is in stdlib/src/ui/ui.cpp, look for PushWindowStart. At the time of this writing the code is specifically in a block that triggers when the resize handle is pressed on line 1289.

This should be a pretty straight-forward task for someone wanting to get their feet wet doing some graphics programming. I can explain how to do this, and maybe search out some good resources to follow along with during implementation.

The debug windows can currently clip down to a size that produces some visual artifacts. We should fix the logic that clamps the min value to a more sensible value

If you open the textures window and drag it such that it clips against the game window (os window) bounds, the textures warp in a weird way like. IIRC this happens because the UVs are wrong.

Because the actual operation of buffering an AABB is quite cheap, we'll need to pack a lot of the operations together. Doing this amortizes the cost of the worker thread starting up the job, which is also cheap, but not free.

We probably want to go with a two-step approach:

1. Start with creating a thread job that just buffers a single AABB
2. Make a job that packs multiple of those jobs togetherj

There's an example of doing this already; grep for work_queue_entry_copy_buffer_set

Alternatively, we could implement instanced drawing, which is probably what we should actually do..

Right now there's a bug; the grid follows the camera around. I think we need to pass the camera offset relative to the center of the world into the shader and subtract that from whatever we're treating as the origin for the grid.

This should be relatively painless, although it'll require also moving bonsai_worker_thread_callback into stdlib (and probably renaming it to something else).

It would be nice if it were impossible to scroll up/down past the boundaries of the content in windows.

Bonus points for adding a little juice by being able to scroll a little way past the end (or top) and having the scroll lerp back to where the hard-stop would have been, like OSX does.

The code that does the scrolling is in stdlib/src/ui/ui.cpp, UiFrameEnd line 2955

Hi! I was recently recommended your project by GitHub and found it quite astonishing!

I wanted to try it for myself, as I noticed the presence of a default.nix file. However it seems to be quite out of date (last updated about 5 years ago) and only provides a few dependencies. With my curiosity picked, I tried to assemble a very basic derivation that would build the core items of the engine (the game loader, and demo files). Currently, the setup is a bit hacky (for instance i have to cd within the result dir), but here the derivation i made as a proof of concept:

{ stdenv, fetchFromGitHub, clang, which, libGL, xorg }:

stdenv.mkDerivation (finalAttrs: {
  pname = "bonsai-engine";
  version = "1.5.1";

  src = fetchFromGitHub {
    owner = "scallyw4g";
    repo = "bonsai";
    rev = "refs/tags/v${finalAttrs.version}";
    hash = "sha256-hzKmrrYNwBVnkwN/AyoYJMI+2xYZGJ7pl5dYpFfitQA=";
    fetchSubmodules = true;
  };

  nativeBuildInputs = [ clang which xorg.libX11 libGL ];

  prePatch = ''
    patchShebangs .

    substituteInPlace external/bonsai_stdlib/src/initialize.cpp \
      --replace-fail "./bin/lib_debug_system_loadable" "$out/lib/lib_debug_system_loadable"
  '';

  buildPhase = "./make.sh";

  installPhase = ''
    install -Dm 755 ./bin/game_loader $out/bin/game_loader
    install -Dm 755 ./bin/lib_debug_system_loadable.so $out/lib/lib_debug_system_loadable.so

    for lib in \
      blank_project_loadable \
      project_and_level_picker_loadable \
      terrain_gen_loadable \
      the_wanderer_loadable \
      transparency_loadable \
      turn_based_loadable \
      voxel_synthesis_rule_baker_loadable; \
    do
      install -Dm 755 ./bin/game_libs/$lib.so $out/lib/$lib.so
    done

    cp -r shaders $out/shaders
    cp -r assets $out/assets

    cp -r settings.init $out/settings.init

    cp texture_atlas_0.bmp $out/texture_atlas_0.bmp
    cp texture_atlas_1.bmp $out/texture_atlas_1.bmp

    touch $out/.root_marker
  '';
})

Here is a screenshot of the generator, that has been built using from the prototype derivation:

It was wondering if you were interested to improve the nix support (which would take me quite some time to do properly).
I could setup a flake.nix for this repository to provide things like the devShelll, package to build the demo declaratively and more. This could also be the opportunity to port the engine to nixpkgs repository.

A few people have accidentally cloned without --recursive . It would be pretty trivial to check if submodules are initialized and emit a specific error reminding them to initialize submodules

At the moment the radio buttons are a little weird.

They currently don't treat the enum value they're created from as primal. The proof of this is that if you open two windows that read/modify the same value, toggling a radio button in one does not update the other. This is undesired, and actually a bug. Since the underlying enum value is actually modified, the view that doesn't update is stale, and displaying the wrong value!!

Additionally, radio groups don't display the default value (typically zero), as selected, which smells pretty wrong.

The git hooks system is hilariously half-baked so we have to add some gymnastics to the build to actually get the repo hooks onto other peoples' machines

Right now the debug lib menu comes up on F1 click. I also want a set of "engine debug" options to show up under it. The first element in the list should be "Watched Values". We should also move the "Picked Chunks" tab into the engine from the debug lib.

The "Watched Values" tab should show up where the '0' is in this screenshot, below PickedChunks.

There's a GameUiRenderer struct setup on the engine_resources that can be used in the same way that the one in the debug lib is.

There's a

• If a user has an external GPU, but the system isn't setup to prefer it, currently we select the integrated graphics. We should query for available GPUs and select the beefy one.

DONE

• LoadVoxData doesn't make exterior faces on models.
• SpawnEntity crashes if you don't pass it models, but ask for a model

Nearly everything in Bonsai is allocated on an Arena, for which there is a pretty fancy (and bulletproof) implementation. That said, I've started to want a heap in a few places. #7

The task at hand is to improve the test harness for the Heap implementation such that we're relatively confidant it's not buggy (or at least doesn't have any glaringly obvious bugs), so we can start using it in a select few cases.

There's a subtle problem sometimes causing holes in portions of the mesh when the noise values are manipulated conditioned on a mask computed from the normal of the surface.

What a mouthful.

The issue is that the noise values are computed on a grid the same size as the normals, and the resulting voxels. This is a problem because the code that computes faces is required to operate on a grid that is 1 larger than the resultant mesh, and the code that computes normals is required to operate on a grid of noise values that is 1 larger than the resulting normals grid. Said another way, each stage in the pipe requires downsampling the grid size by one.

The problem occurs when indexing into these grids on the chunk edges. The grids are larger than the result grid such that we can deterministically generate the voxels on the 'border' of each neighbouring chunk. If the normals & meshing grids are inflated more than one cell they index into the wrong cells when doing the borders. Most of the time this is fine, because the noise values only change a small amount across a single voxel, but occasionally it causes a problem when one chunk thinks a voxel is filled, and another chunk thinks it's not, causing a hole.

The solution to this problem is pretty simple conceptually; use the meshing grid size as primal, and add one for the noise value grid.

This turns out to be kind of annoying in practice because that code is somewhat scattered across the various generators, so we might have to make this a bit more systemic. I'm going to leave it for now, but wanted to write this down so I don't forget exactly what the problem is.

I've gotten a fair bit of interest in porting to OSX, mostly for developers, so I'm starting an issue to track progress. The branch with porting work is port/darwin.

Shawnecy reported some sparkling black boxes on linux. We investigated for an hour or two but didn't get to the bottom of them. What we found out:

• They appear during the gaussian blur of the bloom texture
• They reduce in frequency quickly on startup, sometimes surging in frequency again for short amounts of time
• It appears they are not caused by an error in the lighting shader calculations
• The only system we've seen them repro on is his; a 4090 on driver (IIRC 515.something) ( the screenshot he sent disappeared in discord)

• rendering mesh thumbnails crash (need to move the gfx code to render thread)
• 2d transparency in turn_based (on skill icons) is busted on hover
• Entities have grid drawn on them
• Move source directory for levels in-tree
• voxel_synthesis_rule_baker crashes
• linux doesn't build
• splosions don't work :sadge:
• shadow mapping precision issue because of position reconstruction from depth

DONE

• Weird latent bug that fucks with the frame ticker (frame time gets set to a massively large negative value??