[Freeciv-Dev] Re: (PR#3936) introducing native coordinates

[Jason Dorje Short <vze49r5w@xxxxxxxxxxx>]

Raimar Falke wrote:
> On Wed, Apr 23, 2003 at 05:50:43PM -0500, Jason Dorje Short wrote:
> > Raimar Falke wrote:
> > > On Thu, Apr 17, 2003 at 08:24:58AM +0200, Raimar Falke wrote:
> > > Open points in my eyes are:
> > > - which form should be default (IMHO per performance)
> > For performance, non-iso maps are fastest.  But this default should be 
> > determined by the default view, which is currently iso (iso-view looks a 
> > lot better on an iso-map, and vice versa).
> > Using "map coordinates" rather than "native coordinates" as standard is 
> > fastest, since the vast, vast, vast majority of operations are done on 
> > map coordinates.
> I disagree here. Every tile access needs the compact form. The same is
> true for normalize_map_pos and is_normal_map_pos. But without testing
> we won't find out.
You're right.  In fact, I believee that the most common operation is 
MAPSTEP and this requires both "map" and "native" forms.
> > > - which iso variants do we support (IMHO both)
> > Hmm?  The "variants" you talk about in the file are just a different 
> > numbering system; there's nothing fundamentally different between them.
>
> You can't express every instance of variant1 with an instance of
> variant2. Example: try to build a variant1 map (width and height
> searched) which looks the same like the variant2 map of size (9x5)
> (picture in the page). IMHO this isn't possible. Because the "wdith"
> of variant1 is always even.
True (and vice versa), but that's not really worth worrying over.  Who 
really needs a 99x49 map when you can have a 100x50 one?
On a related note, if you specify an odd ysize in an iso-map that wraps 
in the y direction, you will get very odd behavior.  You have to have an 
even dimension to wrap in a particular direction.  Your variant1 (the 
same as gen-topology uses) enforces this by compressing in the x 
direction; your variant2 compresses in the y.  But neither accounts for 
the other direction.
A simple solution, that would also address the scale problem (a 100x80 
iso-map under gen-topologies is _really_ wide) would be to use variant1 
and double the ysize when the game starts.  But this is a slight hack 
since you only do it under iso maps.
> > > - in which form is wrapping defined? Do we support multiple wrapping
> > > forms (iso view form and non-iso view form)?
> > I don't know what this means.  Wrapping is defined for both iso and 
> > non-iso maps, and is identical in both when done in "native coordinates".
> Ok so the wrapping operations are defnied in the compact
> form.
Yes.

> Question: is wrapping defined in compact form the same as
> wrapping defined in iso-view form? IMHO yes but I'm not sure.
Again you've lost me.  What is the iso-view form?  The form you get by 
looking at it in an isometric-view client?  This is the "natural" view 
of an iso map; the wrapping here is identical except that the scale is 
different.
> > > - how can mapview code done in an easier way (IMHO with an
> > > intermediate form)
> > Again you are lumping a whole collection of unrelated operations into 
> > one term.
> This is a bit terse.
>
> I'm trying to split unnormalize_map_pos into two operations. First the
> wrapping and than the rotating and scaling to pixels. What is your
> opinion?
unnormalize_map_pos is only a small part of the mapview code - just a 
single part of one function (map_to_canvas_pos).  It does the wrapping 
part only; the rotating and scaling to pixels is done separately by 
map_to_canvas_pos.  So this split is already in place...
jason