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 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
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
So apparently changing the href attribute of a link means that the website has to request for the css file and wait while the component is loaded instantly causing FOUC
So I just copy pasted every css file into the header so the stylesheets are always loaded. And to retain the ability to just id an element as “sidebar” without worrying about conflicts I just wrapped every stylesheet with the id of the main element.
I was also optimizing bit unpacking and casting position and restructuring layouts. I swear I didn’t spend all 5 hours just writing 20 lines of code.
Simple readjustment of the velocity precision.
Previously the smallest value of the 10-bit float, we’re not going to implement subnormal values, accumulates to shift entities when idle.
Wow I spent eternity making 10 boxes.
And still tsx doesn’t like that I imported a png file, I should Google that up one day.
Menu expands with little code.
I’m going to run out of functional UI to work on and eventually will have to either fix the aesthetics or make the physics engine.
I’ve been avoiding debugging WGSL learning Solid JS. Incredible UI design I know thank you :)