So remember when last time I thought “oh no how to do private prefix arrays”?

Well, an hour later and I discovered “Oh, my 2^24 entities can be divided by 256 and then 256 again so I’ll just have to do 3 prefix sums layered one on top of each other on the thread level”

I don’t know what happened but my brand new 8 bit radix pass takes 460+ms. Yay

So I’ve hit a brick wall.

gogle told me that to improve my 4 bit radix shader is to do 8 bits at a time to halve the number of passes (and that a byte is industry standard) but I can’t figure out how to like create a private histogram for each of the 256 digits

also I got a 72 on math AS levels :P

Hey guys so I reduced the chunk size so that joints don’t have to hope that there’s at most 16 entities within 16 tiles

Also I was reading the dev time of my other project and I accrued almost 6 hours over the limit, whoops :P

We finished the project yayya

Hello, my team has beena bit busy.

We made live code sharing, ai generating buggy code for the user to debug with friends (although I am rate limited at the moment whoops), and lobbies with codes.

Pretty proud for my first time doing something like this

It’s pretty meditative how relatively frictionless naive backend programming is to naive shader programming.

I remembered how to initalize tauri again

Working with @yaphethstephannatanael for the prometheus competition thing

he thinks im good at coding lol

I made a pool of unmapped buffers so I can continuously record the time taken so I can clearly see how much worse my changes to the algorithm are.

I tried to optimize sorting by reducing the memory footprint of every thread so they could fit more threads.

Mid-bitpacking, I decided to test the pipeline and viola. I’ve doubled execution time.

Also rerolls only add like 10% or less of what you initially rolled. Absolute scams

So by bitpacking I was able to make the array longer while fitting within the shared memory limit.

That means that more threads can work on the kogge stone -> larger workgroup size -> less iterations per thread.

school’s back btw

So the sorting system is taking a bit too long, ah well I’ll figure it out. Google says it’s possible to get it fast enough

So I was trying to visualize the buffer on a helper static website so I can eyedrop data since reading a 16384 length array isn’t efficient

but apparently chromium dropped an update that prevents mouse interactions the moment you use their builtin eyedropper

so here’s my replacement (not what all 8 hours was spent on pls believe me)

So I forgot to add rotations to the collision thing.
Also I got my first ever Device Lost error yay.

No one told me that not posting for over 10 hours will deduct me of my precious work.

Instead of replacing 10,000 characters every frame in 60fps with the performant language JavaScript rendered with the lightweight renderer HTML. I capped it at 20fps on mouse move

some stufff

so collisions taking their sweet time with gjk are seperated and moved to the entities_buffer_meta so the gpu can focus on resolving those stubborn collisions

look, after several parallel friendly paradigms the last step of my code is this sequential and divergent code

Man I made a lot of mistakes earlier whoop.

Anyways here’s a naive implementation of the support function for the gjk algo.

I’m going to move the entity_nodes buffer into shared memory (or at least the collision pair’s colliding mesh nodes into private memory) tomorrow

Yay yesterday’s issue is fixed, in theory.

Man, I haven’t actually like tested any of this code. Should I just print the data from the buffer and eye it or actually try to render it… Cause I’m definitely am going to spend a while getting the render to work in the first place.

I’m almost done with the algo that finds the memory offsets to fit colliding data

but uh, I just realized I don’t have space anymore :)

I think I’m going to revert last update’s progress. fun

After doodling a bit, I decided that the collision handling should deal with 8 collision pairs at a time.

I forgot how to implement kogge stone which we will need and oh boy do I not know where to put the gjk phase. I’m already taking up 0.8 GiB vram at best.

Also, here’s a histogram with nit picking bit packing.

Shuffled buffers around and created a cos sin look up table since entities only have 2^13 possible rotations.

Although I am using a 13-bit floating point for rotation velocity but it’s fine. That’s future me’s specifications to implement