Entity Property Library

Just letting you know I've added a simple entity property library to the code archives. It uses child pivots to store the properties which means that the properties are part of the entity and that means when you delete the entity the properties are automatically cleaned up.

Let me know if you find this useful.

http://www.blitzbasic.com/codearcs/codearcs.php?code=820

Am I right in thinking that it creates a new Pivot for every property?

Wouldn't it make more sense to use the Entity Name of just one pivot?

Reading through it... yes.

I agree. Using a single pivot, with a comma (or pipe) seperated list of properties and values would be the better way to do it. This would mean the properties list could look like this.

delay=50|speed=100|class=transport

Then a function could be used that is passed the property name and gets the value returned (much as it is now)

The idea is good. It just doesn't work as efficiently as it could.

Using this method you could actually by pass the pivots altogether and just use the actual entities name.

But in what way is it inefficient. True, it generates lots of pivots, but it leaves the entities name free to be used for what it should be, doesn't seem to have a performance hit on any entities that use it, and the speed of FindChild is I am sure faster than parsing a long string as you have to parse the entire string in a linear fashion - the example creates 3000 properties for the cube and can retrieve any property almost instantly.

It also has the advantage of being able to allow array style properties in the new version i am working on.

I like it. A HideEntity operation on the created properties pivot may be even more efficient in regards to Blitz3D internal entity enumeration in update and render calls.

I don't know. I would geuss it depends upon the amount of properties being used, but creating pivots takes up memory (albeit not a huge amount) I seem to remember some code shown a few months ago that proved that lots of pivots is just as bad as lots of spheres in that having large numbers of pivots slowed down the app, even if there was nothing to render.

I would agree that findchilding the properties would be quicker than parsing the string of properties. I guess it all comes down to how often you use these things.

Personally the way I do this is to name the entity with the handle of a type which stores that entities data so all I have to do is

p.property=new property
nameEntity handle(p)

then to get the entities data I would

p.property=object.property(entityName(id))
a=p\property1
b=p\property2
;...etc

Of course this will only be good until Mark decides wether the handle/ object commands are official or not, but I have had no problems so far.

Binary_Moon:

I'm well aware of that hack, but I needed something more dynamic and flexible - this is one way I've found round it. This way you can pass an entity to a function and get a property without the function needing to know anything about the 'Type' you have created for the entity - this being the main falldown of types in my opinion as it stops you from having generic functions.

Anyway, I've posted the code and the idea so that anyone who might find it useful can use it. If anyone can help to refine it then please do.

Skidracer:

Glad you like it. I'll try some tests an see if HideEntity makes a difference.

Just really getting into B3D, this sounds VERY useful Ken. Thanks for sharing :c)

That's cool. Just trying to present a different 'perspective' :)

Just had another look at your code. A couple of things I would change (that have nothing to do with the amount of pivots)

In setProperty() you should use

	v = GetChild(p, 1)
	If v = 0 Then v = CreatePivot(p)
	NameEntity v, value

As it is at the moment you can only set the property once. If you want to change the property you can't unless you delete the property first.

this is excellent, i was trying something like this, you bet me to it :)

You can, it's just I messed up the code a little so there are actually two NameEntity calls, one inside the if and one outside - though the code you wrote is what I originally intended to write ;-) Thanks.

I've done some quick tests using a string parsing routine, just out of curiosity, and it seems my assumtions are wrong, my string parser version is just as fast as my pivot version at the moment.

I would guess (I don't know but...) that using FindChild blitz has to loop through all children doing a string comparison to check the name. Obviously this would be slow if we wrote it (in blitz), so it is faster than our version would be but faster than parsing a string... haven't got a clue. Thats why I like the object and handle method. You can get straight to the entity data really quickly.

It does seem like Blitz does just go through all entities until it gets to the one with a name that matches, it's probably the only way to do it as I can't imagine entities being sorted in any way.

I did like the object/handle trick, but I began to find limitations when trying to write reusable libraries of functions - unless you use the same type for all your entities then you have to rewrite the same function for different types. I am just trying to explore Blitz and see if there is a different, more flexible way of doing things - this is just one of my experiments.

Overall, my tests have shown that searching through pivots is about twice as fast as parsing a string using InsStr to retrieve values - I can retrieve 9000 values in about 35 milliseconds using pivots compared to 70 milliseconds using a single string to store all the properties.

The memory usage of the pivot method for creating 9000 properties is about 7000KB above that for creating a string to contain a list of 9000 properties, so the pivot method is a bit more memory intensive, but you are never going to have anywhere near 9000 properties in a game.