[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[glob2-devel] teleporters
From: |
Leo Wandersleb |
Subject: |
[glob2-devel] teleporters |
Date: |
Tue, 06 Feb 2007 02:35:11 +0100 |
User-agent: |
Icedove 1.5.0.9 (X11/20061220) |
hi list
i'm digging into gradients and have some questions:
== confusing code ==
why are there
updateGlobalGradientVersionSimple
updateGlobalGradientSlow
updateGlobalGradientVersionSimon
updateGlobalGradientVersionKai
when there is stated: speed 105.09% compare to simple on test
as the best case of all?
it is very confusing to have some extra 300 loc and it is not comfortable to
hack in teleports into 4 versions of the same function.
if versionSimple is about as fast as the other 3 can we delete the others?
please don't take me wrong but a speed benefit of 5% at the cost of 4 times the
loc taken the speed measurement was correct i don't see the point.
== confused leo ==
how should i implement teleporters?
=== gradients that hit tp put all tp to the achieved value and further
propagate from there ===
*a glob walking to wheat will either hit wheat or a teleporter. tp know the
wheat exit gate and directly release the glob there (wait n seconds, gradient
drops n here)
*no extra gradient needed
*gradient calculation slowed down as a check has to be performed on all tp
until the first teleporter is hit. after that the squares of the tp are in the
list of the gradient and the gradient can be calculated as before.
*the entering tp is not known until we hit it
**this is bad if we want (i don't) to limit the throughput. (imagine there is
only one tp near wheat and all globs use tp to get there while the opponent
tries to rush this tp)
*effectively bigger maps work with 8 bit gradients as these shortcuts put
remote points on the same level
=== gradients that hit tp put all tp to the achieved value. tps propagate their
own gradients ===
*globs would have to check if they are higher on wheat-gradient or on one of
the (tp-gradients + the tp's wheat-value)
*tp could accept a certain amount of globs at a time depending on the level
(1/s 2/s 3/s). this would lead to unwanted behaviour as globs would start their
journey and turn around to take the teleporter while others would benefit far
more from the tp ...
*many more gradients
*smaller change to the gradient generation
=== conclusion ===
I prefere the first implementation as it saves on resources and will work
smoother i guess.
I'd like to test another feature: global tp: one would have to build turrets
around the tp first and then the tp. global tps are indestructable after beeing
built/set up by the designer.
good night,
Leo Wandersleb
- [glob2-devel] teleporters,
Leo Wandersleb <=
Re: [glob2-devel] teleporters, Stéphane Magnenat, 2007/02/06
Re: [glob2-devel] teleporters, Leo Wandersleb, 2007/02/06