@jcl:
1) "Of course ent_remove is slower than ent_morph because ent_remove releases the clone, which is just what you asked for."

leads to==>



So this will result in a memory leak (As Morph does NOT release the cloned memory and ent_remove will release most probably only the last vertex buffer)? In this case I think it should be mentioned that the morph and clone instruction should not be used on the same entity..

(or is ent_remove "smart" enough to detect all cloned previous buffers?)

2) Is it possible to do release the mesh and the corresponding vertex / index buffer (returned by ent_getmesh) for non animated entities on your own?

No, ent_remove does not keep a history of previous clones. So, cloning the same entity multiple times will generate orphans, and we'll mention that in the manual. But it should be sort of obvious anyway.

For gods sake! Is it really that hard to answer my question!

I may be whining, but I AM behaving like a programmer.
I am looking at ALL possible avenues to solve my problem.
But obviously no-one wants to help me determine the validity of
THIS particular avenue...


JCL: I KNOW there are other ways to solve this issue. Probably BETTER ways.
But Im not askling about them. Im just asking is there a way to release the
cloned entity data WITHOUT releasing the WHOLE entity?

I understand WHY ent_clone & ent_morph are consuming memory as they are.
And I dont disagree with it, nor do I think its a bug. Its fine.
Im just looking for a POSSIBLE way of bypassing it.

Ent_remove being slower than ent_morph is obvious, as is ent_morph creating
orphans if used un-wisely. I dont feel the manual NEEDS to explain that.
It was pretty obvious to me after one test run.


There are obvious solutions to my problem... YES.
There are simple solutions to my problem... YES, to a degree.
But I prefer to examine all the POSSIBLE solutions that I can think of,
before deciding which to work with.

And so this discussion... it is all about ONE possible solution.
I was asking for help to see if it was POSSIBLE to be of use to me.

BUT ... seeing as no-one wants to answer the question, Im going to write off
this entire discussion/thread as a WASTE OF MY BLOODY TIME... and hair!

!! CASE CLOSED !!

I'll see you guys around once Ive cooled off a bit.
I apologise if Ive offended anyone... no hard feeling OK?

Ok, I see now - the original question was just if the allocated memory can be released without ent_remove. The answer is no, so either ent_remove or not cloning is required.

I feel like your ignorance wasted OUR/ my time, not yours. To me it has been pretty clear since the beginning of the thread that you need ptr_/ent_remove to release the memory, and all this talk that the provided solutions are "NOT ALLOWED" is nonsense. The memory problem should occur on the day that you've written this code which means that the rest cannot be a full game yet, only a rather simple prototype. Using ents[i] as a pointer and not a "direct" reference is a very easy solution, you're just being stubborn here.

Thanks JCL, a lot. Thats all I was looking for.

I guess my original question got lost in my over-simplification,
and later by my ranting... Sorry.


Superku:
My ignorance is obvious, otherwise why would I have asked the question?
The best way to resolve my ignorance would have been to supply a simple answer.
Just because it was clear to you doesnt mean its clear to me.

But no one did answer the question. There were plenty of good suggestions,
but none dealing with the ACTUAL question.

As for my "not allowed" nonsence... havent you ever has a task to do that had
some form of limitation on it? Thats what 'not allowed' means.
I was trying to limit the number of solutions people would give me so
that the answers they gave fit the scope of my needs.

Phrasing my question better may have helped, but I didnt know a better way.
So I kept trying, and still got no answer, and got frustrated. My bad.

As for this fault occuring on day-one... never going to happen.
Im not capabale of writing a fully complete project on one day,
especially one this complex. So I do it in stages.

Up till now, the entities have been static place-holder entities.
Now Im 'morphing' them to reflect underlying map data, so the ent_morph process
in only now being implemented. All the other entity handling is already done.

Its that 'other handling' that contain the 'direct' references, and there
is quite a lot of it. YES, I will be fixing them to use array references
IN THE END, but not yet. Ive got this morphing proof-of-concept to deal
with first, then I'll go back and 'tidy' older code.

So YES, I am being stubborn. Live with it or ignore me... your choice.
Normally it doesnt get in the way of my programming, normally anyway.


So, regardless of how I may have responded to individual posts, I HAVE
been listening to all the suggestions made, and am considering many of them.

I'm curious, what are you using this code for in the end? Do you have a grid of entities that are used as the visible tiles in a bigger (let's say) var array?

Got is in one ... nearly. As I would expect of you.

Its being used on a grid of 'visible' entities that are the tiles in a
much larger array of custom-structs.

Have a look at Esper's latest post in Projects|"What are you working on?"


The grid is fully populated with null-entities after level_load.
Then the array gets fully ent_morphed with map-data defined models
by the map_load function, or a sub-function thereof.

Then as each row and/or column gets beyond a set 'distance' from the camera,
the entitys in that row/column gets physically moved to the opposite side,
and then ent_morphed into its 'base model' correlating to its new XY position
within the master map-grid. The model also gets rotated to an sppropriate PAN
value at this point. (to reduce the number of MDL files we need to design)
Then the model gets its 'edge' vertices 'stitched' to its neighbour, using the
XY positions of the neighbours matching vertex.
Now you can see why I WANTED ent_morph and ent_clone to work together.

Thats was the plan IF my question had been answered with YES...

This attempt was following my previous one which was using ent_remove & ent_create,
when a slight lag was noticed when scrolling a row AND a column. AND I havent
even implemented the 'stitching' process yet.
I cant afford ANY noticable lag at this early stage because this projects
'mapping system' is only at a 'framework' stage so there is so little cpu-load
at this time I should never get ANY lag. Otherwise it will just get worse later.

Thats the primary reason why I was looking to avoid the ent_remove/ent_create process.
There are other reasons, future reasons, but they can be worked-around easily.

So I think I will soon go back to the ent_remove/ent_create process, and
figure out some way to buffer the ent_remove's (and maybe ent_creates too)
in order to 'smooth out' the cpu-load-balancing so there will be no
significant lag, even later when more game-mechanisms are installed.

Ok. Well as it obviously doesn't work great that way, let me make 3 suggestions:

1) Use a big var/ int array that contains the value/ type of every tile in your level, f.i. a 200x200 array. Then create only a small array of entities, maybe 20x20, which make up the visible part of the level. The entities have the appropriate model file according to their position and the var array value. If you now move the camera, f.i. to the right, you only have to morph one column (or none) because you can replace all other columns by simple pointer arithmetic (I mean create the entity field array out of column arrays and replace their indices in the field array).

2) I don't fully understand why you would need to manipulate the meshes and thus need to clone them. The tiles could easily be created this way that they perfectly fit together. If you need a little more variation you can manipulate the vertices in the vertex shader depending on their world position (using sin/ cos/ ...), that's what I oftentimes do in my game, it allows me to stitch entities together easily and animate them seamlessly.

3) As you don't need any collision detection for your game, you can try to set collision_mode to 0 (before level_load) and hope that entity creation gets faster (because no collision mesh should be calculated then).