Newbie disclaimer - I'm not a coder, I don't code professionally, in fact you may grit your teeth to find out what I do for a living. Anyways, you guys are warned.
I'm assuming the idea that a loading screen is necessary is because the process is blocking because it's busy doing io. Therefore, when you go to the 'next stage,' the game does all the IO before the gameplaying stage to keep the game playing pace, err playable.
If you try to callup IO to load up MonsterSpriteA into your game every time MonsterA is walking into your screen, you will always receive a 'hiccup' in the gamepace right before the monster strolls onscreen, and everybody will find that annoying (and predictable). The smaller the file, the smaller the hiccup. (are my assumptions correct?)
However, how about if you use a different thread to make IO calls, and have the thread pass over the object whenever it is good and ready? That way, your gamethread can keep playing along, and not worry about blocking due to IO. The downside to this is, that you can't have that thread make the calls on the fly, because it will still take time for that new thread to grab the image. What would probably end up resulting is that the game thread simply shows 'nothing', or rather, an invisible object pummelling you and you having no idea why, because the other thread is still loading the sprite. Or null pointer crashing (more or less, but you get the idea)
However, if you can 'foreshadow' the coming of the sprite, such as a tree graphic or whatnot, then you could have it loading up in your thread while you were walking over there, so by the time you get to the tree, the img will be loaded and will display it correctly.
This would be real handy for online games, where users can upload their custom sprites (avatars?) to the server, and upload it on the fly to clients that need to view it. Almost like a... browser with game rules.
So, the real trick is not how you can load images, but rather *when* you can load the images. If it's like a zelda clone, where you can walk to a different part of town, if you know that you are within a certain distance to that unique looking tree, start grabbing the tree image so that by the time you get there, the tree will render on screen. Should you do it when you are one screen width's away from the tree? How fast does the screen scroll towards the three? How much time can you afford to loading time?
I've been thinking about a very very simple graphic mud client with display of 320*240 (think Old School Nintendo graphics), storing most of the graphics locally, downloading changes on the fly when necessary like a browser cache (small screen real estate helps my situation). The reasoning is that I could get rid of the idea of zones, and have the whole world in one big giant map, and the main loading time for the majority of the files would only be when you start up the game.
That's the gist, apologies if this whole post offers no real value. Oh yeah, and is it possible to devote a seperate thread to disk IO like stated above in the first place?