R4's new instance system is going to require a slight amount of -further- rethinking.
Over R3's system, the new system is intended to implement a few things that probably should have been done from square one, honestly. The highlights of these are as follows.
For the first revision, a few half-contemplated changes were implemented:
- Depth was accounted for by mapping/listing draw events by depth, then in a second, subset container by ID.
- Events were added to their own lists, one for each event classification.
- An option was added to determine the return type of instance_* functions.
The implications and philosophies of each are this:
Depth: This was a reasonably poor idea, though it seemed like the best thing to do at the time. The newer system was floating about in my head, but I rejected it for the time due to lack of apparent need.
Events: Storing events in their own linked lists allows for iteration and execution that will not slow down based on a number of empty particles. Tests on Game Maker seem to indicate that it does the same thing. Overall, one of Mark's better ideas, IMO.
Option: In theory, this will allow for constant-time member access with return values from the instance_* functions. Note that instance_nearest and the like will still require O(N) iteration (details outlined in newer proposals below).
Further thought, especially on how to handle GM inheritance, was given since, leading to further ideas:
- Depth should be determined not by the order of instances in the main map, but rather by the order of pointers in the draw event queue.
- Instances will instead (of being sorted by depth) be stored in separate arrays by object_index. This array will be static, so defrag-IDs will be your friend.
The former revision will free organization method for the latter.
This will vastly improve performance of, for example, instance_nearest(x,y,object0), since only one list will need iterated for object0. The entirety can still be iterated at little cost. What's more, heredity can be achieved using this method by having each object, on instantiation, add itself to all concerned lists.
For example, a call to instance_nearest(x,y,someparent) will iterate the list of objects having ID "someparent," which will contain a pointer to all children of "someparent" as well.
I can only imagine this is what Game Maker does. However, if you think you have an instance where this method (referencing all children in a list of the parent) would break some form of compatibility with GM, please verify it and inform me.
Potential problems with any of the above:
- A problem could result from treating too many scenarios as pointers instead of GM-IDs. The most obvious of thees is in room-given instance IDs. Many room create codes reference other objects in the room by integer-index ID. Failing to store the IDs and to offer a look-up by them could break that system. As such, it should certainly be kept as an option and defaulted to false.
- A problem could result from storing by object_index: redundancy in iterating all objects as a whole. For this reason, a separate container may be needed to store a continuous list.