Protip: always account for endianness when using a library that does hardware access, like SDL or OpenGL :/

I spent an hour trying to figure out why the fucking renderer was rendering everything in shades of pink instead of white -_-

(It actually looked kinda pretty, though...)

I'd used the pixel format corresponding to the wrong endianness, so the GPU was getting data in the wrong order.

(For those interested: use SDL_PIXELFORMAT_RGBA32 as the pixel type, not the more "obvious" SDL_PIXELFORMAT_RGBA8888 when making a custom streaming SDL_Texture)

(Warning: This rant includes nonsense, nightposting, unstructured thoughts, a dissenting opinion, and a purposeless, stupid joke in the beginning. Reader discretion is advised.)

honestly the whole "ARM solves every x86 problem!" thing doesn't seem to work out in my head:

- Not all ARM chips are the same, nor are they perfectly compatible with each other. This could lead to issues for consumers, for developers or both. There are toolchains that work with almost all of them... though endianness is still an issue, and you KNOW there's not gonna be an enforced standard. (These toolchains also don't do the best job on optimization.)

- ARM has a lot of interesting features. Not a lot of them have been rigorously checked for security, as they aren't as common as x86 CPUs. That's a nightmare on its own.

- ARM or Thumb? I can already see some large company is going to INSIST AND ENFORCE everything used internally to 100% be a specific mode for some bullshit reason. That's already not fun on a higher level, i.e. what software can be used for dev work, etc.

- Backwards compatibility. Most companies either over-embrace change and nothing is guaranteed to work at any given time, or become so set in their ways they're still pulling Amigas and 386 machines out of their teeth to this day. The latter seems to be a larger portion of companies from what I see when people have issues working with said company, so x86 carryover is going to be required that is both relatively flawless AND fairly fast, which isn't really doable.

- The awkward adjustment period. Dear fuck, if you thought early UEFI and GPT implementations were rough, how do you think changing the hardware model will go? We don't even have a standard for the new model yet! What will we keep? What will we replace? What ARM version will we use? All the hardware we use is so dependent on knowing exactly what other hardware will do that changing out the processor has a high likelihood of not being enough.

I'm just waiting for another clusterfuck of multiple non-standard branching sets of PCs to happen over this. I know it has a decent chance of happening, we can't follow standards very well even now, and it's been 30+ years since they were widely accepted.

Today I had a co-worker ask how we can set a value in the registry since this other program we are working with encrypts it. My response was, "It isn't encrypted, it is little-endian." Then I went into the whole endianness topic. After finally telling him how to convert the hex values in the registry back to the original decimal value that the program is storing, he said, "I'll just take your word for it."

One little two little three little endian
Four little five little six little endian
Seven little eight little nine little endian
Ten little endian bytes

One word: $0024.