threading model

well, the biggest problem with multi-threaded loading is that it still all has to go through one processor(on most systems). i.e. threads aren't magic, you still only have one CPU (unless you have 2 .

in a threaded model you will run into CPU load problems whenever you load resources that will result in frame rate drops. I think it's actually easier to manage CPU & time usage by keeping it NOT threaded. you can still have a buffer of pending requests, but you can more effectively space out the loading over multiple frames within some kind of CPU budget for the loader. like, read in X bits / frame where X is most likely either experimentally determined during development, or dynamically determined by passing some kind of time allowance into the loader's update method.

IMHO it's just easier to manage your FPS if it's not threaded. with multiple threads you'd still have to synchronize the thread to the main loop method, or at least implement some kind of thread monitoring system to ensure that resource loading isn't slowing the main program down. at the end of the day, i think that ends up being more hassling than it's worth.

[EDIT: resource loading that doesn't effect framerate is pretty essential. URU: Legends beyond myst, has completely crap resource loading that seems horribly balanced over multiple frames. loading sections of the map is almost always percievable to the user which is extremely annoying. (i think they optimized it for topend systems, which leaves a 6 month old system chugging a bit on certain maps)]

-me

[edited by - Palidine on November 25, 2003 4:37:37 PM]