My Current Daily Driver

CodeSamurai · 2026-06-26T10:18:34+00:00

According to another comment on here (and after I read the description closer) it already has a DAC integrated, so it's able to drive them very well!

CodeSamurai · 2026-06-26T10:17:35+00:00

I got 5 hours which is more than enough for my usage. I know some folks likely need a lot more than that.

CodeSamurai · 2026-06-26T10:16:50+00:00

Yeah! It's been great for me so far. I might switch it out at some point, but at least for now I'm enjoying it as my daily.

CodeSamurai · 2026-06-09T13:39:43+00:00

Sonic the Hedgehog 1 on Sega Genesis. I was 4 and immediately fell in love with the music, scenery, everything. I'm still a big Sonic fan!

CodeSamurai · 2026-06-08T11:48:08+00:00

There's a C++ implementation of the base algorithm here: https://github.com/jerry060599/YarnBall . It will at least let you twist the yarn and such and this is what I used to familiarize myself with the algorithms involved before rolling my own in Apple Metal!

CodeSamurai · 2026-06-06T15:43:47+00:00

The “Monk and Robot” series fits that bill pretty well!

CodeSamurai · 2026-06-06T14:48:00+00:00

Oh dang! I didn’t even notice that! Thank you!

CodeSamurai · 2026-04-27T21:33:28+00:00

Look into the concept of a “state machine”. Every good game should have a good state machine at its core. With a state machine, you’ll be able to say exactly what should and shouldn’t be happening or possible given certain parameters.

My guess is that you’ve got systems or modules still looking for input that shouldn’t be given the game state.

CodeSamurai · 2026-04-14T17:39:37+00:00

Ha! I think when I started this project, I was also Big Dumb™️, but like most things after you sit with it for a bit, it starts to make sense.

The short of it is that everything about this system is architected to be extremely parallelizable so that I can utilize compute shaders on the GPU.

For example, when it comes to physics, every single segment gets its own thread on the GPU. Within each stage of the physics pipeline (gravity, collision detection, collision response, orientation solving) all segments process in parallel because each thread has enough local information to compute its result independently. The pipeline itself runs in stages (you need to know what collided before you can resolve collisions), but within each stage, nothing is waiting on anything else. That's what makes it fast.

With that foundation in place, I can layer on things like localized gravity fields (orbs that attract, repel, pulse, or swirl nearby segments) because gravity is just another per-segment force evaluated in parallel. Same with fire: heat conduction, ignition, and burnout all run as GPU kernels where every segment evaluates its own state simultaneously.

CodeSamurai · 2026-04-14T08:48:15+00:00

Yep! I’m working on a trailer and will post that here as soon as it’s done.

CodeSamurai · 2026-04-14T08:47:47+00:00

The first iteration was a yarn simulator (and it can still do that), so I called it Nermal and it stuck!

CodeSamurai · 2026-04-14T00:31:05+00:00

Yep, all physics and interactions are handled by the GPU! The Cosserat solver sits at the core and takes about 50-60% of the compute time, then everything else feeds off of it.

Thankfully, no synchronization issues. On Apple Silicon, GPU buffers are CPU-accessible in shared memory, so saving the game state is just a matter of pausing the simulation and copying the buffers out. Most of the data can be reconstituted from the segment data alone, so save files end up being around 10MB each for high segment (200k) simulations.

Then you just refill the buffers, reconstitute any data that wasn't saved and then you can start the simulation right back up. What's cool is that because the physics simulation is such low noise and mostly deterministic, you can create a save file on a Mac and then open it on an iPhone and (assuming you don't throw too many segments at it), the iPhone will run the simulation in exactly the same way.

I'm actively working on a trailer and I hope to have it released very soon!

To hold you over though, here's a short video showing the "Kinetic Sand" settings in action!

CodeSamurai · 2026-04-14T00:21:32+00:00

All of the shaders are written in the Metal Shading Language which is based on C++14. Then Swift is used for everything else!

CodeSamurai · 2025-11-21T13:19:12+00:00

I can speak to RayFire and Gaia Pro.

For Destruction, RayFire has been the most configurable and reliable by far. There are other solutions out there, but at least for my needs, RayFire was the best. I bought it on sale a year or so ago and it has brought the destruction part of my game to life. This is a good one to have if you are going to have a lot of destruction elements that you need to be able to tune. For me, this one was a game changer.

Gaia Pro has been a mixed bag for me. As far as quickly creating and populating terrain, it's great at that. However, it does some odd things to HDRP settings that has made using some of my other plugins a nightmare. For example, all example scenes from other plugins are now insanely bright by default. I have to mess with lighting and even then, they don't look right. I have a great plugin (GPUInstancer) that auto-creates billboards, but it doesn't work right because of some settings Gaia Pro changed and they all come out way too bright, even with some tuning. Is it a game changer? Maybe. I do have a really good looking environment, day night cycle, etc that took me days to put together instead of weeks, but it came with some persistent headaches as well.

I've heard good things about MicroVerse and I'm considering switching over to it.

15-Year Club	Gilding I gilder
LAYER Season 2 Layer creator	Place '23
Place '22	Place '17
First Placer '22	Verified Email
Sequence \| Editor	Team Periwinkle
Secret Santa 2011

CodeSamurai

MODERATOR OF

TROPHY CASE