@ardenfalls thanks for the feedback! these are definitely very valuable ideas, although I weep at the thought of redesigning the font to be larger haha

@passivestar_ maybe a blind spot during development? because as a user I think you usually just want one or the other, but as an author it makes sense to support both whenever possible.

@FreyaHolmer aha tangent.

@yorube_cj yeah, thanks, it has a few different constraints it tries to solve. Not getting in the way, not being ambiguous, and not moving too erratically. Of course it won't always work in every situation, but it mostly works pretty well and it when it fails, it fails mostly gracefully.

@pmelin @teflorator yeah, I plan on writing with this sort of thing in mind. It doesn't make sense to put any miss-able information exclusively in action situations.

@yuusakumenka yeah text log is a necessity when you play loose with this sort of system, because there's no getting around missing things when it's not the main focus of the gameplay. Well, I don't expect all players to read this sort of text anyways, so it's mostly just bonus characterization

@NajaSide @teflorator yeah, fixed boxes are definitely best for readability, and no matter what style of ui, or timed vs button advance, having a text log is always necessary imo.

@teflorator interesting, I had almost the opposite instinct, that it's easier to read text when it's near the action, and it's ok to miss some of it since the individual lines are not as important as the general vibe.

@FreyaHolmer your freehand straight lines are highly intimidating

@FreyaHolmer I wonder what a CAD tool would do with this geometry, if you tried to bevel it on that selection. bevel generates the same edges as inset right?

@goldenbergdev it does measure how many people think strongly enough that they don't see a compromise though.

(and why?)

@trick_o very cool

thinking some more, the issue with a dark scene is all the information is in the dark range, and the lut transform allocates too much unused space in the bright ranges. But if I could boost the EV of the input and shrink it in the lut, that should effectively reallocate the bits?

@teflorator I don't think so, because the banding comes from linearly interpolating a log-space table, so blue noise won't change that, but maybe I can tweak the sample fractional coordinates to correct for that?

@CJAbra it's linear interpolation, so the banding is "soft". goes away if I implement tricubic interpolation, but that's a lot more samples.

@CJAbra the inputs are in 32-bit floating point linear space, which should be correct, and there's plenty of bits to work with, but the lut is only ~5 bits (32x32x32 cube).