[Freeciv-Dev] Re: [Patch] MAPSTEP

["Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>]

At 03:07 PM 01/09/24 +0100, Gregory Berkolaiko wrote:
> --- "Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx> wrote: 
>
>> Actually, a "get the (x,y) delta for direction dir" is not a bad
>> change. It forces you to hand in all the coordinates (in 2-D) and
>> returns a full 2-D result which is needed for isometric and a few
>> other cases. 
>
>I must loudly disagree with you here.  (x,y) delta still has x-component
>and y-component and is still additive as long as the surface you are
>playing on is locally R^2 (planar).  And DIRSTEP explecitly returns these
>separate components and then they are explicitly used in GUI code.  So I
>think you are fooling yourself here.
>
>I also think that DIR_D[XY] should be retained but for use in GUI only. 
>Although it's too late now, which is another issue.

You have a valid point - I was forgetting just where the code used this.

In general coordinate/directional systems this is a good thing, but this
really was GUI window code which will probably never work with other than
standard x,y cartesian pixels, or things built with them :-). 

There will probably need to be a specific GUI function that always returns 
x,y rectangular values, even if the general system allows one to live in an 
isometric or hexagonal game world. Something like

  GUI_DIRSTEP(&x, &y, r, theta, dir={IN, OUT, CW, CCW})
and
  _GUI_DIRSTEP(&x, &y, dir) 

may not make a lot of sense when "dir" is treated independently, even if

  DIRSTEP(&r, &theta, dir) 

does.

But this is a long ways off ...

>However I must say DIRSTEP is a much better name.

There are map_wrap, map_clip (map_trunc was lambasted too badly), functions
to replace the abused map_adjust use in the GUI. And the DIR_ things seem
to be dwindling, except I haven't touched all the DIR_D[XY] use there. I 
used map_step in the corecleanup changes and I still like "map" for the 
functional form, but DIRSTEP fits the macro usage better somehow :-).

>> Doing x and y individually is actually a problem for a generalization
>> effort.
>> 
>> My only concern is this munges the core and GUI directions systems
>> into a single whole, and the use in the GUI vs in the core is not
>> really the same. The GUI stuff is fitting things into a window, the
>> core playing on a game map, and the two are really not the same in
>> many cases (windows have fixed boundaries, game maps may not, 
>> windows are going to be rectangular, the game map might be a quite
>> different system :-). 
>> 
>> But we are still fighting the "elegance" and "symmetry" argument 
>> against the practical understanding of what it is doing battle here.

Cheers,
RossW
=====