Follow-up Comment #15, patch #3829 (project freeciv):
My graphical test was trivial: define some integrated roads in a ruleset,
using existing graphics. Start a new game. Add some roads in the editor.
There's a separate issue that sometimes sprites don't refresh until there is a
new cause of vision for a tile, but that's independent of this patch (and is
only likely to be noticed playing with road drawing and connectivity in the
editor).
Now, about commutativity: currently each road has a separate integrates
vector, and so it is possible to construct a road set where road A integrates
with road B, but road B does not integrate with road A. The consequences of
such configuration are as follows:
1) Move from tile with (only) road A to tile with (only) road B costs
B.move_cost movement points.
2) Move from tile with (only) road B to tile with (only) road A costs
(is_igter ? MOVE_COST_IGTER : terrain.movement_cost*SINGLE_MOVE) movement
points.
3) When drawing a sprite for a tile with (only) road A, if an adjacent tile
has (only) road B, a road A type connector will be drawn towards that tile, if
the tileset supports this.
4) When drawing a sprite for a tile with (only) road B, if an adjacent tile
has (only) road A, a road B connector will not be drawn towards that tile (nor
a road A connector), regardless of tileset support.
My initial thought is that case 2) represents a bug, in that the cost
ought to be A.move_cost movement points, although thinking about it more,
someone (not me) might want to model disembarking from a train with such an
additional movement penalty.
That said, I think case 4) represents a feature: it probably looks better
to draw some roads (e.g. rail) as not having spur connections to feeders (e.g.
road), without requiring the integrating road to be present on the rail square
and using hiders. This may be an incomplete feature, as it may be interesting
to draw spur sprites for incoming integrating roads. Also, it gets hard to
determine when to do/not do this, so perhaps integrating the draw logic with
hiders is better, not drawing a spur (road_near[dir] == FALSE) when the road
being drawn would hide the road that is potentially near (in which case 4) is
neither a bug nor a feature, but irrelevant).
Implementation of this means either carrying two cache vectors client side
or modifying the sprite logic to use binary operators on the road_near[dir]
and troad.integrates bitvectors rather than an iteration loop (which I like
better, and should be faster, but actually doing it requires more review of
syntax than the other way). Regardless of the solution chosen for sprites,
one would just cross-populate the integrators lists for all integrating roads,
before pushing them through the sort and unique functions (which probably move
somewhere else, so they can be processed once ruleset load is complete).
The above notwithstanding, if we don't care about commutativity, there's
nothing to be done, and we have behaviours 1-4 all working.
_______________________________________________________
Reply to this item at:
<http://gna.org/patch/?3829>
_______________________________________________
Message sent via/by Gna!
http://gna.org/
_______________________________________________
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
