Complete.Org: Mailing Lists: Archives: freeciv-dev: April 2003:
[Freeciv-Dev] Re: (PR#3936) introducing native coordinates
Home

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

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: jdorje@xxxxxxxxxxxxxxxxxxxxx
Cc: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: (PR#3936) introducing native coordinates
From: Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>
Date: Thu, 24 Apr 2003 15:44:12 +0200

On Thu, Apr 24, 2003 at 08:58:16AM -0500, Jason Dorje Short wrote:
> >>>- 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?

That is probably right. But this is a decision you (or some other
made) and didn't document. I wonder what other decisions are made
without documenting.

> 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.

Ahh yes that is another point which I think your gen_topo patch is
bad. It should not accept certain wrappings or sizes or should correct
the size by adding one.

> 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.

> >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.

Well the neighborhood in both forms is different. See
http://www.freeciv.org/~rfalke/grid_pics2/grid_iso1_wn.png and
http://www.freeciv.org/~rfalke/grid_pics2/grid_compact_wn.png. But it
looks that these difference don't matter for the wrapping case. In the
above case this means that if you start at the blue point and goes
west wards (NW, W and SW) you will reach the same tile no matter if
you go in the iso-view form or the compact form.

> >>>- 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...

If it only does the wrapping it is complex. I have to look further
into this.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "There are three ways to get something done. Do it yourself, hire someone
  to do it for you or forbid your kids to do it."



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