Probably not, but it sounds cool and is a Minecraft reference.
Anyway, as you can see, I (sadly along with the help of an LLM, since I’m not the best at physics (i promise I only used it to explain the physics part and fix some insanely weird bugs)) implemented the collision system.
So, to achieve this and not make my computer burn down, I used a spatial grid. The way this one worked is:
I probably won’t finish this during stardance, but I’ll add some mouse interactions so the simulation isn’t so stagnant, and that should probably be it.
In the attachments you’ve got a simulation of 2,000 and 100,000 particles, and a screenshot of the final result.
Just a regular burger now, though.
As you can see, the particles are there. And there’s many of them. Three thousand if I remember correctly. I can’t lie, implementing this took a lot and made me experiment with a lot of new things and especially modern Vulkan.
So, in my last devlog I said that the particles were in memory. They in fact were not, because my compute invocation was broken. But as you might imagine by now, I fixed that. What was wrong is that I was calling vkDispatch(cb, [actual number of dispatches], 0, 0). Since x * 0 * 0 = 0, the total number of calls was, you guessed it - zero. Changed it to vkDispatch(..., 1, 1) and it worked like a charm. Then I had issues with displaying the stuff (passing uninitialized values to the shaders), and also making the particles round. Overall, a nice challenging part of the project.
Yup. Despite working on this devlog for about 9 hours, I’ve made no visible progress. There’s still no window displaying anything (there is one on traditional DEs, but it won’t work on Hyprland for some unknown reason). However, it’s not as simple as it sounds, since I had to be working on something, right? Right. That thing being the base for the particle simulation – The compute pipeline, the compute shader, the compute everything. Additionally, I’ve finished the renderer init. Now the program launches without any issues! Somehow. Lol. The obvious next step is to actually get something rendering, and since the particles, or at least potential particles should be in their SSBO by now, I think I should be able to make a humble hundred-thousand-vertex draw call and be good! In theory, of course. How it will turn out in practice, we will see. And because as I said, I don’t have any visual output yet, you can have another picture of the terminal output as a treat.
This was supposed to be covered a separate devlog, however posting the devlog failed and I simply gave up. Anyhow, I set up the project in quite a simple way, hoping to minimize the amount of bloat in the vendor directory. The project uses C++, Vulkan (my two beloved technologies) and CMake, which is a first for me.
So far, I’ve made use of GLFW to create a window and then used Vulkan to create a window surface and prepare the swapchain. What the swapchain in plain terms is that it makes sure you dont have to wait for the next frame to be rendered with a blank screen.
The next obvious step would be a graphics pipeline, however this time I’m thinking of going straight into rendering particles instead of the regular triangle. That would require a different (possibly instanced) .
graphics pipeline, more sophisticated shaders and of course, a compute pipeline, learning which is the very point of this project.
-# ignore assert failed please
I worked on creating the server itself, making it work correctly. To do this, I used the <arpa/inet.h> header. This is my first time doing anything like this, I’ve never messed around with servers and such. The trickiest part was definitely setting up the firewall, since the site did not work on other devices. Serving different MIME types without hardcoding wasn’t the easiest either. Despite that, I really enjoyed doing this, and I’m sure that once I get the ollama API linked using curl, this will surely be a great project to put on my Resume.
Being fair, it was quite simple once I actually understood the math, which was the hard part.
All it took was scaling unit circle coordinates (which are sin theta, cos theta) by the radius and translating them by the center. Another difficult thing was figuring out how to correctly scale the objects, but I achieved that by scrapping pixel-normallized conversions and changing the entire coordinate system into a pixel-based one (for the scene at least).
A small tweak of how the objects are structured, I added the ke::nodes::UserObject to encapsulate shared behaviour between Node2D and Node3D, without passing said behaviour onto SystemObjects. Such behaviour is, for example: Drawing to the screen.
First devlog here, gonna recap what I’ve done after flavortown ended.
Mainly, I created an object hierarchy and a tree-based object structure. This allows for easy displaying and manipulating said objects in the future, and the inheritance covers common behaviours of the classes. This is the first game engine-specific feature I’ve added and will allow the user to interact with the scene more independently rather than me having to add specific ways for them to do so. This project is building upon what I built during Flavortown, and I’m glad I can share what I’m working on again.