Jump to content
  • Advertisement
Sign in to follow this  
  • entries
  • comments
  • views

GTL : The Washu Effect

Sign in to follow this  


As you may or may not have noticed Washu has taken an intrest in the GTL, which had me fearing him ripping into my design and code, however it wasnt that bad in the end and I'm always willing to learn from someone more experianced than myself.

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...
Sign in to follow this  


Recommended Comments

I'm surprised you moved the free functions into the object. Everything I've read about this kind of thing urges you to only have functions as member functions if they really have to be, because it increases encapsulation.

Any function that doesn't need to be a member, should be a non-member function.

What is the reason for doing this?

Share this comment

Link to comment
Yeah it's becoming something 'Wrappy' (the DirectX look and feel) and thus less 'Library' (the OpenGL look and feel). It's not necessarilly that one of them is better than the other, but it does go against your original design. But to be honest, I don't give a shit. As long as it works like it does, charm *!

Hmm.. -wait- it seems like I'm inventing words just because I forgot the exact terms. Something like COM and procedural. But hey who cares?

Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!