Sorry your browser is not supported!

Hi guys, been working quietly on my game and like the fair weather forum user I am I only ever seem to crop up on here when I have an issue.

And currently Im experiencing a rather interesting issue, Im not sure if its a bug so I didnt head for the Bug report thread its more something Id like to chat to some folks about.

Basically Im creating a hud based inventory system for this little game of mine and Ive encountered an issue where huds seem to be taking up incredibly large amounts of memory, I mean verging on the ridiculous

As Part of my testing regime I set up a small prefab, populated it with the items I would be testing and a single light source. Watched the little ticker bar on the test game and was informed once it had built that the level used 476mb, which is fair enough.

Now Bear in mind no entities were added and none were taken away during testing, its important.

So I define all my huds in a single script which destroys itself after defining them so its not hanging around consuming resources.

Now as I added more huds the size of the built level increased gradually in relation.

Finishing with a test game of this single room that consumed over 1.1GB of memory, thats almost 700mb worth of memory just by defining around 40 huds, now in my opinion thats unacceptable, each hud is a png around 40-400kb in size and if you multiply that by 40, it doesnt approach ANYWHERE NEAR the 700mb that is being added to the build level, to the point where if I define all those huds in an actual level it exceeds the memory and wont allow me to test build the level and in a compiled game it just crashes to desktop upon loading any level where that many huds are being defined

This is a serious issue, as I have 6 tabs in the inventory and so far have only populated two of them (3 weapons and 2 consumables)

And if its consuming so much memory Im never going to get anywhere near a playable game.

Does anyone have any idea why this occurs? ive noticed duplicates of my huds appearing in the folders as dds images from time to time, these must be being created by fpsc as I dont work in dds, ever, and the average file size is around 2-3mb, so my hunch is that fpsc is taking my png's, turning them into dds without any form of compressin in place, then substituting those horrendously huge files in place of my nice tiny pngs, the end result being way too much memory is being consumed.

I cant seem to find anything on this anywhere else, does anyone have any idea what is causing this memory leak or how I can stop it?

Its getting ridiculous now.

I have a hud-based inventory system created and it has 85+ huds and I never cap out. I too work in PNG format and do not use the DDS for my huds.



The reason huds are created into DDS is due to the engine and a setting (Preferences>Texture Quality>. Setting to "high" tells the engine to "convert" the images from your format (png) to DDS. I keep mine set to "medium" and my PNG huds never change or convert.

Another thing to check is the following in your "setup.ini" file...



If you set the "lightmaptexsize" higher, some systems will cap out. I found on our desktop if I use "1024" I cap out, but "512" or "256" keeps the build smaller and I never have had any issue. Again, depends on the system and setup.

FYI, if you create a new level, lay 9 ground segments down in a square pattern (3x3), place a start marker- that level will use 630 MB automatically. If I change the ground to use a room segment and make that area a "room", it used about 650 MB. You also have to remember that the engine will use "virtual memory" so you will need to know what your system has for VM.

Just for a comparison- our desktop has 4 GB RAM, 6.50 GB total virtual memory with 1.45 GB VM available. My one level of a development uses the full grid, is "outside", with inventory system (and huds), characters (spawning at appropriate times when needed) and it reports 1289 MB used. On a second build attempt of that first level it drops to 1084 MB. Other levels in the same development fall in around the same amount.

Ahh it will be the high quality textures, which In all honesty I could probably set to low if it wont affect the HUDs quality, I use a single texture map for everything in the game just one 512x image containing a colour map with like a hundred or so primary colours, since the games goin for a cell shaded look it was an easy cheat to keep the file size down

The light map tex size is at 256 and I run it at pretty much half the recommended values of the default setup values as the lower quality map looks a lot better since theres no real bump map or normal map relief to the entites due to the way they're textured the lower the light map quality and attenuation etc the better the result in the end game, the only thing I really keep high is an shadow settings.

Thanks for the help this is really going to keep the project alive, I was about to give up since im trying to create a rather complex rpg system some what similar to fallout, and the bizarre thing is that incorporating all the variables for things like xp, enemy turns, inventory slots, inventory pages etc was simple compared to overcoming this rather mundane memory capping issue

On the plus side after posting the original post I did manage to do a lot of optimization with regards to the huds and duplicates and scrunching down layers so two images become one etc so with that and the information so kindly provided I should be armed and ready to do battle once more!

Amusingly Ive used fpsc for almost 9 years and for the most part a battle is what it usually is, but I just cant let it go, its got something about it that just keeps sucking me in



***EDIT***

So I did some digging and the level itself is using 1501mb without the huds and exceeding 1.85gb WITH the huds. Now the Imageblock fpsc is creating for use with the compiled game is 18mb big, textures set to medium, lightmap set to performance, lightmap tex size is 256, quality is 15, so im not sure whats going wrong here

but for around 18mbs worth of images fpsc is creating over 300mb's of data and it seems to be eating into the level cap.

Having taken out the script entirely and seen the resulting changes I can only think its the HUDS that are causing the problem

Wether it seems to same the dds files to the imagebank after it creates them or not, it seems to be making that conversion on the fly to load them into memory as temp files and then unloading them once done?

Im not overly familiar with the fpsc source or anything so this is purely speculation on my part but i cant see any other reason for it using so much memory.


As a test I repeated your suggestion of a 3x3 with a single light and start marker and first build reported 480mb, second pass dropped to 461mb, adding in the hud script attached to a stock ww2 radio entity skyrockets it to 869mb this doesnt change if built a second time after adding it in, so for an imageblock that fpsc condenses to 18mb its generating 408mb of additional memory

That just seems insane to me, and a really REALLY big limitation on the number of huds a level can support.

are there any tricks to defining huds?

This may be a dumb question but its been bugging me that I havent been and tried it yet simply because of the hassle, but could it be that Im defining them as hudimagefine= rather than simply hudimage=?

Im not saying that excuses the horrendous amount of memory the huds are using but im wondering if that might be the cause, i shall investigate..


***Edit the second****

Hudimagefine to hudimage did absolutely nothing. no change.

Im not even adding all the huds the game is going to require and its already proving too much. there has to be something I can do.

Can I define a hud and then unload it from memory once its been displayed?

It would be work scripting the hudreset,hudx etc everytime I want to display a hud but if defining them all at once is going to cause this many problems I cant see any way forward from here

Super Super Sad Face

By specifying the imageblock, you must have your setting "imageblockmode=1" whereas I do not use that feature (mine is set to imageblockmode=0). I was never happy with how the engine did formulate the bin file for textures and such. Bear in mind (and I forgot to mention) that I do work in an older source of the engine (v1.17). My post prior was a test in both a vanilla v1.17 and my rewritten source of v1.17, and I never cap out nor do I have issues with the number of huds or what you have outlined. The only time I can cap out is if I change my "lightmaptexsize" higher than 512.



There is something to look at which I forgot to ask. Your inventory script- does it exceed 350 lines? If so, that will be an issue as FPSC has a script cap (unless they removed it). Scripts and huds are loaded when each level loads so they are residual during that run. In FPSC scripts, only the script that defines the hud(s) has control of those huds and when the script is done, it will stop. The only way a hud you called prior to come back is if another script defines it and is waiting to be called upon. I do not have a script cap in my source- I removed it to allow for my inventory system script (which counts up to 405 lines). However, I incorporated my inventory script into my "setuplevel.fpi" script for the developments, since inventory remains consistent throughout the game. My health huds and game menu huds are using "hudimage", whereas all my inventory huds use "hudimagefine". Since I can only swap out my "setuplevel.fpi" with a generic one to test for build size, it appears my build will drop only 100mb with the same level and no inventory system (script) versus same level with inventory system (script). The only spot I use the "hudreset" command is when I use my own defined health huds- the health hud changes color when the player's health drops at specified levels and therefore I have four of those defined in the initial setup. The command needs the "reset" to clear out the old one before showing the replacement one.

I like to use PNG to keep final package size down. While some will say DDS is better, I have done tests to see that when it comes to huds for text (such as conversations, notifying player of something, etc), there is no difference between the DDS or the PNG with the exception that PNG is smaller in size. Again, that is in my version, which I spent considerable time rewriting just to get it where we like it.

In your "Files\levelbank\testlevel" folder is where the level is "constructed" for playing and testing from editor. There is a second part located in the "Files\mapbank\testlevel" that is used when you click on "test" from the level editor and it will reference the constructed level from the first aforementioned folder. Sometimes I "flush" that "Files\levelbank\testlevel" folder out (including the "lightmaps" contents), open FPSC, load the level and run a test, cancel, then run a second test without "flushing the folder" and the memory used is a bit lower.

FPSC is a tricky beast at times. Sometimes I can fire it up after being away a week to load the last level I was working on, run a test, and it crashes on the first attempt; reload it and try again and it is fine. I also run VMWare in the background to test my game builds so I know that I am actually running with lower virtual memory than most. But I keep my settings on the lower scale, no imageblock, no bypassing the cap, no shaders (although one dev I do have the shaders on), and no high textures. I do have water and other features I have put into my source and it runs pretty good considering the old equipment I use.

Hmm you raise some interesting points there.

Im pretty sure my actual inventory script doesnt exceed 300 lines, Id have to check but I noticed irregularities If the defined state exceeded double figures so I limit my scripts to states 0-99.

The huds were being defined in a script that was attached to a stock ww2 asset outside of the level, it would define the huds and destroy itself.

Im not entirely sure whether I understand the method your using as you said you only use ''hud reset'' to clear out the previous version of your own hud, does that mean you are calling the same hudname so you are resetting it so that you dont have to define 4 different hudnames in the script that calls the hud? so that the if your calling hud health and the health changes your specifically resetting that hud with a different image but the same hud name?

im using v1.20.18 or 19 i believe, since I wanted a lot of the features that were previously only available in mods to make my game function the way I wanted it, it seems there is some sort of inherent issue with images tho since it shouldnt be exceending 400mb of memory used for 16-18mbs worth of images, now the interesting thing here is I tested multiple times, removing somewhat unneccesary Huds from the intial hud definition script and got it to stop capping out on my system, now im on xp 2gb ram and a 512mb gpu right? Now I send it to my girlfriend to test, the exe crashes on loading the level that was previously capping out, yet she has 4gb of ram to play with, is there some sort of inherent memory cap that the engine is applying regardless of the hardware available on the target machine, and why would a seemingly inferior machine be able to handle it when a more advanced one doesnt, she can run fpsc games fine, she has test hundreds of my alphas prior to this but for some reason its proving to be an issue, what I may do is drastically reduce the size of my levels and have fallout style loading screens and use the level jump script to jump between areas.

Going back to what you were saying about dds and png i agree png is better, i used to use dds and manually compress each image but I noticed gimp wasnt exporting opacity properly or fpsc wasnt reading the opacity in the dds correctly but switching out the same images to png seemed to rectify this

Its an interesting issue and no mistake and from the way testing has been going it doesnt seem to be something Il be able to fix any time soon.

On the subject of image blocks I thought the same last night, turned them all to 0, fpsc still went ahead and built them anyway.

On a side not it kept throwing errors up for her at first related to the imageblock specifically last night which is what prompted me to try without, it kept saying it couldnt load a hud but the huds it was having trouble loading changed each time the error occured.

Ive already reverted back to a previous build that Id saved as a back up and brought it up to parity since the original fpm became corrupt and Im wondering if at some point prior to backing it up something went wrong that just wasnt brought to the foreground till I started piling on the things the memory needed to cope with.

I'll attach the latest build of the affected level to this post if you want to try and download it and see what happens when you start a new game (the title menu loads fine which is actually the first level its the second level crashes upon finishing loading)

Here is a snippet from my setup script...

Defining health huds


Script checking player health and displaying the corresponding health hud



According to the script syntax...



If I did not use the "hudreset" in my script, then my health huds overlap one another. By this method, it clears the first hud and then displays the new one as intended.



I tried it out, and it seems to get to the last part of the loading bar in the second level and wham... the famous "FPSC has stopped working" error. Swapped over from the desktop to my wife's laptop to try on there and same thing. That one last spot on the loading bar. It's too bad FPSC developers did not think of using a better method to "log" so one can know roughly what is the cause.

I been keeping an eye on the thread and noticed you having some issue with memory and capping out on your system.

I did try your demo level and it did crash for me, i think this is where its loading the decals but hard to say but it somewhere close to that.

I did notice you said you was using v.20 beta 18, this in fact has a major editor bugs so its best to use v1.20 beta 17a.

I'm not sure why your games hubs are using so much memory and would need to think why this be the case but the problem with fpsc is it does load everything into memory and that's why it usages so much memory for a single room but the good thing is that it reuse the textures again so the memory use can be a lot less on top of your hubs.

nomad and myself are working to up the cap in fpsc on top of the 0m and very low lightmapping all ready in Black Ice Mod.

best s4real

There is no chance the huds are causing that much increase in memory used for building. He is using PNG (just as I am), is running only 40 huds (whereas I have over double the huds in my inventory system). If I build with my script system(s) in place and then build without them, the overall memory size difference is approximately 100 MB max between the two. If DDS was only being used then possibly that would contribute given you can have large DDS file sizes.

There has to be something else that is eating at the memory- even with my rewritten source huds and scripts do not use that much memory in relation to the rest of the build process. Unless something in the source (from v1.20 to the unofficial versions) has changed where displaying huds and scripts suddenly has priority to consume more memory than actually needed.

Right Im back

And Im sorry to say it But It DOES seem to be the huds. Emphasis on SEEM, I removed the scripts relating to the huds and dropped around 400mb on the test levels, when built into the level that was causing the issue it was capping out over 1.85gb, now that same level runs at 1051mb with those scripts removed, or more accurately drastically altered.

Which leaves me at a loss as to what the real cause is, I totally agree a logging feature would have been fantastic everytime I see that error I just feel like screaming 'Give me a file name, a variable name, a script name give me SOMETHING!.

Reading your post did give me an idea though, you say your using hudreset to clear out the huds between each one being displayed, which im assuming requires the level to have been loaded and is in play for those actions to be possible.

Now what ive been doing and may be where its going wrong is simply using the hide and show commands. So I just suddenly thought, in terms of the engine, since im using those commands... IS EVERY Hud permanently on screen at the same time and just been hidden or shown when needed.

Whereas your script does practically the same thing but only the huds being used at any given time are being drawn to the screen whether hidden or not? If that makes sense.

if its not that then what really supports my idea that its huds is that im not actually using any decals as s4real suggest. But the real killer is I went overboard remaking the battle menu system and inventory system and ripped out all the huds relating to that bringing my hud loads to around 20 huds per level. Instead of huds
Im now camming to an entity and have made all the menu buttons and backgrounds out of 3D objects in very much the same way as my 3d title menu, so the entity cam just sits there pointing at these objects til the battle scripts are called at which point the players cam is swapped for the entity cam to view and control the battle then swapped back after the battle (Since I couldnt get the buttons to link to the player properly, they were going to just constantly be there but hidden til battle started but I think doing it this way makes for a better battle system and allows me to randomize the enemy encounters)

Now in theory having upwards of 10-15 always active dynamic entities active always should be more demanding on the engine than loading 20 2d flat images, but the evidence doesnt bear that out.

It appears to be INCREDIBLY more efficient for my build to do it in this fashion rather than defining the huds which are taking up the memory.

Im not a source modder so I cant say anything for certain but as far as I can see the evidence is thus, removing the huds frees up around 400mb, replacing them with 3d models actually made the data loaded into FPSC SMALLER than when using huds, and the script crashing the level was tracked back to that specifical script (ie when its removed from the build everything goes smoothely)

I cant imagine its my custom media based on the evidence I have, espscially since the script causing the issue was also attached to a stock asset rather than a custom one.

I'll attach the redone 'demo' to this post with the new 3d menus, like I say Id have thought doing it this way would be way more memory intensive but the evidence just doesnt bear that out.

Either way Im avoiding defining more than 20 huds regardless of level size from this point onwards, and for the last few days that seems to have been the trick.

Also I noticed since I stopped using a single hud image for each digit of a numeric and instead using the numeric definition commands attached to a variable and used to draw that variable to screen has reduced the hud usage greatly for displaying quantities.

Its strange. Maybe just related to my machine but I just cant come to any other conclusion than my pc just doesnt hold huds well if you guys are convinced its not the engine.

But yeah heres the updated version in this post.

OK After being on the verge of giving up I installed Black Ice mod and the result was just amazing, reduced the build memory at portal stage from 500mb to 360mb! which I havent tested yet with all the huds but that should be more than enough memory to allow for them to be reintegrated thanks to the super effiency and optimization the mod seems to do to fpsc Ive attached a test copy Ive been using similar to the above one where the run button is disabled and player takes no damage (its kinda a testing version so dont take it as representative of the final game) but the sheer difference in quality between the unmodded and the modded versions are unreal!

Windows 8 users will need the same extra dlls in the game directory alongside the exe as the modded editor does to function and can be downloaded here for anyone not using the black ice mod

https://forumfiles.thegamecreators.com/download/2518476