Posted by elect on Oct 16, 2015; 2:08pm
URL: https://forum.jogamp.org/Texture-compression-tp4032185p4035487.html

gouessej wrote

Hi

It's better than nothing but why promoting a third party library instead of implementing those features directly within JOGL? Adding KTX and DXGI support in our texturing and imaging API would benefit to the whole community without having to learn how to use another API, a developer already using TextureIO would have nothing or almost nothing to modify in her/his code to support those formats.

Charity begins at home: I moved the automatic image format detection from JogAmp's Ardor3D Continuation into JOGL so that it benefits to all JOGL users instead of the few ones using this engine. This is what I expect from other developers.

Edit.: You have kept the useless comments generated by Netbeans at the beginning of each class... It would have been easier to support those image formats within JOGL...

Edit.2: Where is the license???

Edit.3: There is almost no comment in the source code and there are numerous calls to System.out whereas you should use a logger.

What you write is totally right and agreedable.

And indeed it was also my first idea: I tried at the begin modifying the jogl structure to accomodate the dxgi formats (this was my attempt), but I found this way really time consuming and low productive. I spent literally days without getting nowhere...
The dds/dxgi docs are a nightmare, there is nothing given for sure, specifications look like just an hint, I spent a lot of days, I had something like 30 tabs opened on my browser, I was even looking inside other projects, like dds reader, Valve dx->gl porter and so, trying to understand what has to be translated with what...

The current structure of jogl was fine at that time, when you didn't have to deal with layer/faces, all the possible combination of 1D-2D-3D-Cube-Array and a legacy and a new format from M$... The main difference between the jogl current structure and jgli/gli is the usage of an intermediate layer, made of formats, targets, types, etc.. you can take a look at them here

The biggest problem is experience, I lack experience in the texture/opengl field and in developing for jogl. This was another reason to do 1:1 port.

1:1 port gives me essentially three huge advantages:

- I see progresses, coding porting a lib is way easier than doing it from zero. If anything doesn't work or I don't have a heck of idea how to go on, I just debug the C version and I quickly find it out what was the problem. Sometimes even this is not sufficient, look for example at my troubles with jAssimp and materials..

- I don't have to deal with all the shit of understanding and checking which parameters and in which order I have to control in order to figure the texture format out, basically I skipt the M$ specs :p

- I can incredibily easily and quick catch up the main lib, these two qualities also transfer in turn to other topics such as closing/finding bugs and introducing new features and formats (g-truc is proposing, for example, a new format, KMG). We basically exploit the C community for being always on the top edge ^^
Just to mention, I implemented (partially, only what has been ported so far) all the modifications that g-truc wrote in the whole month of September in barely an hour (!). And he is updating that like hell, trust me.


Anyway, I still plan to re-introduce all the features jogl has, such as png, jpeg and so on. Once done and stable, we can include it back in jogl.

Of course this will include some modifications/new methods and so on, but I am truly convinced the advantages are far bigger.

What do you think?


Ps 1: I'll remove then when it will be time, there are other priorities now, if you want to do, don't hesitate :)

Ps 2: Mit

Ps 3: same as 1