T w e n t y S i d e d

One of the things I like about this project is that it is uncluttered by goofy, awkwardly-designed libraries. Sure, I could have grabbed some existing code for loading 3D files or animating figures, but I still would have been faced with the problem of getting them all to work together with my program. It’s possible that I might have saved time, but it’s also possible that I would have spent those four days pulling my hair out and solving strange dependency issues and going on fetch quests to get all the stuff it requires, only to discover that it didn’t work properly. Then I would have had the problem I feared: A huge, complex system that doesn’t work and no idea how to fix it.

And even if it did work, I wouldn’t really want to have an extra ten modules cluttering up my program, with thousands of lines of foreign (to me) code, the bulk of which I’ll never need or use, all in the name of saving me a day of work. There’s a trade-off at work here (like there always is) where you exchange compactness, elegance, and maintainability for time. At some point it becomes worth it, but I always advise caution when integrating foreign code. Even if the other library was made by someone smarter and more experienced than myself, the truth remains that they didn’t design their code with my project in mind.

Worse, when integrating external libraries like this there’s always the chance you’ll spend the time and end up with nothing. (Although, I think my professional experience has improved my ability to spot the packages likely to become duds and time-sinks. In fact, yesterday’s post touched on that: Look at the interface of a library. If it’s cluttered, obtuse, verbose, and confusing to use, you should be extremely reluctant to add it to your project, even if it solves critical problems. Right now, you only have one problem. Don’t trade it for six others.

Hang on a second. I feel like I’ve done this rant before…

Continue reading ⟩⟩ “Project Frontier #15: Devil of a Problem”

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.

There’s a book called Teach Yourself C++ in 21 Days, which can be read for free online if you have the inclination. When people have come to me asking for suggestions about where to begin with C++, that’s usually where I send them. Looking back, I’m not sure that was the best move. Although, I don’t really know where else to send them. College maybe? That’s an excruciatingly expensive and time-consuming way to learn, and probably not a good choice for the curious person looking to test the waters. Even that might be a bad idea. A lot of people seem to read books and take courses and emerge on the other side having no idea how to make useful software.

Imagine a book titled, “Become a novelist in 21 days.” There’s also a college course that purports to teach you novel-writing skills. Inside, you will be instructed in grammar, spelling, punctuation, proper capitalization, and page formatting. Afterward, you march out into the wide world calling yourself a “novelist”. I mean, that’s what writing a novel is, right? Putting words together? And you totally know how to do that. You got an A and everything.

I’ll admit I’ve never seen the inside of a university as a student, and I’ll freely admit Ive got shameful gaps in my knowledge as a self-taught coder. But the way C++ is taught seems to have the most alarming omissions. For example, I know people supposedly educated in C/C++ who have never had to:

Continue reading ⟩⟩ “Learning to Program vs. Learning to Write Software”

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.

So I have an animation system that works. I also have a system to import animations from bvh files. Now all I need is a figure to animate.

I have a look at the various file formats available to Blender. There aren’t many. (The previous version of Blender had a LOT more file formats, but I didn’t know about that when I was working on this.) The Direct X format, creatively named “X”, is a likely candidate.

Still, you can go a long way to figuring out X files (see?) by just reading the file itself. It’s a parser’s dream: A unique word (like “Mesh” or “MeshMaterialList”) marks each part of the file. Then there’s a number, saying how many things it’s about to list for you. Then it lists them. Example:

Continue reading ⟩⟩ “Project Frontier #14: Import Models”

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.

Heads up, I did a weekend post on project frontier, so if you’re one of the many Monday-Friday readers (aren’t you supposed to be working?) then you might have missed it. In that post, Reader Jordi asks:

Hi Shamus, why don't you make your own file formats that are maximally efficient for your situation? Although writing a compiler/converter from a third party file format to your own takes some extra effort (although I imagine this would be fairly easy), I think it has 2 major advantages:
1) You get to select the third party format purely based on what modeling/animation tools you want to use, or how easy the format is to parse without having to worry about efficiency (both in terms of extra data/memory and parsing speed).
2) In your game you get to use maximally efficient and flexible file formats because you can custom tailor them to your own unique situation.

Ah. I really wanted to take this route. But my art path begins with Blender. (I’ll get into why later. I’m not planning on using it myself, I’ll tell you that.) If I knew Python and knew how to make Python talk to Blender, then I’d do this in a heartbeat. But I don’t and “learn a new language so you can avoid learning a new file format” isn’t really the most efficient way of doing things. Particularly since I’d still have to write the Python scripts, and then write C++ code to read the resulting files.

Continue reading ⟩⟩ “Project Frontier #13: An Animated Topic”

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.