Subject: Speeding up the server

[Mark Wedel <>]

 I've already implemented a new list that keeps track of active
(ie, speed is nonzero) objects, so process_objects goes through a much
smaller list for each tick (in most cases, with only me playing on
the server, the number of objects on the active list is less than 100).

 This seems to make things snappier, but it is hard to really, because
I run in XPM mode, and the number of images that need to be drawn can
really start to bog down the server.

 
 The next step for speeding things up is to get rid of the floats, or at
least make it so that they do not have to be adjusted every tick.  My
thought is this:

 Have an element in structure that determines what tick the item gets
to go (on_tick).  Thus, it might be tick 500 right now, but on_tick
is 510.  The loop has some check like 'if (pticks < ob->on_tick) continue;'
This saves adding a float to float every tick for active objects, and
instead is just a simple integer comparison, which should be fairly quick.

 The speed variable would remain a float.  This saves A LOT of conversion
work throughout the problem, and if speed was changed to a int, it would
still be synthesized as a float (ie, instead of speed 0.5, it might
be speed 500 (ie, just multiply it by 1000)).

 When on object actually moves, the next tick it goes on would be
 pticks + (speed_remainder + 1/speed)
   
 Where

speed_remainder = 1/speed - (int) (1/speed)

 (there might be a function to do that instead).  Thus, something with a
speed of 0.5 would go every 2 ticks, where as something with speed
0.03 would go every 33 ticks, with speed_remainder = 0.333.

 The advantage with this method is that that only area of code that would
really change is in process_events.  The disadvantage is that objects
that have a high speed would need that updating very often, and thus
may not be any faster (could, in fact, be slower, because those divisions
are probably slower than float additions - however, that division oculd
be stored in a tmp value to make sure it is only calculated once per
updated object..)

 The other difficulty is when the speed of an object changes from a
nonzero value to another nonzero value (if it changes to or from zero,
then taht is a simple case).  The nonzero -> nonzero becomes more difficult.

 This is because right now, if an object has speed 0.1, that value is
added each time, and when speed left is above 1, the object goes.  Thus,
if the speed changes to 0.5, things still work out nicely.

 However, in the new method, if the speed changes, then the next time that
object goes (on_tick) would need to be re-calculated, the result being
based on the old speed, how close it was to getting its turn, and the
new speed).

 For example, if an object has speed .1, it means every 10 ticks, the
object goes.  IF it changes to speed .2, it means that every 5 ticks, it
moves.

 If on tick 1, the speed changes, then around tick 5 or 6, the object
should now move.  If on tick 5 the speed changes, it means that on tick
7 (with 5 remainder), the object should move.  The code is not that
complicated, however, the calculation would probably require a fair amount
of floating point time (which is what we want to avoid.)

 The simple solution could be that when the speed changes, if the
the next time the object moves in MIN(present move calculation,
new one based on present speed).

 Thus, if in the .1 ->.2 case, the object would move on 10, and 
when the speed changes to .2, it would move anywhere from tick 6 to
10, depending on what tick the speed changed on (if it changed
on 9, the new time would be 14, but 10 is less).

 OR an average of the two could be used.  If speed changed on tick 1,
then the average of the old and new (10 and 6) would be used, so it would
mve on tick 8.  Actually, this is probably a bad idea, as if somethings
speed changes from very slow (.05) to fairly fast (1.0), it would still be
up to 10 ticks before it moves.

 Anyways, just putting this out for various thoughts and suggestions.

 --Mark