stardance has been extended another month! the new deadline is october 31 :)

You are browsing as a guest. Sign up (or log in) to start making projects!

Knaj

@Knaj

Joined June 6th, 2026

  • 8Devlogs
  • 3Projects
  • 1Ships
  • 18Votes
I'm a 16 y/o programming student from Poland 🇵🇱
I specialize in desktop apps and games using Vulkan or OpenGL! I firmly believe in C/C++ superiority.
I guess I have the abilities and skills needed to make websites and all, but that's not my cup of tea.
Check out my game engine (HEAVY WIP) Knaj's Game Engine

(i use arch btw)
Ship Pending review

Particle Simulation, semi-finished.

At last I’ve done it, this a mini-dream come true.
I’ve finally “mastered” Vulkan compute shaders and got better at using C++ and GLSL.
The program spawns 2000 particles (a very humble number, so I can run it on almost any machine) and simulates their gravity and collisions.
In my very humble opinion, it’s quite impressive.

  • 4 devlogs
  • 33h
Try project → See source code →
Open comments for this post

7h 41m 19s logged

The end?

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.

What it took

So, to achieve this and not make my computer burn down, I used a spatial grid. The way this one worked is:

  • I added 2 buffers, one for cell heads, and other for next particles
  • Created a linked list using those, with the last one pointing to index -1.
  • Then, using some nonsense calculations, for every particle I checked every particle in their own cell and the 8 surrounding ones. That way I didn’t have to make a literal billion if statements per second.
  • Then I fiddled around with making the particles stop moving on their own, and bim bam boom, I’ve got a nice layer of particles at the bottom.

What’s next?

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.

Attachments

In the attachments you’ve got a simulation of 2,000 and 100,000 particles, and a screenshot of the final result.

2
0
33
Open comments for this post

9h 20m 39s logged

Not a nothingburger anymore!

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.

What it took

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.

0
0
24
Open comments for this post

8h 39m 4s logged

A very big nothingburger.

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.

0
0
149
Open comments for this post

7h 20m 26s logged

Devlog #1

Project Setup

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.

Renderer base

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.

Next Steps

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

0
0
29
Open comments for this post

2h 18m 19s logged

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.

0
0
2
Open comments for this post

35m 59s logged

Objects Render now!

  • Added Circle rendering using unit circle scaling & translation
  • Added Rect rendering by well, generating a rect
  • Changed coordinate system from (-1,-1)-(1,1) to (0,0)-(width, height)
  • Fixed crashing on exit by adding UserObject::Destroy()

How it went

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

0
0
4
Open comments for this post

21m 9s logged

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.

0
0
4
Open comments for this post

25m 57s logged

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.

0
0
4

Followers

Loading…