Some of you have seen the new LoadingGameState that I added not too long ago. I'm using it extensively in my current game I'm developing. However, I would like to implement this concept on a larger scale within jME. I would like to take the Loader interface and add it to the core of jME. The reason for this is to be able to interject it into aspects of jME that might take a while (model loading, texture loading, terrain generation, etc) and add the ability to add the Loader interface to initialization method invocation along with a number of increments the object should take. For example:
Node model = (Node)BinaryImporter.getInstance().load(myFile);
could be re-written to:
Node model = (Node)BinaryImporter.getInstance().load(myFile, loader, 10);
This would set the loader into the load method and the BinaryImporter would call:
loader.increment();
10 times before it returns. This will allow for smooth progress in game loading throughout all of jME. Does anyone have any thoughts on this? My intention is to add support to everything that might take much time to load, but they would be additional methods, I wouldn't remove anything so people that do not use this wouldn't be forced to change anything.
I'm opposed to this. Passing a progress bar (or progres type item) into low level interfaces goes against modularity in every way. When you come up with some other tool that measures work done by the underlying system are you going to add yet another parameter to pass in? By polluting the API with LoadingGameState objects (which by the way is not in the core, so should never be referenced in the core), you are taking away options for people to use their own loading system.
I assume Loader is a very clean interface that has nothing of LoadingGameState associated with it.
I think the third parameter is pretty silly though… If you were to have such a thing, let "loaders" (I mean BinaryImporter in this case) choose themselves how to often to update. Potentially Limiting the number of updates should be the concern of whatever implements Loader.
I don't really see a need for something like BinaryImporter to support this either… my guess is you'll never get it to be accurate anyway. And when you load several models, just use that to set a percentage, you can even interpolate a bit if you want it to look smooth.
I too think melding it into the internals of jME is "a bad idea" ™. The Binary loader takes less than a second to load pretty much every model I've ever thrown at it and thus having a progress bar externally increment after each load would be just as interactive and informative to the user. (i've done something like that at work, but just incrementing after loading all models, after loading all sounds, etc. and it is already pretty much "good to go" at that level.)
But what’s the point of having a progressbar that runs very choppy, and then suddenly smooth for a bit?
Maybe you can make a smaller less intrusive hack change to TerrainPage that’ll let you make a loader that can spy in on it’s progress. Or switch to my terrain
This is really an easy task to resolve if we could just agree to have a Loader interface be able to be taken by tasks that are loading. I'll do all the rest of the work to make a smooth progress bar with tasks that are instantiated based on how large they are in comparison to other tasks. It should be relatively easy and would make loading progress smooth throughout.
llama said:
But what's the point of having a progressbar that runs very choppy, and then suddenly smooth for a bit?
I agree, but my point was to prove that is definitely a valid argument for one thing and thus necessitates insertion throughout. :)
The biggest problem with something that guesses based on previous loads is that often you have different amounts of data loading each time. Take for example a sector loader for a massively multiplayer game. It has to load all the models for that sector, but depending on which sector and what is currently in the sector this can differ significantly. The way I'm proposing reduces the complexity significantly and addresses this problem. It simply requires us to pass around a Loader object though.
I'll do all the rest of the work to make a smooth progress bar with tasks that are instantiated based on how large they are in comparison to other tasks. It should be relatively easy and would make loading progress smooth throughout.
The way I'm proposing reduces the complexity significantly and addresses this problem.
1. you need to explain further how you would accomplish that, cause i don't believe you at all(call me stupid).
2. in an mmorpg i would never load all models currently in the sector at "progress bar"-time but rather like WoW and load it continously during play time(first just show shadows where people are then slip in the models as they load etc). the progress bar is just for static stuff so the "guesses" would be quite good...
I'll refrain from calling you stupid for fear of what that would make me.
What I was thinking about is having the Loader have a nextTask method that would switch to the next task before passing the loader to a an object with work to be done. In instantiation of the LoadingTask that gets added to the Loader a multiplier (like 10 for a task that takes a really long time, 1 for really minimal tasks, etc) could be specified as well. When the work is being done the loader.setProgress(float) would simply be called from 0.0f to 1.0f for that tasks progress. In the loader implementation it would take into consideration the multiplier for the task in addition to all other tasks completed and incomplete to determine the current progress. If specified properly then loading should be extremely smooth and continuous throughout the load of the game.
Unless you come up with a better design for the system, the argument is moot. You need to figure out how to do what you want to do without passing ANYTHING to the units of work you want to measure.
Let the "workers" expose their progress themselves, you can then write loaders that "wrap" them. But it still only makes sense for "workers" that can actually predict how far they are with some sense of accuracy.
There are many times when the animation continues (and I can think of Internet Exporer as a quick example of this) yet it's stuck and not progressing any further. You lose the major point I'm trying to address by removing progress.
llama, I'm not opposed to doing the reverse and having something like a Progress object returned immediately on tasks that will take a while to accomplish. Is this something that others would not be vehemently opposed to?
still an unsolved mystery, ten times harder than fermat's therorem…
