12.18.2011

I think I want to make a system that requires too much control over threads and their continuation control than possible (or just not imagenable to me) with the stuff implemented in SDL. I've this some times now and this means I'll have to do something else about it. I guess I'll never get to the point where I've a finished game due to that. There are so many things to consider with this system. If I'd not want to always put ressources immediately required into a list position with higher priority, I wouldn't get those problems. Point is, that this wouldn't really make something that's better than always loading when needed or in a loading screen. See, when everyone's waiting for something, it's like loading all the stuff in the way they started waiting on it. So it's not of use to decide between priority. It makes it completely useless. So there's only wacky, specialized loading of textures or direct loading when required. This is why Borderlands loads it's levels and sounds first and will the stream it's textures in the background cause there'll always be a texture to work - no matter how big it is! This is why Skyrim and Oblivion tend to have their short freezes once in a while - because they have to load their level data instantly when entering it. I tried to overcome this by concept but I fail by the operations giving by SDL and the operating systems.

Is there no way to workaround this? Do I once again have to create a new synchronization object that works around it? That's switching between waiting on mutices and changes of values? It seems so. So I'll give a last try before attempting a simpler system with no good features but atleast a few advantages but optimized waiting between. *sigh* My next step is collect what would be the best solution for a simple ressource manager code. First the features, then the implementation. I'm not liking this but there's no other way to avoid system limitation. I'll have to invent something new again. Darn.

No comments: