Trunk r9794 on Debian GNU/Linux testing amd64.

Units supposedly move faster on good roads.  This has been implemented by making UnitShowAnimationScaled shorten the waits defined in the animation.  However, the implementation never lets a wait become zero-length; each wait lasts for at least one frame.  This means:

• If the animation definition specifies only single-frame waits ("wait 1"), then roads can never make these shorter; the unit does not benefit from roads at all, even though the pathfinder thinks it does.
• If the animation definition also specifies some double-frame waits ("wait 2"), then roads with movement costs 0, 1, or 2 do speed the unit up (compared to the default cost 3), but there is no practical difference between them: cost 2 is as good as cost 0.

In fact, Bos Wars does not currently have any unit types with "wait 3" or longer waits in move animations.

List of unit types that have only single-frame waits in their move animations and so do not benefit from roads:

• unit-buggy
• unit-grenadier
• unit-rtank
• unit-tank
• unit-artil
• unit-harvester

I omitted the aircraft from this list because those shouldn't be affected by roads in any case.

A difficulty in fixing this is that DoActionMove must be able to detect when the unit has finished moving to the adjacent tile.  If you just make UnitShowAnimationScaled entirely skip some waits (making them zero-length and evenly distributing the roundoff error from the scaling), then it seems possible that UnitShowAnimationScaled keeps running even after the unit has already reached the tile, and DoActionMove does not notice the new tile because unit->IX and unit->IY are not exactly zero.  The IX and IY checks can be changed but that still leaves the unit->Anim.Unbreakable check.

Sure this bug can be fixed, but I suspect the animation system will need to be rethought somewhat.