Preloaders - Advantages and Disadvantages
Preloaders - advantages and disadvantagesUsing a preloader is a lot like using percussive maintainance to repair a device:
If you know what you're doing you'll get a lot of astounished people asking "How did you repair the thing by hitting it with a sledge hammer??"
And anyone who doesn't know what they're doing wonders why everything broke apart on being hit.
Preloaders aren't miracle workers - and in a lot of cases they break or slow down your games. Not because they are buggy, but because you don't understand their limitations and use them in the wrong way.
This tutorial is intended to explain the basics behind the preloaders, so that you know how to use them and how NOT to use them.
Unfortunately that means that parts will be rather dry reading to explain the basics - but if you consider using a preloader you should read this before applying a sledgehammer to your game.
A hammer rarely speeds something up, it usually breaks it instead.
The most precious resource of the computer is the RAM. Early programmers spent month on applying every trick impossible to reduce their program's RAM usage - that was at a time when 64kb RAM was priced in the hundreds of dollars.
When the RAM became cheaper that was unfortunately abandoned and modern programmers often don't care about memory management - which makes the RAM expensive again, just at higher numbers.
Because of that no computer ever will have "enough" RAM, they can always use more to speed things up.
A side effect of that missing memory management is what is usually called a "memory leak". Some of you might remember from the early MV versions that there were many bug reports about "memory leaks", which is basically memory being filled without ever being re-used.
The memory leak is basically the program loading data into RAM to be used, without a care whether the computer has enough RAM or giving it back to other programs to be used, until the program lags and crashes from missing RAM.
And now you're probably beginning to understand why I have sometimes called preloader plugins to be "memory leaks by design", because that is exactly what they are programmed to do: load files into RAM without a care for the availability of said RAM.
And with the same risk of crashing if the data is not released when the RAM is needed for something else.
Now, if most programmers have abandoned memory management (especially hobbyists writing plugins that never heard the term), why don't the computers crash all the time with memory errors?
The reason for that is the garbage collector, a very limited form of automated memory management.
The garbace collector check the memory regularly (and every time it gets too full) for the oldest files (longest in memory) and releases them to free up the RAM again.
And that is where the first case of wrong use of preloaders happens:
How many of you have thought "Preloading speeds things up, so let's preload everything!!"
That can't be a problem because the preloader magically creates RAM for everything to fit, right?
No, not really. What really happens if you try to preload files three times of what fits into RAM is that the first files are kicked out by the garbage collector before the last file in the list even started loading, and all but the last few files will be gone by the time the player presses "new game".
You only slowed down your game start with loading files that are quickly removed again for absolutely no advantage.
"Preload on boot" only works for a very limited number of files that are constantly needed from the very beginning. Pictures of HUD elements on the main screen are good candidates for preloads, or pictures from an introduction and similar.
Everything else would long be removed from memory when it is finally needed.
And please never forget that storage/filesize is NOT RAM-Size, most pictures are stored with a compression rate of 50 or 100 or more, meaning that their size in RAM is fifty or a hundred ties of their size on harddrive.
Now you should also understand that the only way for a preloader to work correctly is if it is given the command to load something at a short time before the file is used, but not directly before that use.
If you give the command too early the garbage collector will have it removed and forces you to reload it on use.
If you give the command too late then the loading is not yet complete and the computer has to wait for loading on use again. Which is a lag that you want to prevent by preloading after all.
I haven't checked the code myself, but from what I heard the latest maker versions have a half-way decent preloader on the event interpreter.
Upon loading an event for execution, it checks the event for the show picture commands and preloads all pictures used in them, before starting processing the event with its first command.
Depending on what kind of event it is and how many pictures it contains that principle may still be lacking (for example if it is cycling though many large pictures for an animation), but it is at least trying to follow the best principles as to when to preload which resources and as such will speed up most events.
And that is what you need to do if you want to get improvements by any preloader:
1) identify resources that are too large to be loaded fast - you don't have to use a preloader for small icons that are loaded within microseconds. Parallax maps, large background pictures or videofiles are something else
2) look at when that resource needs to be available for use. It does not help to load it hours before that, the garbage collector would remove it long before it is used in that case.
And neither helps a preload command on the line before the resource is needed, because that preload command would get you nothing compared to directly loading the resource.
3) find a place in the events that is shortly before that moment, based on the size of the resource. If the computer would need three seconds to load the file that place is different than it would be if the file can be loaded in one second - or in ten seconds
4) place the command to preload there.
Any other form of preloader use - especially excessive use of preloading to the point of overloading your memory - will only cause negative effects.
And there is nothing that can change that.
For example another point is "Virtual memory" - computers can increase their physical RAM by adding "virtual memory" - but do you know how that works?
It means placing part of the memory on the harddrive, which is why the virtual memory is so much slower. It needs to be loaded back again from the harddrive to be accessed.
That is the opposite of the preload function, which means that if you use the preload to a limit that forces windows to create more virtual memory to compensate the demand, then you're working against the preloader advantage.
So another problem of using preloaders is to know how much RAM is available to keep the preload limits within that limit.
And since you don't know how much RAM all your players will have, you cannot just base everything on the performance of your own computer (which is often above average for the interested developer).
I hope that these background informations will make people think before adding preloader plugins to their games, and especially before configuring them.
A preloader can help and speed things up, but only if you as the developer know what it is doing, and not automatically.
本贴来自国际rpgmaker官方论坛作者:Andar处,因国际论坛即将永久关站,为了存档多年珍贵资料,署名转载到本论坛存档,由于官方帖子为英文原帖，需要中文翻译请点击论坛顶部切换语言为中文就可以将帖子翻译成中文浏览,方便大家随时查看,原文地址：https://forums.rpgmakerweb.com/threads/preloaders-advantages-and-disadvantages.162804/
页:
[1]