(the very first)

Welcome to the first ever episode of the weekly...


That's right! This is a brand new weekly podcast for people who support me on patreon, substack, and liberapay.

It's my way of telling you what your money has been going towards.

Every week, I'll share all the goings-on from behind-the-scenes, however big or small they are. There may or may not be some interesting stories along the way too.

The more observant of you may realise that I've been doing this for 52 weeks already (EDIT: Wow one whole year!?). Well... I've renamed it now, so consider this a "re-launch". More info in last week's update.

Let's begin... What's new this week?

120 frames per second

I've been doing a lot of work on Arroost for the next video. It's a silly tool for making silly music.

And now... it has a pulse.

But before we get to that, I have a question to ask you:

How fast is your screen?

I'm not talking about how fast it moves. I'm talking about how quickly it refreshes what it displays.

Right now, I'm looking at a screen that refreshes 60 times each second. 60 frames per second. Or 60fps. But sometimes, I use a screen that refreshes 120 times each second. 120fps.

So, what about you? How fast is your screen?

Let's say that I wanted to display something on your screen. Let's say that I wanted it to be animated.

To use the full capabilities of your screen, I'd need to send it new images at the right speed. If it's 60fps, I have approximately 16 milliseconds to send it each new frame. If I'm too slow, I'll miss some frames, and my animation will look slow and stuttery (compared to the other things on your screen).

If your screen is 120fps, I have even less time - about 8ms! That's not very long. My code has to be quick.

But wait! Do we actually have to be that fast? Maybe it's part of your animation's aesthetic to be a lower framerate. Or maybe running slightly slower is "good enough"

Or maybe... we could split our animation into multiple pieces. The slow parts could run at a slower rate, allowing the faster parts to stay fast.

Many game engines do this. They run certain aesthetic pieces at a higher speed, like the shimmering of water, or the wave of grass in the wind.

Meanwhile, more intensive parts can continue to run at a slower speed. The tricky physics calculations of the underlying engine can run more infrequently. You probably won't notice!

This is how we made Sandspiel run so fast on phones. The main thing slowing them down was the tricky calculations involved in simulating wind, and fluid dynamics. It was blocking the engine from carrying on with its 'other stuff'!

To get around this, we just allow the wind simulation to run at a slower rate. We tell the rest of the engine, "It's ok! I'll catch up later."

So try out on your phone, or slow laptop, and tell me how it goes!

120 beats per minute

What has any of this got to do with Arroost? Is what you might be asking.

Well, Arroost does this to the extreme!

The user-interface runs very smoothly, at 120fps, or as fast as your screen will allow. But the underlying engine runs much slower. By default, it runs 120 times per minute. That's 60 times less often!

This is because it's about music. More specifically, it's about music that's 120bpm (beats per minute). You can modify the speed, but that's more advanced - we'll get to that another day.

So hey, in Arroost, we have LOADS of time to figure out the next frame. 500ms to be precise. This means we have enough time to code some truly massive and magical stuff in between frames. It's gonna be fun!

A final note: Why 120? Why not... 128? or something else?

That's because 120 is a multiple of 60, which is the FPS of all my videos. This makes it easier to do some frame-perfect editing around it.

It's also a multiple of 24 and 30. So if you were to animate a dancing berd, or a trippy surprise sequence at the end, it'll also work well with that!


There's more. This week, I also did a bit of design work on how Arroost looks.

I usually pick colours from a very limited list of choices. This list is my TodePond colour theme! And it includes things like RED, GREEN, GREY, BLACK, and more!

I was using SILVER in Arroost quite a bit, and it... didn't feel right.

It was too cold and dull. It felt a bit lifeless. But GREY was too grey, and I was using it for other stuff... If only there was an extra colour in between GREY and SILVER to serve as a 'slightly brighter grey'...

To solve this problem, I created a new colour, creatively called GREY-SILVER, and I really like how it looks.

As different cells of the engine 'fire', they look a bit like flashing lightbulbs. I like how it feels a bit like a mad scientist's invention.

Also, it was very very important that the middle bit of each cell is the same colour as the background. That very very important reason is...

You see, the very very important thing about them is...

The very very...

Sorry to interrupt. I've just realised that we've reached the end of the episode. If you're listening to this free sneak peak as a non-subscriber, consider signing up to find out more next week.

And if you're a subscriber, thank you so much for your help! Your support helps all of these things to happen.

I'm going to upgrade my video editing setup this week with some of your money. My old one refuses to render any video anymore. It's been on its last legs for a while now. And now, it's given up. But I haven't! And I hope you haven't either! Fun things are afoot. I hope you have a great week.

Days since tode fell asleep: 231 Days since bot went missing: 196

1 Comment
Weekly update about slightly-surreal creative-coding.