🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

Increasing Ram of the System by playing the game continuously

Started by
17 comments, last by Wyrframe 4 years, 10 months ago
39 minutes ago, Wyrframe said:

@Gautti: try instrumenting the problem; that is, make it possible to analyze the state of the system, so you can identify the issue.

For each of your dynamically-created object types, set up a "live object counter". Increment it every time you instantiate, decrement it every time you explicitly destroy. You'll want some interface to monitor things as well, so you can see the current counts. Watch to see if there's some particular object type which is running away on you (getting higher over time, instead of staying relatively steady or bounded).

It may also be some system resource you're acquiring and not releasing. Are you doing any kind of dynamic sound generation? Opening files and possibly failing to close them under some circumstances? Creating dynamic meshes for your objects and not destroying those separately?

 

Addendum: "slot game" doesn't really explain what it is, or what you're doing. Do you mean slot as in "slot machine", a variety of gambling? https://en.wikipedia.org/wiki/Slot_machine

Thanks for your answer Wyrframe. Actually "slot game" means I am developing the slot game for match objects. Yes i am making for a slot machine. which is in linux and windows as well. There is  no 3D objects and materials are there. I am instantiating and pooling 2D images in the game.

Advertisement

Could you show us what your slot machine game looks like? I'm having a hard time picturing what kinds of objects you need to pool.

Pooling is generally done for objects where creation and/or destruction is an expensive operation at the scales at which you need to do it; so you just temporarily inactivate those objects instead of destroying them, storing them in a pool to draw upon later.

RIP GameDev.net: launched 2 unusably-broken forum engines in as many years, and now has ceased operating as a forum at all, happy to remain naught but an advertising platform with an attached social media presense, headed by a staff who by their own admission have no idea what their userbase wants or expects.Here's to the good times; shame they exist in the past.
11 hours ago, Wyrframe said:

Could you show us what your slot machine game looks like? I'm having a hard time picturing what kinds of objects you need to pool.

Pooling is generally done for objects where creation and/or destruction is an expensive operation at the scales at which you need to do it; so you just temporarily inactivate those objects instead of destroying them, storing them in a pool to draw upon later.

Sure Wyrframe, I am sharing you the youtube link for  game please check it. In which the objects are spinning is  pooling and the objects are stopped it is instantiation. After sometimes the instantiated objects are destroyed. Although the memory profiler gets high in texture side and game crashing while continuously playing. so what will be the solution ?

 

2 hours ago, Gautti said:

After sometimes the instantiated objects are destroyed

So you are instanciating objects dynamically and destroy them; check if this works well and your objects are really destroyed properply

2 hours ago, Gautti said:

Although the memory profiler gets high in texture side

This sounds like you use very high sized textures and have low/no dedicated VRAM in your mashine. This could explain your high memory use when anything is placed in RAM instead. If you create a GameObject and attach a texture to it (otherwise you would not be possible to use the texture without a GameObject under the hood) the texture will be placed in memory for rendering and stays there while the object is alive. If you instanciate objects and never release unused ones, you will never remove unused textures from memory and your game gets bigger and bigger by playing it.

Also you should use some optimizations like TextureAtlas; depending on your settings, for every texture you load there will be mipmaps created. This are additional texture instances in other qualities so when zooming in/out the graphics API will replace those textures with the matching mipmap level (like LODs when using 3D models). This however consumes memory too. Uisng a texture atlas (placing multiple textures in a new bigger texture next to each other) will cause just one mipmap loop for all textures all-together instead of one mipmap loop for every texture you use.

This is just a guess, without source code it is difficult to investigate your problem

23 hours ago, Shaarigan said:

So you are instanciating objects dynamically and destroy them; check if this works well and your objects are really destroyed properply

This sounds like you use very high sized textures and have low/no dedicated VRAM in your mashine. This could explain your high memory use when anything is placed in RAM instead. If you create a GameObject and attach a texture to it (otherwise you would not be possible to use the texture without a GameObject under the hood) the texture will be placed in memory for rendering and stays there while the object is alive. If you instanciate objects and never release unused ones, you will never remove unused textures from memory and your game gets bigger and bigger by playing it.

Also you should use some optimizations like TextureAtlas; depending on your settings, for every texture you load there will be mipmaps created. This are additional texture instances in other qualities so when zooming in/out the graphics API will replace those textures with the matching mipmap level (like LODs when using 3D models). This however consumes memory too. Uisng a texture atlas (placing multiple textures in a new bigger texture next to each other) will cause just one mipmap loop for all textures all-together instead of one mipmap loop for every texture you use.

This is just a guess, without source code it is difficult to investigate your problem

Hi Shaarigan, Thanks for your answer. Now please look at this uploaded Screenshot in .PNG format. Which are taken in delay of 1 hour continuously by continuously playing my game you can see the minor difference between Textures, Meshes, Materials, Animation clips, Assets, Game Objects in the scene and Total objects in the scene. Although my total system memory usage went from 3.14 GB to 6 GB and this issue cause game lagging and crashing. So please give the way to balance reserve memory , total system memory usage and allocated memory  as well after contimuously playing.

New.PNG

Old.PNG

Do you have or have not a dedicated GPU and VRAM?

2 hours ago, Shaarigan said:

Do you have or have not a dedicated GPU and VRAM?

Yes we having dedicated GPU and VRAM both. Actually we are having Core i3 processor which has  8GB of RAM.

The memory used by the graphics driver, by FMOD, and by Mono did not go up; that means it's probably the Unity scene graph that's overflowing. That at least should help narrow it down.

On 7/17/2019 at 11:39 PM, Gautti said:

So please give the way to balance reserve memory , total system memory usage and allocated memory  as well after contimuously playing.

Instrument it. Count instantiations, count destructions, and look for the classes of objects which are building up over time. Then start searching your code for the reason why.

RIP GameDev.net: launched 2 unusably-broken forum engines in as many years, and now has ceased operating as a forum at all, happy to remain naught but an advertising platform with an attached social media presense, headed by a staff who by their own admission have no idea what their userbase wants or expects.Here's to the good times; shame they exist in the past.

This topic is closed to new replies.

Advertisement