[Freeciv-Dev] Re: [PATCH] Corecleanup_07Part2 has been put in incoming

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Tue, Aug 28, 2001 at 02:57:03PM -0400, Jason Dorje Short wrote:
> Raimar Falke wrote:
> > 
> > On Sun, Aug 26, 2001 at 03:17:37PM -0400, Ross W. Wetmore wrote:
> > > Attached is the ReadMe for second Part of the corecleanup_07 update to
> > > cvs-Aug-25.
> 
> > Let me state my position/plan:
> >  - make a is_normal(ized)_position
> >  - insert an "assert(is_normal(ized)_position);" into every access
> >  method of map.h
> >  - debug
> > 
> >  - remove map_adjust_x and map_adjust_y
> >  - debug
> > 
> >  - come to an agreement what the final direction system should be
> >  - migrate
> >  - debug
> > 
> > I'm won't do anything before I heard Gautes position/comments on your
> > patch. Jason?
> 
> Ross's patch has a greater scope than what you and I are considering;

It may be possible that Ross has a greater scope but I consider the
steps mentioned above the first ones.

> however it handles things differently than I would.
> 
> As to the general issues:
> 
> DIR_REVERSE has been replaced by 7-dir because Ross plans to change all
> of the server code to use the rotational directional system, while
> temporarily leaving the GUI using the vertical system (with magic
> numbers).  I believe the better solution is to have all code continue to
> use the vertical system (with no magic numbers) until all dependency
> issues are resolved; however, I believe some of his applied patches have
> already changed some DIR_REVERSE usages back to be 7-dir (for instance
> in client/gui-*/mapview.c).  I feel strongly that this is not the
> correct way to handle the problem; it makes fixing the GUI later even
> harder.

These changes weren't applied.

> I will state again that non-real map positions should not be wrapped. 

I have nothing like this in mind.

> Imagine the situation of a hexagon that wraps along the sides only; for
> this simple topology many non-real tiles will have no canonical wrapping
> position:
> <-     x     ->
> <-   x x x   ->
> <- x x x x x ->
> <- x x x x x ->
> <- x x x x x ->
> <-   x x x   ->
> <-     x     ->
> (Note that this is different from Trent's proposed "sphere" topology.)
> 
> I believe he also introduces another function to determine the nearest
> normal position to any non-real map position.  Such a function will be
> necessary if the GUI is to continue it's current behavior (which is not
> strictly necessary IMO).  Until this function is in use (or the GUI
> behavior is changed) there will be a need for map_adjust_[xy].  Also,
> the current GUI method of wrapping will not work cleanly with
> normalize_map_pos.

Such a method may necessary. However I prefer to remove
map_adjust_[xy] and have some magic in find_nearest_real_position.

> I agree with you that is_normal_map_pos is a needed function (although I
> believe there may still be disagreement about the name.  Gaute?).

GAUTE!!!

> Attached is another patch which implements (but does not yet use) this
> function.

I would implement is as follow:

> +int is_normal_map_pos(int x, int y)
> +{
     int nx=x,ny=y;
     
     if(!normalize_map_pos(&nx,&ny))
        return 0;
     return x==nx && y==ny;
> +}

> In short, I agree with your "plan", Raimar.  However, I don't think any
> agreement on what the final directional system should be is really
> needed just yet - we can all agree that code should be written
> independently of the directional system, and that should be the
> immediate goal.  

> Note that some of the patches you've applied have taken an opposite
> approach to this plan.

Please explain.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
  "With a PC, I always felt limited by the software available.
   On Unix, I am limited by my knowledge."
    -- Peter J. Schoenster <pschon@xxxxxxxxxxxxxxxxx>