They must've been pressed on time.
They must've been pressed on time.
At that point, the GPU doesn't care if it's overlaying text or something like a barcode. The main priorities would be resilience to image/video compression, and being large enough that you can't just crop it out of screenshots, while not impeding gameplay. Since it's only for the unstable testing builds, why spend more time than necessary implementing it?
Is there something I'm missing about what's wrong with this approach?
Instead of hiding an image of a text in a layer, they could've encoded the text itself (i.e. the ascii values) into the texture. That's trivial to do and doesn't produce visually-discernible artifacts as per above.
They render ID into rasterized text (blocks of pixels) and blend in these blocks. But they could've just as easily rendered raw 0s and 1s of the ID into blocks the exact same way. It just would've not looked like text, but as a random pattern.
But a rasterized text has a lot more information about each character than the raw ASCII values. If you halve the resolution or add compression artifacts an OCR will still pick it up.
If they rendered raw binary data they would have to add lots of redundant information as well as spreading it out over a large enough area. Maybe that's what you meant but didn't fit the 'trivially to do' part for me. Seems a lot easier to just render the text.
It'd be overkill if they were building this feature from the ground up starting with nothing but a string, but they weren't.