Sign in to follow this  
  • entries
    455
  • comments
    639
  • views
    422282

GTL3 marches on

Sign in to follow this  
_the_phantom_

102 views

In a flurry of activity last night I added remote downloading of textures; right now it only works with http or ftp requests but as i'm using libcurl I can pretty much deal with anything; I probably need to refine my 'is this a url?' detection; I wonder if ':' is a valid character in any file systems?

Today I added async downloading; this was just a matter of pointing the async routine at the Sync libcurl based loader as there really didn't seem to be any other way of doing it. It might be possible to hack something together with events but for now this seems to work just fine as the loader is in another thread anyways so it doesn't matter so much if it blocks.

Now matters switch to that of loading errors; before today if a file didn't exist things would just asplode and you'd find yourself in Debug Town so I've got to the loading routines and added various error checks and exceptions so that the loading can fail cleanly.

This brings up an issue however; how to report the errors?
Right now, the exception is consumed, the image's status set to 'error' and the client has no further information about the error. It could be a load error, a parse error or anything like that if simply doesn't know.

So, the question becomes do we want to give back more information and if so how?

Right now I'm not really sure how I want to go about this, and with the added consideration of a callback system when loading 'completes' being throw into the mix it just complicates matters further. This requires further pondering.

The other thing I'm thinking about is the ability to define custom decoders; the main reason this could prove a problem is that it requires exposing some internal code to the external world. Mostly it's a short refactor to shift things about, but mostly it's a matter of doing it cleanly. The fact that some of the functions are templated, such as the image flipping routines, and thus need to be resolved at compile time is also a slight pain.

So that requires some consideration; given that the library is redistrubted as source and covers the major image types I don't see how added an extra decoder could be handy, the ability to define your own loaders however is useful as the library only understands file or url sources.

So, the march towards 'complete' carries on, of course once that is done we aren't at the end of this saga as the core needs refactoring out and seperating so that an audio loader can be added, thus forming an asset loader.
Sign in to follow this  


4 Comments


Recommended Comments

Pre OSX macs use colon as a path separator: http://www.westwind.com/reference/OS-X/paths.html

As for errors, what about an error callback function?

Share this comment


Link to comment
Quote:
Original post by rip-off
Pre OSX macs use colon as a path separator: http://www.westwind.com/reference/OS-X/paths.html


Bah, it's always the macs [grin]
OK, how about '://'?

Quote:

As for errors, what about an error callback function?


Well, I already had plans for a 'loaded' call back, so I may as well place the payload of information in the Image class, that way it is avalible in both the call back and the non-call back way of loading things. Due to the async loading any call back would have to indicate which image/asset failed to load anyway.

I guess two call backs could be setup with the same signature, that way at least if you wanted you could route both outcomes to the same code.

Share this comment


Link to comment
Quote:
Original post by phantom
Quote:
Original post by rip-off
Pre OSX macs use colon as a path separator: http://www.westwind.com/reference/OS-X/paths.html


Bah, it's always the macs [grin]


Odd bunch, that lot [smile]

Quote:

OK, how about '://'?


I imagine they choose that because no existing OS used it. Could be wrong though.

Quote:

Quote:

As for errors, what about an error callback function?


Well, I already had plans for a 'loaded' call back, so I may as well place the payload of information in the Image class, that way it is avalible in both the call back and the non-call back way of loading things. Due to the async loading any call back would have to indicate which image/asset failed to load anyway.

I guess two call backs could be setup with the same signature, that way at least if you wanted you could route both outcomes to the same code.


Sound good to me.

Share this comment


Link to comment
Yes, : can occur in filenames and :// can occur in paths on at least BSD and Linux (and I think for POSIX in general, but I'm not positive):

[pete@slow:~/tmp]
283> mkdir http:

[pete@slow:~/tmp]
284> echo zxcv >http:/qwer

[pete@slow:~/tmp]
285> cat http://qwer
zxcv

[pete@slow:~/tmp]
286> ls -lR
total 9
drwx------ 2 pete pete 3 Jan 6 12:35 http:/

./http::
total 5
-rw------- 1 pete pete 5 Jan 6 12:35 qwer

[pete@slow:~/tmp]
287>

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