Complete.Org: Mailing Lists: Archives: freeciv-dev: August 2001:
[Freeciv-Dev] Re: [PATCH] bugfix for wrapping problem
Home

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

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Reinier Post <rp@xxxxxxxxxx>
Cc: Freeciv developers <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: [PATCH] bugfix for wrapping problem
From: Jason Dorje Short <jshort@xxxxxxxxxxxxx>
Date: Fri, 24 Aug 2001 21:10:41 -0400

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.

> > As a final idea, if you really want to avoid wrap-around I think a
> > better way to do it is not by normalizing all the time, but by limiting
> > the width of the canvas.  If the canvas is no bigger than (map.xsize,
> > map.ysize) in width/height, then there will still be no wrapping,
> 
> With playable 20x20 tiles (tinydent) on a 40x25 map (fast game)
> on a 1600x1200 screen (my default), wrapping really is convenient.

Well, this solution would most likely limit the width and height of the
map canvas when they are first set.  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.

> > the
> > graphical updates will be faster, and the "correct" solution for
> > handling coordinates can still be used (allowing different topologies to
> > work).
> 
> You can't handle playing on the sides of a cube, for instance.
> But it's not clear to me if there is any consensus on the range
> of topologies you aim to support, anyway.

There's certainly a consensus on the range of topologies I aim to
support.  I agree with myself :-)

What I'm talking about is only topologies that map cleanly to a plane. 
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.

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.

I've heard much more complicated proposals...projections onto a sphere,
projections onto an arbitrary digraph...these are not practical in the
near future.

jason


[Prev in Thread] Current Thread [Next in Thread]