DIY or not?

When developing my tools I often have to choose between implenting a functionality myself or using a third party library that provides it. Both approaches have their pros and cons of course.

When coding something yourself you possibly reinvent a wheel that somebody else already did. But on the other hand it gives you more flexibility to implement it the way your tool needs it. And when there are bugs in a functionality they are often easier to solve.

When using a third party library the arguments are kind of reversed. It’s often quicker to use a library, but glueing all kind of libraries can result in a messy architecture of the tool as well. And for bugs the library is sometimes a black box where you can’t look into.

For MCX I have been meandering between these approaches for quite a while already. For example initially I made my own COLLADA reader, while later I switched to the Assimp library to read COLLADA and other formats. But sometimes there are issues where the library just throws an error and you can’t easily debug them, so then I wish I still had my own reader (of course forgetting at that moment how much work I can be to maintain that code).

So why am I talking about all this now? At the moment I’m implenting a feature to write DDS files without ImageTool. I tried to find a library for that, but the only good one I found targeted a much newer version of dotnet and updating MCX to thst version proved to have a lot of errors. So in the end I decided to write my own DDS writer and that’s what I’m working on now.

And of course there is one more pro of writing some feature yourself, you learn a lot from it. And this understanding, in this case about the DDS file format and its limitations, also helps to understand better why the sim works like it does.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.