Brad Allred

we do have a shader so we could incorporate it there

I highly suspect that using UTF-16 on the Python side won't be viable without this. We would have to write our own function to do the conversion every time we...

As explained in #1516 attempting to juggle multiple encodings is insanity incarnate. there is no reason to do it and its an endless which-a-mole with bugs and needless code and...

> relying on fmtlib I'm not sure this is our preferred solution. It's another dependency and the need to change all of our format strings which is another tedious undertaking....

string theory sounds great, but unfortunately uses uff-8 internally and indeed seems like overkill. one reason to perhaps prefer libfmt is that it is the basis for the string formatting...

> Python's internal representation of Unicode objects is not going be UTF-16 in most cases My cursory research indicated this is controlled by the encoding of the source file. Not...

> Python's internal representation depends on the string's contents, and for our use cases, will typically be ISO-8859-1. The source file encoding doesn't matter. The internal representation of Python strings...

Ryan has added more information to the SDL [discussion board](https://discourse.libsdl.org/t/future-3d-api/33485) it looks like it will be a new API entirely. It may not change my roadmap plans much in the...

that could be potentially very useful. lots of our blending is known to be incorrect (magic missile off the top of my head) and shaders can provide clues at the...

I doubt that setting a uniform variable is actually a bottleneck. likely its caused by the fact that we keep switching programs and the call to `SetUniformValue` is just the...