Let's revisit memory cap and memory exceeded issues.
I don't pretend to be advanced or technically savvy in this area, but, what I do know is that when the game is being compiled into a stand alone
each level is compiled and saved. During this compilation data is being stored in virtual memory rather than to disk so that it will compile faster.
What takes up the most memory is light mapping. When the memory hits it's max is where you will see "Calculating Object Light." Calculating object light is dependent upon two settings in the ini file.
lightmaptexsize=512
lightmapquality=5
The default values are shown. A lot of people worry about what they see even when they are testing a small level. Check out the image below:
You will see that 1015MB is being used. This is only for one room without anything else in it. This is also before we get to the place where it starts calculating object lights.
You see, there is simply a certain amount of memory that is taken up regardless of the size.
Before I make the next comment I would like to say that v120 is the best version to use as there have been some changes made to make better usage of memory during the build.
So, you have exceeded the memory cap during a test build. The first thing to is check out those two parameters mentioned earlier. If they are at the default, you could decrease the
lightmaptexsize to 256. However, I feel that 512 should be the absolute minimum. I have mine set to 1024. I have
lightmapquality set to 75. So I certainly have some wiggle room.
The next thing you can do is check your light shadows in preferences. If
Best For Performance is already selected the only other alternative is to select
No Light Mapping. I really don't recommend that. However, you will never have any virtual memory problems if you select that.
What's next? Some people believe that too many dynamic entities will take up to much memory. That may be the case but not in terms of light mapping. Also, dynamic entities effects FPS more than the virtual memory being used. What effects light mapping the most are
static entities. Why? Because static entities will produce shadows. Creating shadows means the use of light mapping (LM). As a side note: this is why Lee has never made it possible for dynamic entities to create shadows. It would be cool but not a good idea for FPSC. He even has a question on FPSC-R about making shadows for dynamic entities. He does have some thoughts on it, however.
So what can you do? You probably have noticed that most of the crates and boxes that have been created by TGC for FPSC are dynamic by default. Most people will then think that perhaps I should make them static. Making them all static is
not a good idea. Most of them have a default.fpi for their main script. This will decrease the possibility of FPS being reduced because there is no script to execute for that entity. The only issue one might have is that the crates are "moveable." You can make them immovable if you want. Also, you can make some crates static to have some shadows cast but most of them should be dynamic. If you still have problems with exceeding the memory cap then you will have to reduce the size of the level. If you have more than one room, I would first get rid of whatever extra rooms you have. If you like have enough going on in the one room with all the entities then you could go to the next level when the player goes from the one room to the next. However, I would make sure that the player is actually finished with the level before sending him to the next.
Another really good idea is as xplosys mentioned. Making a model that is a shelf and that has boxes and crates on it. This can be one large entity. The trouble is I would not be able to create a model like this because I'm not a model maker.
THEORY - you know everything but nothing works. PRACTICE - when everything works but don't know why. For me, theory and practice are combined: nothing works and I don't know why.
