Part 3 is up. Check it out, then my comments below:
Ugh. The example Microsoft code Michael shows us for DirectWrite is abominable. That’s about what I remember for DirectX programming as well. HUGE variable types, all over the place, mixed case, and cumbersome syntax. The end result is that even simple lines of code end up being very long, which is bad for readability. This is probably the #1 reason I work in OpenGL. I evaluated both in the 90’s, and found OpenGL to be far, far nicer to work with. Since then OpenGL has (reportedly) struggled a bit to keep up with the cutting-edge stuff. I suppose this would be bad if I rode the cutting edge, but I’d rather have it be slightly more cumbersome to load a pixel shader in one part of my program than have the ENTIRE program look like a wall of incomprehensible gibberish.
It’s really interesting how much my recent work is matching up with what Michael is doing this week. I said last week that I wrote my own program to produce Drawn to Knowledge. If you remember, that was this video:
My program isn’t nearly as clean or as polished as what Michael is doing. It took me over three days to create, and is still rough to the point of being unfit for public viewing. But I had to deal with both the file-format question and the font-drawing stuff.
For file writing, I took the easy and cheap way out. As Michael said, you have to remember to mark your files somehow so that they will be readable in the future. Like, if you are making a save game system for your game, and later in the project you decide to add a bit of data for keeping track of how long the player has played this particular character. If you don’t have a way of keeping track of versions, then the newer version of the game won’t be able to read old save game files. It will look for that “time played” stat, and (because it’s an old savegame) find some other bit of data in that spot. This will throw off reading of the file and generally lead to some sort of hilarious failure.
For my own saves, I need to save all of these little doodles. They’re actually pretty small. (The entire presentation you see above is just ~317k.) So I took the lazy way out and gave the file a needlessly huge header file. How that works is this: The project settings record stuff like what background I’m using and what line color I’m using. (The next video will show this off a bit more. It’s done in purple “crayon” on white paper.) That bit of information is actually just a few bytes. But when I save the file I write a great big 2k block of (mostly empty) data at the top of the file. If I add some feature in the future then I can just throw that data in that big empty space and not worry about the file size changing. It’s wasteful to do things this way. But hey: two thousand bytes. Screw it.
Here is a shot of the program used to produce the video:
The font business was more annoying. I don’t actually need fonts for my program to do any drawing. That’s really my handwriting, although messier than my usual handwriting because I’m still getting used to the idea of a tablet. But for debugging I DO need to draw some stuff on screen. When something malfunctions, it’s helpful to have the program able to print text to the screen so it can tell me about what’s going on. Luckily, I didn’t need to worry about it looking pretty, since it’s just for my own use.
And because I know people will ask: The next Drawn To Knowledge will probably come out next week. I still thinking about when I should put it out, how often, what topics I should cover, how it should look, and how much time I’m willing o put into it.
Shamus Young is a programmer, an author, and nearly a composer. He works on this site full time. If you'd like to support him, you can do so via Patreon or PayPal.
T w e n t y S i d e d
