• entries
455
639
• views
422282

# GTL3 marches on

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.

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?

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]

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.

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:

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.

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>


## Create an account

Register a new account