DIY or not?

[arno]

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.

Continue reading...

 

[tgibson]

However, you do it, I appreciate the result.

 

[sal1800]

I can relate to exactly what you are describing. I don't work on anything as complex as MCX but in web development we face a lot of this sort of thing.

I'm fine with the modern front-end frameworks, it's when the developers think they need to bring in all kinds of silly dependencies. If they tried to take the time to understand what's in them, they would have been able to just write that code. But the worst is when vendors convince marketing to use some new tool for tracking or analytics or something. "Just add this Javascript snippet to your page", they say. Yeah right, we'll just plop that in so it can affect our entire app. Then of course they ask for all this custom code to feed their script.

But really, MCX is such a powerhouse tool, no doubt due to your decisions like this. It's bold for sure since importers, converters and exporters are hard to get right. The spec doesn't really mean much in the real world where you're going to have to deal with all sorts of files don't care to follow it. I think you're right, you'll come out of it with much more knowledge and a more robust piece of software.

 

[Pyscen]

Arno,

There is one possible easier option or at least a different option: To use the NVidia Texture Tools Exporter (standalone). It has the capability to be used within an application.

This would levitate the use of a library or the programming of every possible ways the dds needs to be created. Of course, everyone needing to create a dds would also need to download the standalone application for it to be called upon by MCX.

 

[arno]

Hi Doug,

It's the dependency on ImageTool to create the DDS files that I try to remove. Now that more users use MSFS only, they don't always have a FSX or P3D SDK installed anymore. Using another external tool does not sound like a good alternative in that case. And also calling an external tool is slower in general, as that involves saving the data in some temporarily file and then calling the converter.

I'm almost done with implementing DDS now, DXT1, DXT3 and DXT5 are done. I only need to work on the alpha channel in the DXT1 files. So hopefully in a few days something is ready.

And it was a nice experience to figure out how to select the optimal color line that is used for each cell in the DXT compression. Always good to learn something new

 

[Pyscen]

That's fine and understandable. Are we going to have the same problem though with psd files not reading the alpha channel correctly like imagetool?

Reading psd files as a flat image.

 

[arno]

Humm, not sure which PSD issue you refer to. MCX can read PSD files for quite some time already and I have never heard that the alpha channel is read wrong.

 

[Pyscen]

I'm referring to how MCX reads the PSD file. either as flatten (data). image. I refer to this thread: https://www.fsdeveloper.com/forum/threads/mcx-photoshop-dds-conversions.442021/

I just wonder if you have "fixed" (more robust) how MCX reads PSD files.

 

[DragonflightDesign]

Arno... somewhere on Intel's website is the OSS code for their DDS conversion tool. Of course:

a. I've deleted my local copy two days ago (!)
b. you really didn't want me to tell you that (both comments!)

 

[arno]

I'm referring to how MCX reads the PSD file. either as flatten (data). image. I refer to this thread: https://www.fsdeveloper.com/forum/threads/mcx-photoshop-dds-conversions.442021/

I just wonder if you have "fixed" (more robust) how MCX reads PSD files.

I had to re-read that old thread. But the conclusion then was that both ImageTool and MCX show the same issue. So I don't think the current change on how DDS files are saved has anything to do with this.

I will add it to the to do list to check the psd reading, but I'm not sure if that's easy to fix.

 

[Pyscen]

Yes, you did say that before that it may not be easy to "fix". That was the reason I was asking since the previous thread if you have "fixed" it or not.

 

[Ronald]

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

TIP: Before anyone passes any judgement on any so called "pro's" and "con's" (often invented formed by others then blindly copied by oneself), perhaps it is wise to consider these facts:
1 - Having to learn everything yourself is the hard way: It takes time, _can_ generate a sh*tload of frustration, need presistence, and often come with having to (re-)write your own native level of documentation
2 - Yet! At the end of the process you now have fully in-tegrated all that hard earned wisdom inside yourself, and that is absolutely price$less (later on in another project/ Life itself).

3 - Regarding using somebody elses stuff: Here a few wise words from a guy who really knew his coding_stuff

More of Ken's (coding's) wisdom's can be found over here:
- [ur]https://www.azquotes.com/author/14620-Ken_Thompson[/URL]

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.

4 - Stop using this phrase please: "Reinventing the wheel". This non-motivation / non-inspiring negative thought-patterns are a absolute killer for any type of innovation)
To me personally it is always better to adhere to the one and only True Hacker Ethic guidelines:
- https://en.wikipedia.org/wiki/Hacker_ethic
- https://learn.onemonth.com/the-hacker-ethic/

My personal final words on "DIY or Not? "
5 - Once one chooses to fully OWN your stuff, and have 100% created, written and testing one's own code. that is - to me - the only way going forward.
- Always strive to gain and maintain full (digital) autonomy at everything you do
- Or become at least 100% aware of all cavecats, quirks, (business-continuity / vendor_locks_ins) risks that come by choosing to use somebody elses [payware-d] fruits-of-labour.
And no, mentally labelling something *.* as [payware], doesn't turn somebody elses stuff magically into into a rocksolid flawlessly working magical product all of a sudden...


5 - Why choose the Open_Source approach?
One can always choose to learn "from the best of the best", from their fruits of their own labour and start where they left, and improve their! wheel! with your own newly gained insights.
That is my personal reason to fully embrace the Open_Source(d) ecosystems and cultures:
- Find and download somebody elses relevant (and well documented) source_code / projects

- Learn from their approaches how they choose to tackle a problem and then decide:
-- to only improve their existing ways of doing it (which has been developed to the maximum of their given (cap)abilities in that time-frame
-- simple and boldly take a whole new approach armed with time-advanced insight and newly gained skill-sets.
- Do your own native stuff with the gained knowledge

- Reupload your best work back into the community you got it from
and thereby elevating this particular entire ecosystem, for which you have benefited to learn from

Since... not matter how everyone wants to ignore it: We all started and developer_noobs, learning from somebody elses hard-earned efforts ;-)


TIP: Nice book to read and memorize on the //ROOT of the one and only Hacker culture by Steven Levy
-https://www.amazon.com/Hackers-Computer-Revolution-Steven-Levy/dp/1449388396



Note for those who dis-agree with this statement:
Just look around you at the contents of this FsDeveloper forum, and think about the endless hours we! all! have had to invested into decoding somebody elses socalled "Software Development Kits" over the past decades,
just to get our own ideas into somebody elses poorly documented (if any at all) and supported toolset / programs / eco-systems.

How many of you have been (cap)able to simply implement your ideas - straight out of the box - into your desired flightsimulator?

 

[shez]

🙂👍