iiinova — where your digital self keeps evolving

So at the start of the simulation tick, I add the particles to the main simulation, but mark them as changed so they don't move. Other pixels and the rest of the game can interact with them, and at the end of the tick I take them back out and do their simulation separately.

0172

GitHub - PieKing1215/FallingSandEngine: Experimental 2D falling sand engine written in Rust

I took some inspiration from this repo I found recently, because it implements a bunch of fun stuff: github.com/PieKing1215/... In particular, the realization that not everything has to be in the main falling sand simulation, but that I can put things in and out temporarily as needed.

github.com

Experimental 2D falling sand engine written in Rust - PieKing1215/FallingSandEngine

1152

The tank already had a sort of gliding interaction due to how it placed materials in the world, but that was rather unintentional. There is now a new particle system for terrain that allows pixels to fly around with velocity, which makes the shooting possible!

1131

Chunie @chunie.bsky.social · 02/10/2026

New mechanic for the fluid tank. It's a jetpack!

2985

I added a secret to the game. One is enough, I think.

1793

The player is a mouse, so it makes sense that everything else is bigger.

0182

Here you can see the actual simulation pixel size. Noita simulates an area of 512x512x4 around the player at once, which is the same size as the entire map of this game.

1412

Yeah, pretty much. I might have already paid for the 1024 size with 768 internally anyway. Even on the CPU it's better, because I can make faster lookups with bit shifting (which I already do for chunks).

232

As much as I'd like to have a variable map size or even a dynamically loading huge world, I don't think that's in the cards anytime soon. Maybe some day.

1112

Chunie @chunie.bsky.social · 29/09/2026

I'm increasing the map size from 768 to 1024. 768 is a bad size for textures, and it would be nice to have a little more room to breathe. All I have to do now is change all the little magic numbers that assume a 768 size.

3612

Reposted by Chunie

Sunbathing! www.patreon.com/chunie/posts... subscribestar.art/posts/2676512

262144

Chunie @chunie.bsky.social · 29/09/2026

Sunbathing! www.patreon.com/chunie/posts... subscribestar.art/posts/2676512

262144

Chunie @chunie.bsky.social · 27/09/2026

Now, the building checks if the material has room in the destination, then sets up a transfer packet with its own timer internally. If that is finished, the actual transfer happens. The animation is then just based on that packet, without any actual projectile movement.

0211

Chunie @chunie.bsky.social · 27/09/2026

Previously you put put a material into a stash, and it would transfer instantly to the end, then start the internal cooldown and play the pipe animation after the fact. That was sort of okay when the pipes were opaque, but if you can see what's in them it just looks bad.

1211

Chunie @chunie.bsky.social · 27/09/2026

You can now properly see materials going through pipes, rather than it being faked (it's only half-fake). If a transfer is cancelled in the middle for some reason, you even see them coming back.

21027

Not at the moment, but I might add them.

021

If I comment out my own fullscreen code and mash Alt + Enter, it still sometimes sets itself to fullscreen at the wrong resolution. Awesome, consistent and very desirable behavior.

0141

And it isn't native fullscreen resolution either. It sets your resolution to the size of the window.

1111

Okay, so the trick is to make the borderless fullscreen window one pixel higher than the screen size, or something somewhere decides to force you into exclusive fullscreen one in ten times at random. Very cool.

171

Wait, it doesn't do it anymore randomly? That's not good at all.

171

Now how do I disable this if I'm in OpenGL...

191

Oh, the DXGI Swapchain steals the Alt + Enter shortcut, which breaks my borderless window toggle and replaces it with a fullscreen mode that doesn't work. That's nice.

2492

Now that I think about it, maybe that can be extended after all...

0211

*scuffed. What I'm doing is replace the water with an electrified water material, which replaces surrounding water with electrified water as long as it has a different lightning id that is assigned per frame (so it doesn't roll forever).

1221

Lightning can electrify water and hurt you. It's scruffed and not extensible the way I'm doing it, but maybe it doesn't have to be.

1953

This replaces the earlier rain where I just spawned a water pixel at the top and had it fall down. Now there are rain particles that have a chance to spawn a material when they hit the ground, which is much easier to control and has more consistent performance.

0191