enough ptr_remove?

hi
I have a question.
BMAP* b1=bmap_create("test.bmp");

ptr_remove(b1) is enough to free memory or i have to use bmap_purge(b1) first?

its all vhat you need.

Thats right.

bmap_purge is seldom used.
It is mostly for memory minimisation by 'freeing' video memory used by
'seldom' access bmaps.

BMAP_remove is for 'truely' removing a bmap. I it does a bmap_purge during the remove process.

PTR_remove is for removing any object. I BELIEVE it will do a bmap_purge as I understand it...
I THINK the ptr_remove checks what type the object is, and then performs the
appropriate '???_remove' process. (ie bmap_remove, str_remove, ent_remove, etc)

BMAP_remove dose not in 3dgs help.
is it a 3dgs command?

"bmap_remove(BMAP* image)" is a command, but its name is all lower-case...
I just put the 'BMAP' part of its name in capitals so it would be noticed.
bmap_remove has been around so long, I cant remember how old it is,
but Im pretty sure all lite-c versions have it.
!!BUT I COULD BE WRONG!!

[EDIT] After a bit of digging... I have discovered that bmap_remove was A7 ONLY,
and has been dropped entirely from A8... How did I not notice this?!?
It does not even exist in the obsolete syntax section of the manual...
Ah well... you learn something new every day...

And it goes to show how me using ptr_remove all the time for ANY
3DGS-object can be both a blessing and a curse at the same time...

what about entities?
i test and seems ptr_remove dosen't enough for free memory.

I dunno for certain, but I believe it is OK.

Entities can be decieving because of the way acknex 'recycles' the memory they use.

Often you will completely and correctly remove an entity and all its resources,
but only a part of that memory get given back to the OS.
BUT, acknex will re-use that memory later even though there is no known (to me)
"user accessable" way of knowing the memory is currently sitting in
acknex's recycle bin... Its all to do with the way the nexus is managed.
(NOTE: When the engine exits, then ALL the memory is returned BTW)

To be able to test a similar problem with entities some time ago, I had
to set up a script that created around 100 entities per frame for about
10 frames, then remove the 10 oldest and create 10 new ones every frame.
This made the engine hover at around 1000 entities constantly being created,
living for 10 frames, and then being removed.

When I ran it the first time, it shocked me by climbing to nearly 700 Mb usage
in less than a minute... but then it dropped down ... and spiked to 800 ...
then dropped again ... and EVENTUALLY stabalised at around 400 mb.

This was with some very system-hungry models BTW.


So if you set up a script similar to mine above but use ptr_remove instead
of ent_remove, you can give it a valid test....
Set it running, stare in horror for the first minute, then walk away from it
and make a cup of coffee, or have a smoke (IF you are a smoker of course).

You could also set up a counter to register HOW MANY entities have been created
so far... That will make you feel better.

But in a nutshell, if it eventually crashes, there is a problem, but I
suspect that it will work fine, barring a few 'spikes' here and there.

there is a way to free memory and you can see it in taskmanager:
at first i have a model that has a 2048*2048 dds texture that make model size to about 4 mb.
so my code is :

///////////////////////////////
#include <acknex.h>
#include <default.c>
#include <mtlFX.c>
///////////////////////////////
ENTITY* e1;
function rm(ENTITY* e2)
{
BMAP* bmap_temp=ent_getskin(e1,1);
if (bmap_temp!=NULL) ptr_remove(bmap_temp);
bmap_temp=ent_getskin(e1,2);
if (bmap_temp!=NULL) ptr_remove(bmap_temp);
ent_purge(e1);
ent_remove(e1);
ptr_remove(e1);
safe_remove(e1);
e1=NULL;
level_free();
level_mark();
}

function main()
{
level_load("");
wait(2);
level_mark();
e1=ent_create("CAM1-PAINT.mdl",vector(1000000,0,0),NULL);wait(-0.5);rm(e1);
e1=ent_create("......
and 40 lines like above for 40 other entites like that
}

I found the main code is level_free() and level_mark(). without these two ,memory increase a lot.


why there is not a command to delete a entity and free it's memory?
how can i check that my code free memory when engine , don't show me that.

What you see in taskmanager if the amount of memory the application 'owns'.
It is not necessarily ALL in use as far as the application is concerned.
It can hold memory back from from the OS in RESERVE for it to use.

Level_free releases a set 'chunk' back to the OS when you tell it to.

Level_mark SETS a point in memory. When you then do a level_free, then
everything created AFTER that mark will be released.

Level_load releases it ALL, and starts afresh.

These three level_? commands are manually controlling the nexus, which is
the primary 'level' space used by the engine.

If you dig far enough back in the 'Ask the developers' forum you will find
a large discussion/argument between me and JCL on this issue, because
I wanted the nexes to be 'manipulatable' in the way you seem to.
THIS WILL NEVER HAPPEN!

In a nutshell, handling memory 'that way' is in-efficient and CAN add serious
cpu-overhead given commonly-occuring cercumstances. So JCL just isnt going to
go there. End of discussion.

BUT, the memory handling as it is now is more powerful, and more flexible than
is stated anywhere by anyone. And IF your situation allows you to actually
use level_mark etc, then it makes life very easy.


But ... if you cant or wont use the level_mark/level_free functions (like me)
then you are largely on your own, flying in the dark.

If you want to do MICRO-MANAGING things like checking if memory from a removed
entity HAS actually been freed, you need to write your own test routines.
There doesnt seem to be any way of telling the truth from looking at any of the
'system' variables that SHOULD report this information.

Maybe there IS a way, but Ive never found it, or anyone who knows it.


Do me a favour... Run the following script with your entity in place of
the "BLOB.MDL" in the 'ent_create' command. And tell me what happens...
And leave it running for 10 minutes if it can...

@EvilSob:

no it does not. level_free releases memory, that's true. but it releases this memory only to the engine/nexus
the nexus is some preallocated memory with a specific size
the engine itself does some really simple memory allocation algorithm which can't release any previously allocated memory. that's why you need level_free and level_mark. this is just some easy freeing of memory, but not releasing to the OS

it crash "script crash in lifetime "with this data:
counter=210
nex=25
mem=818
free=1202

i made a studio that player can select a car between 40 diffrent car.
each car size and it's part have 16mb and palyer can select bodypaint for his car between 210 body paint(2048*2048 dds texture)

now i have problem.if player want to see some cars and some bodypaints,memory will be full.

i need some advices.
and please some one show me a code for sys_malloc and sys_free for using with ENTITYs.

MasterQ32:: Yup, you are right. I just over-simplified my poor understandings...

flatron:: Try my code again, but remove the ent_clone in 'lifetime', and
see how much of a difference it makes. The ent_clone part is an EXTREME stress-tester.

THEN, if it is still crashing, try increasing your nexus with the '-nx'
command-line option in SED/Options/Preferences.
Check the manual for detailled help.
This may not help at all, it might be your VIDEO-memory is overflowing.
If this is so, Ive never hit this issue, so I cant help at all.


I cant help much more than this, because even with my most detailled models,
1000 of em are only hitting a nexus of 6. I aint much of a modeller...

As for how to use sys_malloc with entities??? I dont even think is CAN be done.
But FOR YOUR SAKE hopefully someone will just tell me Im an ignorant dumb-ass!

one suggesstion use "process hacker"(it has a system information part)
without change in nexus: counter=560
with -nx=500 : counter=560

it crash in both time



if there is no way to free memory ,it is very bad.
i spend 1000$ and buy an engine and now at the end of a 12000$ project a problem occurred an there is no way to solve it?

and a question : i can't use sys_malloc for entities?

God no. There will be a way around it, its just "I" dont know the answer.
Im sure someone else will, given time for them to find and read your problem.

I 'discover' how to do stuff ONLY when I hit that problem myself.
And I have never dealt with multiple large textures like you are doing.
So Ive never NEEDED to solve this problem, thats why I dont know how.


But back to the issue on hand..

Did you take the ent_clone out as I suggested? It more than doubles memory usage.
And when it is crashing, it IS showing 210 models isnt it?
And were they all with the SAME skin? Or different ones?
How big(roughly) is the MDL file IF it contains the DDS skins?
OR How big(roughly) is each DDS file, and how many are used per model?

yes ,i hope find an answer to it.
thank you.

above result is for time that i comment ent_clone.
when it crash(in case of comment ent_clone) it show 560 with same skin.
model size is 3.78mb
and dds file are about 2 mb

Well, to be honest, I cant see any REAL problem.
How often are you going to be racing agains 560 other cars at once?

The memory consumption really only applies to what is ON-SCREEN at the same time.
Everything else can be managed swapping models and textures in and out as
we need them on screen.


So... lets roll back a bit and take a FRESH look at what you are trying to do NOW.
Lets go back to the studio, you have 40 car types ATM I believe. Not a problem.

Is there any way you can fill me in better about the 'base' car models...
Can you send me one? Or even a screenshot would do.
Im trying to figure how much of its 'built in' texturing is 'necessary'.

Does the MDL contain ANY of the bodypaint texturing?

Could you post a (JPG) screenshot of its various textures?

The reason Im trying to better understand the models skin layouts is to figure out
which textures get swapped/replaced when you put bodypaint on them.


The basic concept I have for the 'mechanics' of the studio is this.
We have 40 car types, so at studio start-up we create an array with one of each.
After each ent_create and shader-apply we set each car invisible and then do an
ent_purge to minimise memory usage.

We then display the first car on-screen. When we 'scroll' to another car then
we need to do an ent_purge on this one after setting it invisible.

While a car is visible, you can scroll through the bodypaint skins.
Ptr_remove the existing one and bmap_create the next one as we scroll through.

Thats the BASIC mechanics of it. Can you see any STRUCTURAL problems here?
Problems that may interfere with your Studio design?


Also... do you have 210 bodypaint skins PER CAR?
Or is the 210 spread across all 40 car types?


PS you can start a PM with me if you want to keep things private/confidential.

thank you EvilSOB.

i have no problem in loading and showing models and skins.
the problem is occured after i do it for more than for example 40 times.

but I am working on it.

OK. Then it sounds like as you are loading models and/or skins that
have been visible at some point are 'piling up' in memory somewhere
and eating all your available space.

In that case, I would suggest using ent_purge and bmap_purge to flush them out.
As each model becomes "not visible any more' because your studio is viewing
a different car, then perform an ent_purge on the model that WAS visible.
This will flush the model from memory.
This MIGHT also flush its skins but Im not sure... It SHOULD at least flush the
skins embedded in the MDL file, at least I would EXPECT it to.

Then for any 'bodypaint' skins you have loaded to view on the model,
as soon as any one of these skins is no-longer visible, do a bmap_purge on it.

Following these steps sould keep your memory usage down.
The drawback of doing it this way is that EVERY time you change models or
bodypaint skins, the engine will need to reload that skin/model from disk.
If they are big, or a slow machine, this may cause a 'lag' as the file loads.

Also... doing a ent_purge or bmap_purge EVERY time a model or skin is changed
is probably rather overkill.
If you can figure out some form of counter system, you could probably get away
with only doing your purges when you have scrolled through 10 or so models/skins.
But this would take a bit of trial and error to find a healthy balance.


Best of luck all the same dude.