I understand.
It may seem odd, but I could not do things any differently, probably someone could make links work for my project, but with my understanding alone, I'd have to change my organization name from 'Binary Modular' to Binary Singular' or 'Binary not-so-modular afterall'. My entity abstraction system would not be very abstract; as I will explain.
Quote: "of course the peek and poke commands are definitely faster"
I personally am not sure; that was my point. My point is that no program has been created the same, and no end user or system is identical. In some cases they might be faster, in other cases slower.
My test indicated on my machine, link array is faster with the same list; but not with many lists.
And my workflow is 'it is fast enough until proven too slow!'
Quote: "I find the array approach to be much more straightforward"
One aspect of my approach has not been revealed, the actual management code.
I do not actually have to write poke commands and memory allocation and resizing of my lists; I have only shown the inner workings to demonstrate to Sasuke what I do.
In reality I just call
Insert( number, listID ),
Remove( number, listId ),
AddListToList( list, iListId ).
That is not possible with array links; because the function has to know the UDT and its format. Where as with abstract data, the management functions need not be concerned with what type of data is being managed; nor is there a need for a new function for every UDT.
I do not have to dimension local lists, link them and unlink them like:
Local Dim TextMessage$(10) : For i = 1 to 10 : TextMessage$(i) = GetNetString$() : Next i : Player.TextMessages = Get ArrayPtr( TextMessage$() ) : Unlink Array TextMessage$()
I can just set something; and the system puts it in a list for me; even if the list did not exist:
For i = 1 to 10 : Player.TextMessages = AddString(Player.TextMessages, GetNetString$() ) : Next i
I do not need to link my list. The list is just there; I just access it
MyVariable = IntegerItem(MyList, Index)
I also do not need to recompile 90,000 lines of code, to add a new field, which would be the case if everything had its own UDT array
Quote: "I'm not sure that the link array command has a significant overhead to it. The command isn't copying any data or creating new data, it is simply changing what the array is pointing to"
It is like a reference to an area of memory containing the list; quite similar underneath the surface.
Quote: "That's actually what I use the dynamic array system for, I don't have defined classes - instead I have lists of attributes and their values. One of the attributes would be the entity type. But from my engine's perspective every entity is standard."
I am afraid this is where raw memory roars past like a Ferrari racing a push bike. Whilst what you have done is wickedly smart; it is also constrained by the array system.
I am not arguing, just stating why I quit using links:
UDT lists limit you to fields that only store data in a fixed format.
So entities ranging from short pieces of text to the entities that form a world must inherit from a 'superclass' and thus assign unnecessary bytes and more bytes for fields to declare simple entities, where as my raw entities can actually be 8 bytes long; an integer or a float along with the address.
As far as I know you could not attach events handlers to UDT fields,
- nor can you have variable number of fields in the same/similar class (See polymorphism)
- nor can you listen to changes to field values
- nor can you clone one UDT class into a new one.
- nor can you watch or edit any of your field values in your debug window for all of your instances
- nor can you combine two UDTs into a new one at runtime.
- nor can you get one UDT from one application and put it into another application over a network
- you could not set readonly functionality as easily
- UDT fields cannot easily share validation functions, you'd have to call string or number checks in hard code each time the field is assigned a value; it is tedious to add validation functions which can check input on unlimited integer, string or floating point fields unless the assignment function has an easy way of accessing any UDT it sees fit; a walk in the park with memory addresses.
- and no polymorphism, that is to interact with instances of similar classes. - A flight function could not make a UDT bird and a UDT aeroplane fly, unless they where the same type.
Arrays must all be the same class; unless you get into the world the Array Field Ptr, in which case you would end up using peek and poke commands anyway; but far worse because you have to figure out the location of fields based on the definition order. Whereas having the field locations defined in the first place means not having to figure out anything later on.
The only reason why I know this, is because of finding out the hard way.
It is extremely difficult for me to put into words; I think it will make more sense when I release my editor.
Finally I must clarify that my engine actually uses array UDTs everywhere; it is just link/unlink that I dropped.
