J0eCool's Blog

[somie]

New Noelle

[vexheart]

This

[jaggedspine]

i'm going insane

[seaphine]

i‘ve been called weird, but never unfunny, let that sink in.

[nothingdoingcomic]

Nothing Doing no. 64

[j0ecool]

manic episodes be like: errybody's gotta know how I wipe (god said)

[lara-cherriinie]

it’s a beautiful day to ominously wingman for your unwilling vessel

[goomyloid]

kris

[lavenderpanic]

all of my writing is actually just thinly-veiled fantasy about being seen at your worst and still being loved

[j-h-cubedman]

Safety First

Bonus:

[j0ecool]

The facial expressions here are so, so goddamn good

[insomnimelodies]

fuck it, skitter miku

[j0ecool]

I add tests for the builder logic. This means I need to add builder.h to the build logic for the test runner. This means I need to redesign my builder to avoid needing to maintain three seperate builds, one for the kernel, one for the game dylib, and one for the tests

While we're at it it would be nice to set the builder up in such a way that it can itself hot-reload, which feels like an unsolvable bootstrapping problem??

I guess I can move the build logic into a data file, which can reload without needing a code update, and that covers everything sane I could do with a hot-reloading code-rebuilder

Yo dawg, I herd u like infrastructure, so imma need better infrastructure before I can work on improving this infrastructure

[j0ecool]

When you're making a game engine, there's a tradeoff when it comes to working on dev quality-of-life features vs game-facing features.

A factor I don't usually see discussed is the project's PITA Budget. It may take more swe-hours to implement a shortcut that saves 5 seconds at a time than it will ever pay back, but the qualitative difference in working without that 5s annoyance reduces the mental-strain cost of continuing to work on the project at all. As a motivation-bottlenecked solo dev, having good tools not only makes asset creation more efficient, but effectively gives you more hours in the month to work with.

today's small thing is interpreting a UI Label of just "\n" to be a shortcut for a linefeed, which lets us change this from

to

cutting lines-of-code in half

It's the sort of thing that makes actually* zero difference in the finished product, but it makes the daily life of being a game developer fractionally less frustrating, so that's satisfying.

*: If compilers can optimize across strcmp, which I strongly suspect they can, then they would literally compile into the same code

For funsies (because I'm stoned) let's pretend we're compiler engineers again. Why should this be optimizable? ui.labels() is a variadic template function that emits one call to ui.label() per argument, which has overloads for each type. the const char* overload has a clause at the top of it:

With inlining, we would get if (strcmp("\n", "\n") == 0), which a human programmer can clearly see is always true. Can compilers? Well, given that strcmp is a C Standard Library function, compilers are free to make special assumptions about how they work that may not be obvious from the type signature. We also would not be able to inline strcmp, because it's compiled separately (unless you're building your own libc from source, or if your libc ships bitcode which would be weird)

Anyway! So it stands to reason that some enterprising young lad may have realized that they can save 0.2ms on some benchmark by constant-folding strcmps, or by precomputing string manipulations, or whatever. How can we check? Godbolt.

Sure enough, even at -O1 clang is able to constant-fold the strcmps and turn test("foo") into just doSomethingElse()

This ramble didn't really have much of a point. C++ is a language built around zero-cost abstractions. There's something really satisfying about knowing enough about how the optimizer works, and what the language's semantics are, including its cost model, and thus being able to reason about what will actually get optimized away in practice.

[j0ecool]

gradients

[j0ecool]

gradients

so now i've got it set up so it lerps between two arbitrary colors

this is far less dramatic than the patterns we would see previously, but that's because that was using a 3-color gradient, blue-black-red

I'm excited to mess around with arbitrary-number-of-colors gradients, but not excited about the hacky UIs I'll need to make along the way

(I guess I could use the same colors as the hardcoded 3color version for a better apples-to-apples comparison huh)

[j0ecool]

There we go

it is a pain in the butt to use but oo shiny pretty colors

we're basically doing the same thing as a Gradient Map (pictured: Krita's version), which is a more direct way to manipulate the relevant data, but this works as a v0 because we have (awkward) access to all the bits (and bytes)

[j0ecool]

simple black-blue-white gradient

greebly

here's an example of intentionally using lower resolution to imply details/texture

vs the high-res version is clearly kinda nonsense

and now to get dirty

this is pretty much pushing the limits of what can be done with one single gradient map alone

zoomed out + params (8 colors! that's probably too many!)

so the next steps for generating things would be generating multiple noise maps and combining them. We can use thresholding, multiplication/masking, and different noise resolutions in order to make more coherent generated features

finally, stars

[j0ecool]

gradients

so now i've got it set up so it lerps between two arbitrary colors

this is far less dramatic than the patterns we would see previously, but that's because that was using a 3-color gradient, blue-black-red

I'm excited to mess around with arbitrary-number-of-colors gradients, but not excited about the hacky UIs I'll need to make along the way

(I guess I could use the same colors as the hardcoded 3color version for a better apples-to-apples comparison huh)

[j0ecool]

There we go

it is a pain in the butt to use but oo shiny pretty colors

we're basically doing the same thing as a Gradient Map (pictured: Krita's version), which is a more direct way to manipulate the relevant data, but this works as a v0 because we have (awkward) access to all the bits (and bytes)

[j0ecool]

gradients

so now i've got it set up so it lerps between two arbitrary colors

this is far less dramatic than the patterns we would see previously, but that's because that was using a 3-color gradient, blue-black-red

I'm excited to mess around with arbitrary-number-of-colors gradients, but not excited about the hacky UIs I'll need to make along the way

(I guess I could use the same colors as the hardcoded 3color version for a better apples-to-apples comparison huh)

[j0ecool]

quick UI update

I finally added some sliders and visually this is way more effective than I was expecting

specifically the decision to try just drawing a box outline instead of a filled in rect for the range indicator; I wasn't expecting much but it actually looks kinda competent? in stark contrast to the rest of it

the rendering code is super straightforward

the update code is less so, and I don't feel like going into it in any detail

I also took the liberty of aligning everything, which was dummy-simple

... though getting the text right-aligned was less automatic than I'd prefer (for now)

it's nice to have features built-in, so you can say text.alignment = RightAlign and have that more clearly communicate your intent (plus not having to think about how to write or read a math expression can be a boon), but being able to just cobble something together with a minimum spanning set of functionality is important for Good Enough engineering