So, after a convosation the other night I started work on Washu-ing the GTL [grin]
The first thing to go was the copying of objects around, no instead of the LoadTexture() functions returning an Image object it returns an Image*. This will ofcourse make life easier when it comes to using it with C# or with DLLs as copying objects across DLL boundries is iffy at best.
Because of this we have also gained a FreeImage() function to properly delete the image from the DLL's memory pool.
However, for those of you who dont want to deal with the pointers themselves the header has now grown some inline 'safe' loading functions, namely LoadTextureSafe(), which wrap the returned pointer into a boost::shared_ptr and set the delete function to point to the FreeImage() function so memory is properly cleaned up. As they are inline they will exist in the application side of the project, not the DLL side, so using C++ containers isnt a problem.
The free functions are also currently gone, instead they have become member functions of the object. However, if enuff people want them they could be brought back as wrappers for the member function calls.
One of the issues Washu brought up was the lack of ability to add image decoders at runtime. This has now been fixed for the most part with the addition of a RegisterRunTimeFilter() and unRegisterRunTimeFilter() pair of functions. The former returns an id you can use with the LoadTexture function to indicate the type of image. The latter unregisters the loader by the same ID. Because of this the filetype is no longer an enum but an int, with the built in IDs being hardcoded into the system as const ints.
Ofcourse, all these changes bring one key issue I've still not puzzled out; how to deal with functors.
Right now, all the function pointers are being copied around as part of a functor, but as we know, we cant do this across a DLL boundry without being tied to one C++ compiler.
I've got a few ideas about how to fix this, however any insights people might have would be welcome.
- It needs to be clean
- needs to work across DLL boundies
- needs a way to possibly work with C#/other .Net language
Recoding parts of the framework to fix this isnt isnt out of the question, although idealy I'd like to get everything into a working functor on the DLL side of things.
I could enforce "C style functions only!", and for the texture filter creation this wouldnt be a bad thing over all, but for the user callbacks on load and the custom readers this could become klunky so I'm not overly happy with the idea.
Thoughts and feedback as always welcomed...