FPSC Optimisation Techniques and Tips Compilation Thread
After running into issues with built games crashing while loading, I had to dig out some methods to optimise my game. I've since answered questions to problems very similar to what I faced, which made me wonder how many people are actually aware of these techniques. So I decided to start to put together all of the methods, techniques and tips for optimisation of FPSC.
The aim of this thread is also to provide a handy resource for those who need to stop their levels from crashing or optimise them to get that bit extra. There are tip ands tricks are all over this forum, and it seems like a sensible idea to bring them all together. If you have anything else to contribute to ways FPSC can be optimised then please share and add to the list
Also, I realise some members here will likely know all this. If you already know this then consider that the next person along may not.
Here a list of the links I provide:
v120 beta 17a
Unofficial beta F
Paint.net
Audacity
Research on memory cap (DXT1)
Dealing with the memory cap
Tip to stop hitting cap
FPSC optimisation
Multiple Build Levels method
-------------------------------------------------------------------
So, first off, I'd recommend using FPSC v120 beta 17a with the latest unoffical FPSC game.exe. The reason I say this is because they vastly improve on stability, performance and testing times (unless you're using a custom source, I know the foxes do for example), scene commander and s4real have put some really good work into it.
Here's the link to v102 beta 17a
Here's the link to the unofficial beta game
If you don't know, Install Beta 17a first and copy the FPSC game.exe from the last link and paste it over the previous one. However, this one isn't a necessity. The optimisation techniques (except for the passage about lightmapping recalculating and building) should work for all versions.
-------------------------------------------------------------------
The absolute biggest save I made when making my game was optimising all of the textures in the game.
Here's a link to a post that I recommend you read (the textures part). Basically, there are different ways to save a .dds texture file. If you save a .dds texture file that has no transparency in it under DXT1 compression the image is 3x smaller in file size, but entirely unaffected visually. If you don't have it already,
paint.net is an image editing tool that can save .dds files as DXT1, although other image editing tools will likely do the same job. What I did was go through my entitybank and texturebank, loading textures in bulk until I had an entire folders worth of textures open. If they contained alpha or transparency I didn't modify them. I saved these as DXT1 and then shifted them back into their appropriate folders, replacing the old ones. It took a good few hours to go through everything relevant to my game, but was
well worth it.
This shaved off approximately 300-400mb off of each of my levels. Where as one of my levels hit 1838mb, it hen hit 1500mb, which is a huge save in space. When optimising I would recommend taking this approach first because it allows for much higher quality and more quantity in your levels. When previously my lightmapping quality was set at 20-35, it its now 50-65 etc.
One of the bigger consumers of memory is textures. The bigger the file size, the more memory it loads. Because converting non-alpha textures to a DXT1 compression reduces their size by approximately 3 times, that makes more space available for everything else.
-------------------------------------------------------------------
A thread I
recommend to read in this one on dealing with the 1.85gb memory cap.
What I got from this is:
-lightmaptextsize does not need to exceed 256 (I use 256)
-reducing the resolution of textures decreases file size (eg. 1024*1024=4 times 512*512, often there is no noticeable visual difference)
-check the file sizes of music, if it is too large the reduce it (read below)
Music files is also another point I have to talk about. For example, I applied a free piece of music that I downloaded to a loading screen. The file size of the music was 198mb, (it was long).
This is ridiculously high. Using
Audacity, I cropped the audio to only 2 minutes long and saved it as an .ogg file. .ogg is a supported file format for audio by FPSC that uses less memory than .wav. The quality doesn't seem to be any different.
I would definitely recommend converting large audio files to .ogg because of the space it will save. Don't forget however, to change the reference to the audio file of the script that calls it, otherwise it will be using the large file size still.
Also another point is to reduce the length of audio if it suits. For example, that music I applied to the loading screen didn't have to be half as long, so reducing it to 2 minutes helped.
-------------------------------------------------------------------
Also,
take look at this thread here. What I found from this thread, my tests in FPSC and etc is interesting. When static objects are moved or added/removed, dynamic objects are moved or added/removed, moved or added/removed, segments moved or added/removed the lightmapping process has to recalculate and be built again. When testing a game using the latest beta, the lightmapping is built, baked and saved. If none of the above changes are made the lightmapping remains the same, drastically decreasing the memory used (for test game). Whenever I test I always run twice. The first time to build the lightmapping, which after the process is done I cancel the test otherwise it will greatly exceed the limit and crash. The next time I test the lightmapping is saved and far less memory is used. What I mean to say from this, is that you're levels aren't necessarily taking about 1986mb, that's just because lightmapping has been calculated.
I'm not sure if this applies to other versions of FPSC, however.
-------------------------------------------------------------------
On top of this, another
thread may provide an interesting read.
-------------------------------------------------------------------
Lastly, when building my game I don't build it the traditional way.
I recommend reading this thread here, perhaps a more comprehensive tutorial on the topic, but I'l explain it in the way that I do it. I discovered this method first and it allowed me to successfully load levels whereas it did not previously, so I can assume this method works better.
Basically, each level is built individually. Once you have, lets say, 5 built levels, I'd usually create backups for convenience (not necessary though, they can just be built again).
Go through each of the folders, go into 'levelbank', and rename the 'level1' file to the appropriate level that you want it to appear at. They will all appear as level1 because when they're individually built they're going to be the first to play.
Eg. for the 4th level, go into its levelbank folder and rename its 'level1' file to 'level4'. Repeat this for all the levels, renaming the files corresponding to where they should appear in-game of course.
Next go into Files\languagebank\english\gamebank\(next folder\ and find the loadingpage1.fpi
Similarly to before, rename this to loadingpage4.fpi, etc, corresponding to the level where they should appear in-game.
Once all of these files have been renamed, merge all of the levels into the first folder. When prompted, merge all folders, don't replace imageblock, but replace everything else.
In the thread mentioned it says to create a level that uses all your media and huds so it can be loaded into one imageblock file. I understand this, but I haven't done it and no errors have shown thus far. However, I do use the first levels imageblock.
Next, go into the folder with all of the merged content and open its setup.ini. Open this and scroll to the bottom of what's written. Where it says, "levelmax=1", change this to the number of your levels, eg. "levelmax=5".
Next, mimic the pattern the refers to the fpm to load and loading page to select.
Eg. for level 2:
levelfpm2=mapbank\level2.fpm
levelfpi2=languagebank\english\gamebank\game\loadingpage2.fpi
Along those lines until everything necessary is covered. This method worked for me! This method has its advantages and disadvantages,
Advantages:
-Allows for bigger levels to be connected without crashing
-Allows for different lightmapping settings for each level (very helpful)
Disadvantages:
-Takes more time and effort
You be the judge.
On one of my levels which happens to be smaller, I use a lightmapping quality of 65 now (this is after DXT1 conversions). On another level that is much bigger, I use a lightmapping quality of 40. With this method of building levels I can adjust the quality to its highest per level. This is as opposed to the traditional method of building levels, where the lowest quality of lightmapping would have to suffice for all of the levels, bringing it down somewhat.
-------------------------------------------------------------------
For others looking to optimise their game I'd definitely recommend to do the DXT1 conversion first, because these other optimisations may not be needed. For example, there may not be a need to reduce texture resolutions if you have a spare 300mb in your level.
If you have any questions don't hesitate to ask. If you have anything to contribute please do, and posts are welcome
Thanks,
Burger
- An Instinctive Fear IndieDB page, download the demo today!
