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
_______________________________________________
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
