Chris Blume

Do you know if videos will be posted?

Got Lempel-Ziv compression working.
Now to combine it with the Huffman from before to get Deflate.

This is how Lempel-Ziv compresses Green Eggs & Ham.
The numbers inside the parentheses are the offset from the start and the length.

(5, 3) is the "Sam" it saw before.
(0, 4) is the "I am".

Also, gross. I uploaded a PNG.

Bluesky decided to recompress as a JPG. Fair enough. I think it is a good idea to do a lossy compression for the human-presentation step.

But it didn't take the image dimensions vs display dimensions into account. Gross artifacts everywhere.

Join us for 3D on the Web on March 11 in San Francisco

Calling all programmers!

Khronos Group is hosting "3D on the Web" -- an evening of talks, demos & networking around #WebGL #WebGPU, #glTF & #Gaussian splats.

March 11 · 5:30-9:30 PM PDT
Easy 12 minute walk from GDC in
San Francisco

Learn more and register […]

[Original post on fosstodon.org]

I feel like that might be a new one for me.

The guy wasn't aware. Few are.
Sounds like the guy in your video also didn't know.

However, I'm curious about California's offset allowance.

I had a guy knock on my door trying to sell a solar install.
He claimed he could get my bill to zero.

I had been researching a bunch and do want solar. So I asked him details.
"Half of my bill is the actual energy. The other half is grid maintenance. In Ohio, you can only offset energy, right?"

It it was my choice and I'm the pilot, 100% "Jesus, take the wheel"

*correction (it was late, I was tired):
This IS a prefix tree. The only nodes with values are leaf nodes.
What I meant is this is kinda right-leaning. See how the bottom right filled up? Typical Huffman implementations are left-leaning.
It doesn't matter--just produces a different bitstream.

*Technically, Huffman trees should be prefix and what I made here is suffix.

It still works the same. But this implementation will produce a different bitstream than the typical Huffman encoder.

Ahh that makes sense.

I still don't love it. :) But it makes sense.

Finally getting around to writing my own compression implementations.

Got a naive Huffman compression going.
Had to take some notes while debugging.
LZ77 next.

Also utf8'X' would have been SO MUCH BETTER than u8'X'.

In any other language, u8 is shorthand for uint8_t.

To clarify a bit:
Originally, prefixes only changed the representation in the code. Suffixes changed only the type.

So there was some logic.

But then u8'X' was added--a prefixes that specify type.

Also, guess how you specify the type uint8_t.
Did you think Xu8? Nope. Maybe u8X? Nope.There is none

I love C++.
But uh...the literal situation is a mess.

0xXXX for hex.
0bXXX for binary. Many similar prefixes.
u8'X' for a unsigned char 8, another prefix.

XXXll for long long. Suffix. Many more.
XXXs for seconds.

XXX_foo for user-defined literals. Gotta use a _.

It could be XXXb for binary...

I'm sure they don't think about it at all,
but it keeps crossing my mind...

I explained to several managers that I was drastically under-leveled. I'm pretty sure they thought I was lying.

Having quit and retired, have they since "huh."?

Next thing might be adding collision? *shrugs* We'll see.

February is almost over. Sit rep:
I added a state machine for the player and am feeding it input. So now there is a "running left" state, for example.

I also cleaned up a bunch of animation code. But I didn't add frame timing yet. So the player's animations are way too fast.

If you're interested when you wake up:

It had already been proposed and debated. And a test change to clang was made. There are some good reasons not to allow it, which I didn't see.
open-std.org/jtc1/sc22/wg...

Thank you, Hana. I genuinely appreciate your help. <3

I think my example of lambdas is weak. It only works when the default initializer is used.

The lambda's type cannot be used outside of that. So nothing could match (without a std::function-style workaround).

So that argument isn't strong. Almost entirely for ease then (barring reflection).

See also this:
bsky.app/profile/prog...

Correct.
And if the default initializer isn't used, the type is still deduced from it.

Fun fact:
You *CAN* do this:

auto baz() { ... }

class Foo { decltype(baz) bar = baz(); }

That is more explicit about what the type is, regardless of the default initializer.
So what I want is the default initializer to be able to instruct 'auto', even when it isn't used.

There are workarounds. You could use std::function instead of a lambda.

But
1.) I don't think we should stop at "workaround" rather than fix the core language restriction. We didn't with function auto return types. And,
2.) Even with the workaround, I don't want to specify the type here.

There is a thing I wish C++ supported. Might be time to finally write a proposal?

class Foo { auto bar_ = baz(); };

We have 'auto' return types for functions. It is a hard requirement if you're returning a templated type involving a lambda.
It is also a hard requirement here.

In WoW there are truffle pigs.
They are idle (state 1) until you summon them over to dig (state 2). Once they arrive, they dig (state 3) and then return (state 4)

At each state, they might get attacked. After the attack, they return to that state. So we need 4 more "attack" states with typical JUMP

Is there a standard name for combining state machines and stacks?

Example in reply. But tl;dr most state transitions are effectively a JUMP. I want to also CALL & RET.

Theeere we go.
Got a player sprite working.

FRIGGIN'...

A triangle wasn't rendering. My default was to check winding order. Seemed the same as others?

I changed the order just in case and it worked!
Fair enough.

But also, the triangle was upside-down.
I forgot DX is -Y down. My winding order would have been correct in -Y up.