Text Rendering on Hard Mode - Live Coding with C and OpenGL

In this stream, we'll attempt to get text rendering on the screen with TrueType fonts using the FreeType library. This will require me to write code that renders each letter individually using the glyphs from the font. Can we get it working by the end of the stream?

SUPPORT MY WORK:

CHECK OUT THE CODE:

SHOW NOTES:

JOIN THE COMMUNITY:

MY CONFIGURATION:

If you'd like to learn more about Emacs and Guix, check out my other YouTube channel System Crafters!

[halfacanuck]

Interesting vid, thanks. Haven't used FreeType nor OpenGL before; the former looks nice to use, the latter looks like the kind of thing Haskell programmers have nightmares about ;)

Some suggestions:

- Don't bake pointers into typedefs without a really good reason. In fact, don't use typedefs at all without a really good reason. IMO size_t or FluxErrorCode (if you must use camel case ;)) are good uses which increase code clarity and reduce maintenance if the underlying type changes; but FluxWindow isn't, for precisely the reason you saw: it's impossible to know if the type is a pointer or not just by looking at it, and thus easy to screw up things like sizeof. My approach is to use typedefs very rarely, instead typing out "struct flux_window* win" or "enum frankfurter_type fft" or whatever.

- Don't use opaque pointers ("handles") without a really good reason because their storage size isn't known to the (presumed to be dumb) user and they cannot be stack allocated. Stack allocation can be much faster than the heap, depending on system and whatnot. A comment at the top of the file saying "all structures private and subject to change unless noted otherwise" is good enough, imo. Provide a good and complete API to access the structures and no-one will need to dig around inside them, and will have a suitable sense of dread while doing so.

- Why default to int8_t when defining signed fields? It can't store values higher than 127. uint8_t is equally limited, especially these days with laptop screens 80, 000 pixels wide. You ( _maybe_ ) save a few bytes of memory at the expense of time spent investigating overflows. And when you're copying a value from the output of some other code, don't default to anything other than the type _that code uses_ for the value. uint32_t _might_ be okay for an unsigned int value, but using the same type will always be okay, on every architecture, system, and compiler combo.

- Look into tools which detect stack-stomping automatically. They could've saved you about 90 minutes in this episode! You wrote the same invalid-index bug twice, once when storing to the chars array and once when reading it. My suggestion with this one is to slow down a bit, especially when doing dangerous things like arrays.