The link-list is a much more complicated way to get a list of all afflates within a region, but it is much, much faster than a simple search and much more memory efficient than using discrete lists for region registration. If an extreme number of afflates and regions are to be used, a link-list is strongly advised, avoiding the need for possibly 64 gig of RAM and/or extreme memory and CPU cycle speeds.
If memory serves (might want to check it over), to prepare a link-list requires 4 arrays;
RegionBeginAddr - double-word, Max-region length
RegionEndAddr - double-word, Max-region length
LinkPrior - double-word, Max-afflate length
LinkNext - double-word, Max-afflate length
Each element in each array is initialized thusly:
RegionBeginAddr - null (or 0)
RegionEndAddr - null (or 0)
LinkPrior - BOF
LinkNext - EOF
The idea is to form short chains within the link lists that represent collections of all items (afflates in this case) that reside within each region. A chain is formed by keeping track of beginning, prior, next, and end chain-links as a short connected chain. Each link in each chain is both an afflate number and an array address. Due to the manner in which the chains are maintained, an almost instant access to a complete list of afflates for any chosen region is always available.
Creating Region Chains
During initialization, as each afflate is assigned a location, the xyx location coordinates identify a specific region and the afflate is recorded as a link in the chain associated with that region (note that the AddAfflate module listed below can be used for this purpose). If the region has had no prior assignments, the afflate number becomes the RegionBeginAddr and also the RegionEndAddr for the region’s chain simply by storing the afflate number in the respective arrays and leaving LinkPrior and LinkEnd arrays untouched.
But if there is already a beginning to the region’s chain (RegionBeginAddr is not null), the newly assigned afflate must be linked onto the end of the region’s chain. This is done by obtaining the region’s chain end address from the RegionEndAddr array, which is an afflate number and array address into the LinkNext and LinkPrior arrays, then simply placing the afflate number into the RegionEndAddr address of the LinkNext array (displacing the EOF marker). Then that same afflate number must be stored as the new end address in RegionEndAddr.
Also there will be need to be able to delete from the middle of a chain, so a prior-link afflate number/address must also be stored as each new link is assigned. So after the new afflate displaces the EOF marker in the LinkEnd array, that same array address must be stored into the new afflate number/address of the LinkPrior array. Each afflate number is also an array address which leads to both a prior and a next afflate, which in turn is an address which does the same until the end of the chain.
What this has accomplished so far is to have each afflate within a region provide the next afflate number that is within the region (via LinkNext) until all afflates within the region have been listed. To obtain a list of every afflate within a region, simply find the beginning of the chain and read an afflate number from the LinkNext array, then using it as an address into the same array, read the next afflate number. Continue that until an EOF marker is found as the next afflate number.
Relocating
Once all of the assignments have been made, the emulation clock can begin. For each tic of time passing, all afflates are relocated to the new locations, as dictated by their assigned vector. This requires that each afflate be removed from its prior region and added to its new region (even if it is the same region). To simplify the coding its best to have a “RemoveAff” module and an “AddAff” module, each specifying which afflate and region is involved.
RemoveAff
To remove an afflate from a region’s chain requires that the afflate number be used as an address into the LinkPrior and LinkNext arrays.
- The afflate’s NextLink number (possibly and EOF) must be placed as the NextLink number at the afflate’s PriorLink address (obtained from the PriorLink array).
- And the afflate’s PriorLink number (possibly a BOF) must be stored at the afflates NextLink address in the PriorLink array.
- If the BOF or EOF markers have been moved, store them in their respective region arrays.
- Decrement a region counter (for later use)
This causes the removed afflate to be skipped over by the links in the chain. The prior-link points to the next link after the removed afflate-link and the next-link points back to before the removed afflate-link. It might be difficult to keep that straight, but once coded, it is very fast and need not be remembered.
AddAfflate
Once each afflate is removed from its prior region’s chain, it must be added to the new region’s chains (perhaps the same region). To add an afflate is the same process as initially forming the chain, simply add the afflate to the end of the region’s chain as before.
- Find the RegionEndAddr for the region, displace the EOF marker with the new afflate number.
- Using that afflate as an address, place the new EOF marker into the NextLink array, terminating the chain.
- Place the former RegionEndAddr into the LinkPrior array.
- Then replace the RegionEndAddr with the new afflate number as the new end of the chain.
- Increment a region counter for later use
Once this module is written, it can be used during the original creation of the chains.
As wordy and complex as all of that is, once coded it is extremely fast and efficient, providing for already prepared regional afflate lists for ambient affectance attribute calculations (density, polarity, wind, gradient) and display. With each tic, the ambient region of every afflate must be examined. That can lead to millions of list compilations and then calculations for each tic, especially when more than one region might have to be examined for each of millions of afflates.