- The first was function based, in that you copied around an immutable structure and used namespace functions to perform operations on it (or directly accessed the data yourself)
- The second changed this to a more C++ OO style; where you got back a pointer and called functions directly via that.
In the end, I've come to prefer the 2nd way of doing things over the first, if only because it means a C interface over the top would be easier to do.
GTL3.0, which is the tentitively given version for the GTL update, seeks to build up on that 2nd design and introduce some new features.
One of the main things would be a clean up/rebuid of the GTL loading backend; right now it's based on and very closely tied in with Boost's IOStream library; so much so infact it effects the design of the loaders, or filters, significantly.
At the highest data loading level things are read in a loop, the first read always being a header read and subsequent reads being image data. At the time this seems sound enough, certainly with the restrictions based upon things due to how I was using the IOStreams library.
However, hind sight is of course 20:20 and it was pointed out to me via someone I've exchanged a few emails with, that there is a better way to do this, namely by having seperate header and data reading functions, as after the header is read we know the size of the image data we are loading.
While the current system does work and all the 'filters' are written towards it I think a new system might be in order for 3.0, one which might even be more flexiable than the current system.
The reason for this added flexibility is that there is a feature I'd like to add to GTL, which I had in mind from the start, but couldn't include because of design constraints; async image loading.
Right now GTL is perfect for a classic 'static' level system, where at level start you load in all the data and be done with it. While these games are still popular a fair number use streaming of data in order to get things done, and having your loading thread blocked while data transfer completes isn't overly helpful I feel.
So, async loading is a definate addition, but not only from local sources, infact as the 'device' system will still be in effect there isn't any perticular reason that the resource needs to be local, it could pull it off an http or ftp server somewhere.
The interface will stay pretty much the same, however there will be a change to allow for textures with multiple images and different sizes per image; right now the multiple image support is there for DDS cubemaps, however with DX10 hardware allowing for texture stacks of different sizes getting this support into the library could be prove useful.
The only other change would be a 'status query' function which would allow the caller code to see when an image is done loading.
If anyone has any thoughts, suggestions or comments about this then now would be the time to make them [grin]
