Posted by elect on Oct 17, 2015; 7:46am
URL: https://forum.jogamp.org/Texture-compression-tp4032185p4035495.html

gouessej wrote

You could have used another library as a source of inspiration to make it work within JOGL but now, you have something that works, good.

I took a brief look before taking the decision.

I ended up with GLI because:

- it was one of the very few supporting dxgi and ktx

- very active and with a good user base

- modern looking and oriented

- hosted on github

gouessej wrote

If you don't, I'll find some time next year to add KTX support within JOGL. I still think that it isn't difficult to reintroduce g-truc's changes into another API.

Ktx is not a problem, supporting both dds and dxgi is. Moreover supporting few formats is not a problem (jogl dds supports three compressed formats, two of them can be seen as one since they share the same block dimension). Supporting all of them is.

gouessej wrote

What's the interest of open sourcing your code if it is hard to understand and lack of comments?

You are right, but in relative small project like this one it matters relatively less. Just to say, a project like jBullet would be a different story. This does not mean I don't want to do it or I never will, I just think that, given all the contest conditions, I give low priority.
One of the advantage of open source is that if you think it has a high priority instead, you are very welcome to contribute, as I said, or in extreme case clone and do whatever you like.

gouessej wrote

I don't like Microsoft but if you have no real understanding of its specifications, you'll be very dependent on g-truc's talent and you'll be unable to fix the bugs by yourself.

Oh, but the specifications are clear, gouessej.. Let me paraphrase you what the problem is, scanning the specs you read many times: "this is how the specifications is, so you should write in this way, but for the reading part you should do this and this because everyone doesn't give a shit about specs".
Now, as I said, if you want to be able to support most of them out there, you need to have (also historical) experience in the dds/dxgi texture field, something I don't have.
You are right, this introduce g-truc dependency. But I think gli has a solid core and I already ported it, so fixing bugs will require relative less skillz than building a core by myself.

gouessej wrote

Your library is a Netbeans project, it depends on Netbeans, there is no clean Ant or Maven script. you should make an effort if you really want others to use your stuff. Look at my own code, it's very well commented, documented, quite easy to build, ...

You are definitely right, this is one of my major problem I keep postponing because of laziness, I'd try to keep it up with this asap.

gouessej wrote

I don't want to discourage you but the interest of supporting additional image formats in JOGL but through third party libraries is highly debatable and I'll do my best to drive them less and less appealing as time goes by. You could at least implement a SPI still in a separate library but loadable by JOGL at runtime.

I disagree, I cannot see any cons about having a larger user base.

I'll analyse the SPI option