memory usage

TheElk · 02-03-2014 09:39 PM

Hello Esenthel

Or anyone else we are having problems with editor 2.0 when programs are built or published our memory usage since of lately. when publishing or building our games the memory usage keeps going up. We thought it might be something that we did but we try ed Bloody Massacre and its memory usage is doing the same thing as you fly around the game it keeps going up and up.

can other please try Bloody Massacre demo and see if it happens to you

Any confirmation or help would be great.

Thank You
TheElk

TheElk · 02-04-2014 12:58 PM

ok I made a video showing the memory going up in Bloody massacre hopefully this will explain what is going on, Watch task manager bloody is the 3rd one down.

it is better to watch on youtube in 720p

thank you

TheElk

rstralberg · 02-04-2014 01:15 PM

Definitely something going on with the memory there. Could it be some memory not released properly when leaving terrain areas?

Zervox · 02-04-2014 01:56 PM

I've always noticed this issue with EE, although not in this extreme case of increases. rather the issue I've noticed in the past is that it never seemed to unload area data properly/completely. eg program can be with empty areas and you can move endlessly and the memory would never be freed of earlier areas(eg even if areas are empty the areas structs are being allocated), This has and is the case since 1.0, could you check the demo with WORLD_FULL instead of stream and set the active range to cover the entire demo world? would be interesting to see if it doesn't unload any areas or if there is a major leak in area loading/unloading.

Just tried bloody massacre and I did indeed notice it although I was already up over 1GB memory usage in a matter of 1 min flying around the world, moving far out of active area range made it go down to 267mb going back it was instantly up to 700, quite a difference from the starting memory usage of about 190MB, also every time it unloaded or loaded memory(approx 100mb difference)after 500mb it would choke my computer completely for a second.

gwald · 02-04-2014 04:05 PM

well, it was never a performance demo pfft

Also you're not meant to fly in it.
I'd say that memory usage is normal.

I'm guessing it's loading all the meshes and textures in view, which is everything!
That's why we have a draw distance and fog to work within the limits of ram pfft

In your game, is it in a particular area?
Is it a wide open space with a lot of meshes and textures?
You can do a few things, ie try braking up the world into something like zones/areas (not too small but not too big, ie 1/4 of a level) then test if the whole area is in view, if not, the whole zone doesn't go to GPU maybe removed from GPU ram also.

If your level needs a high draw distance, then you'll need to swap out your high res-models/textures with lower ones and swap them back when the camera gets closer.

But if memory is your problem then you'll need to find a more optimised way of generating your models/textures, ie using code to duplicate arms/legs, swapping out colour pallets to save on textures and other fun things :(

You'll need to read the memory section on the wiki, see how 3D objects are handled:
http://www.esenthel.com/wiki/index.php?t...Containers

Also, at your stage you should be profiling GPU/CPU speeds and GPU/System ram.. not really sure how tho

Zervox · 02-05-2014 12:20 AM

EE uses 2D range finder for loading areas qwald so that is not the case. Performance demo or not memory increasing like that in general is bad. It is not normal behavior, afterall turning on WORLD_FULL the game starts with 179MB for me after moving around for 2 min it is just about 200mb not nearly close to the 500/800MB+ I have with Game::WORLD_STREAM

EE also doesn't use viewrange directly as loading/unloading areas he uses activerange which is a 2d computation, it clearly is doing something which it shouldn't, by effect this means EE doesn't compute unloading/loading based on your view direction(which obviously is correct way to do it) but from my knowledge EE doesn't frustum areas. so terrain is rendered regardless as long as they are in active areas. Memory spikes like this is thus caused by Game::WORLD_STREAM affected behaviour problems we are noticing.

**Esenthel** · 02-05-2014 01:49 AM

I can check this in the future, although I sincerely doubt there's anything wrong from the engine side.
The memory usage can be anything from DirectX, Graphics Driver, PhysX, System, Pathfinding.
The engine has no memory leaks, so it doesn't lose memory, just tested this with APP_MEM_LEAKS

Quote:so terrain is rendered regardless as long as they are in active areas

this is incorrect as EE does use Frustum culling for the terrain meshes.

Zervox · 02-05-2014 11:28 AM

All of these parts like DirectX,PhysX,Pathfinding is an integral part you use in your engine, and fine lets not call it a memory leak, but runtime unfreed memory to the extent that memory usage is blowing out of proportion, not to mention the diffferent behavior from FULL and STREAM, is that FULL won't go much above 200mb in memory while stream easily surpasses that and goes to an insane 700-800mb, going into nowhere on the same world will make it go down again, but once it loads 2 or 3 terrain areas again the memory usage blasts up again.

Ok, I was mistaken about the frustum culling.

TheElk · 02-06-2014 10:53 PM

Esenthel

anything yet because we are having a hell of a time with our game on this. we used Bloody massacre as the base for this game that is why i try'ed Bloody massacre to show you the memory problem. I know you should know it because you wrote it.

AS for DirectX, Graphics Driver, PhysX, System, Pathfinding we are not using Pathfinding and we have try'ed it on xp, vista, 7, 8.1 , and different video cards and different DirectX.

This I hope can be figured out.

We are so close to releasing a alpha version of Moobly but this is not going to go over well.

Thank you
TheElk

TheElk · 02-07-2014 12:42 AM

Esenthel

A update I can say we are not having a problem with Exiled Dimensions which is based on the mmo that you wrote so there has to be something that is messed up. any help we would appreciate.

Thank you
TheElk

**Esenthel** · 02-07-2014 10:19 PM

I'm testing this right now

**Esenthel** · 02-07-2014 10:46 PM

Hello,

As I assumed the issue was not in the engine.

The problem was that in Bloody Massacre code, the
AI.save used File.cmpUIntV for idle_motions and attack_motions, while
AI.load used File.getInt for them,

Please update the codes to this:

Code:

// io

   virtual void save(File &f)

   {

      super.save(f);

      f<<time_to_random_animation<<time_to_random_move<<time_to_sense<<time_to_update_action<<time_to_attack;

              target.save(f);

        idle_motions.save(f);

      attack_motions.save(f);

   }

   virtual bool load(File &f)

   {

      if(super.load(f))

      {

         f>>time_to_random_animation>>time_to_random_move>>time_to_sense>>time_to_update_action>>time_to_attack;

         target.load(f);

           idle_motions.load(f, cskel);

         attack_motions.load(f, cskel);

         return true;

      }

      return false;

   }

TheElk · 02-07-2014 10:48 PM

Esenthel

Thank you

We will try

TheElk

TheElk · 02-08-2014 11:32 AM

(02-07-2014 10:46 PM)Esenthel Wrote: Hello,

As I assumed the issue was not in the engine.

The problem was that in Bloody Massacre code, the
AI.save used File.cmpUIntV for idle_motions and attack_motions, while
AI.load used File.getInt for them,

Thank you it works this is why I wanted you to look at Bloody Massacre, I figured you would get it fixed. again thank you for getting this fixed.

we now have a new ERROR not sure if it is on our end or not but here it is.

ERROR

Element out of range

File: "c:\esenthel\bin\esenthelengine\misc/templates.h"

line:94

Thank you
TheElk

**Esenthel** · 02-08-2014 11:38 PM

Hi,

This is a bug in your codes, please use Debugging:
http://www.esenthel.com/?id=doc#Debugging

memory usage
Author	Message