[crossfire] mapguide/director question

[Mark Wedel]

Alex Schultz wrote:
>
     
      Mark Wedel wrote:
     
     >
     
     
     >>
     
      So if you fire across the world maps, there will only be a few objects 
     
     >>
     
      on each space the meteor has to check against.
     
     >>
     
     
     >>
     
       In comparison, in the director loop, it has to check on all the 
     
     >>
     
      objects on the space, which is considerable (all the other meteors).  
     
     >>
     
      And you have a whoel bunch, so this is happening a whole lot.
     
     >
     
     
     >
     
     
     >
     
      You seem to be implying that the meteors checking for other objects is 
     
     >
     
      the issue, however from what I've found in profiling it's all the flames 
     
     >
     
      checking all the other flames to see if they are a counterspell seems to 
     
     >
     
      be about 2/3 or so of the time. From what I've saw, most proposed 
     
     >
     
      solutions to this involved merging the flame objects so there's only one 
     
     >
     
      layer per square, however this would greatly complicate how they 
     
     >
     
      disappear and how the damage of each changes. However believe I have 
     
     >
     
      thought of a solution that would take much less effort and would shave 
     
     >
     
      off the time it takes for the counterspell checking:
     
     >
     
      Have a "countermap" which lists the number of counterspell objects on 
     
     >
     
      each square of a map, when one counterspell object is added, it adds one 
     
     >
     
      to the correct spot in the array (or whatever data structure it is), and 
     
     >
     
      when removed counterspells subtract one from that spot on the array. 
     
     >
     
      Then the big loop that currently goes through every object on the square 
     
     >
     
      for counterspells only has to quickly check the "countermap". This does 
     
     >
     
      not completely get rid of the issue, though I feel this solution is the 
     
     >
     
      most efficient in gain vs. complexity.
     
     
  Its not really that simple however.

  It isn't only that the space in question has to be examined for counterspells 
- it is more generic - when an object is inserted, the objects on the space have 
to be examined to see if any of the objects on that space may somehow affect the 
inserted objects.

  For spells, counterspell is the most likely scenario, but directors and 
spinners are other possible cases.

  Likewise, the object being inserted has to check against objects currently on 
the space to see how it may effect them (burn them up, etc).  Although that may 
actually be done in the spell code when it is actually inserting the object.

  The point being here is you just can't set up a counterspell map and say the 
check_walk_on code only needs to check that - doing that is sure to break some 
thing.

  A more likely fix might not be counterspells, but basically record the 
type/subtype of the object(s) on the space that have check_walk_on set (right 
only need to know there are two different types).  The assumption being an 
object of the same type/subtype doesn't effect itself.

  Thus, if you get a square and the only objects with walk_on set are the same 
type of the object as we are inserting, we don't need to do any checking.  When 
types are different, then we go through and see if there are directors, exits, 
counterspells, whatever.  This would only take a few bytes - if there are 4 
different types of objects on the space, we don't need to record the properties 
of all 4 - we just need to know that there are 4 different ones so have to go to 
old fallback.  If there is only 1 type, we need to know that to check against 
what the new object is.