Complete.Org: Mailing Lists: Archives: freeciv-dev: October 2001:
[Freeciv-Dev] Re: to wrap or not to wrap?
Home

[Freeciv-Dev] Re: to wrap or not to wrap?

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: freeciv-dev <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: to wrap or not to wrap?
From: Jason Dorje Short <vze2zq63@xxxxxxxxxxx>
Date: Mon, 15 Oct 2001 03:20:21 -0400
Reply-to: jdorje@xxxxxxxxxxxx

A few clarifications.

Jason Dorje Short wrote:

> The problem is exactly that the GUI does not behave in this manner.
> It's not just a flat window sitting over a wrapping world; the
> coordinates in the window itself are being wrapped (as above).  If it
> were otherwise, then we'd just take our window coordinates (window_x,
> window_y), adjust them to map coordinates (map_x, map_y), and call
> normalize_map_pos() to see what we had at that position.  This would be
> the better solution, but unfortunately (1) it will require a significant
> overhaul to achieve this and (2) we will need to do some additional
> tricks to make sure we don't draw a tile more than once (since the
> flat-earth window knows nothing of the underlying topology) [2].

There is no [2].

> If you don't believe me, please prove me wrong by fixing the GUI to work
> with your system.  You may use only existing topology functions
> (normalize_map_pos, is_real_tile, nearest_real_pos, and
> is_normal_map_pos).

You may also define additional topology functions, like clip_map_pos, so
long as they can be implemented for all topologies.

> > Specialized code goes where specialized code needs to go. By definition
> > it is not general and so your concern for trying to make it fit
> > general topologies is admirable but misplaced.
> >
> > To make this easier for you to swallow, specialized code might be a
> > "subclass" that handled a particular specific topology. Only the class
> > interface needs to be in map.h.
> 
> This would make the job much, much harder.  There is so much GUI code
> that changing it for every topology is not practical.  Additionally, I
> believe it is fundamentally very, very flawed.

By "it is fundamentally flawed" I mean the idea of writing
topology-specific code outside of the topology functions.

jason


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