[Freeciv-Dev] Re: [PATCH] bugfix for wrapping problem

[Reinier Post <rp@xxxxxxxxxx>]

On Fri, Aug 24, 2001 at 09:10:41PM -0400, Jason Dorje Short wrote:
> Reinier Post wrote:
> > 
> > On Fri, Aug 24, 2001 at 07:25:53PM -0400, Jason Dorje Short wrote:
> > 
> > > Refreshing the whole canvas will not give the appropriate animations,
> > > although it would be easy to implement.
> > 
> > That isn't necessary, or is it?  The user is looking at the positions
> > where the order was given, so that's where the animations need to be.
> 
> Right, right...you can animate once and then refresh.  Ideally, though,
> all visible incarnations of the unit would be animated in sync.

This may be too confusing to the user.  Speed isn't much of a concern I
think - in busy games you have to turn animation off anyway.

> [...]  It would be a matter of changing 2
> lines of code to allow full wrapping (although the update problem would
> still not be addressed).  So, I think it could make everyone happy for
> now.

I am not very familiar with the code, but as far as I can see all
translations from underlying map to map view coordinates are done by
city_get_canvas_xy() and get_canvas_xy().  So a crude way to solve the
update problem is to make them update a *list* of canvas_{x,y} pairs
and make the calling code iterate over the list.  Code that operates
on a pair of tiles in the map view, eg. goto route display and animations,
would either have to use a get_canvas_x1xy_x2y2() and iterate over a
list of tile pairs, or select one such pair and use that.  (If they
are to appear on the map only once.)  In the latter case the code must
be made to remember the original canvas_x,canvas_y coordinates the user
used to instigate the action, and use that.

> What I'm talking about is only topologies that map cleanly to a plane. 

What is 'clean'?  From the usability point of view, I think all topologies
are allowed that are locally flat: the complete local neighbourhood of
some reasonable diameter (at least 10) around every tile must map onto
a regular tile grid in the map view.  Another way of putting this is to
say that the tile adjacency relation in the resulting map view represents
the tile adjacency relation in the underlying maps.  Yet another way of
putting this is to say that the movement operations (the arrow keys) form
a Boolean algebra, but I'd have to look that up to be sure.  I think
this is what you mean by 'well-oriented'.  (Google doesn't return much
on 'well-oriented' and 'topology'.)

E.g. this disqualifies playing on the faces of a cube filled with a grid:
the neighbourhoods of the corner points cannot be mapped.  It does not
disqualify playing on a large enough cube of which the four vertical edges
are cut: such a cube can be mapped to the plane, at the cost of leaving
empty space.  It also allows unusual tilings of the plane,
even Penrose tilings.

> There are eight in particular that are necessary:
> 
> rectangle
> vertical cylinder (the current standard)
> horizontal cylinder
> torus (not particularly useful, but...)
> orthogonal rectangle
> orthogonal right-tilted cylinder
> orthogonal left-tilted cylinder
> orthogonal torus
> 
> These are all the simplest type of topology, well-oriented and
> what-not.  There might be a few others that could fit in here...like a
> wrapped hexagon.

It really shouldn't be hard to allow hexagonal grids in the map view,
shifting the odd rows by half a tile.

> If all of the map adjustment is cleaned up, these should be
> implementable only by changing the map code (in map.[ch]).  Some other
> topologies, like mobius strips (which are not well-oriented), may not be
> too far off but will have some problems.

It depends on whether the Moebius band is cut on the edge, on
whether you insist that every map view must be drawable without
multiple appearances of the same tile, and on whether you insist
that normalization (the modulo operator) suffice to represent
the canvas->map transformation.

One advantage of supporting multiple tile appearances is that it would
make it easier to add support for multiple simultaneous map views.
This is something I would value as a player: there are often
several simultaneous areas of action, small, but distant, and it
can be cumbersome to switch the map view between them all the time.
 
> I've heard much more complicated proposals...projections onto a sphere,
> projections onto an arbitrary digraph...these are not practical in the
> near future.

No, I'm just trying to specify the exact constraints that may or
may not be imposed and their implications for the code.
 
> jason

-- 
Reinier