[crossfire] mapguide/director question

[Alex Schultz]

Mark Wedel wrote:

>
     
      Alex Schultz wrote:
     
     >
     
     
     >>
     
      <snip> 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.
     
     
True, what I suggested isn't simple, but it is simpler than any method 
I've thought of to merge all the fire objects created by a meteor swarm.

>
     
     
     >
     
       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.
     
     
Indeed, though according to my profiling, the counterspell checking is 
by far the largest portion of this.

>
     
       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.
     
     
Hmmm... this sounds like it might be a good solution. However it should 
be noted that this wouldn't completely fix MS slowness of course, just 
fix one of the several reasons why it's so bad, which would be a good 
fix to do even if the other aspects of MS slowness (i.e. the raw amount 
of flame objects) were fixed.

Alex Schultz