Complete.Org: Mailing Lists: Archives: freeciv-dev: November 2001:
[Freeciv-Dev] Re: map tiles in city dialog drawn in wrong order
Home

[Freeciv-Dev] Re: map tiles in city dialog drawn in wrong order

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Gaute B Strokkenes <gs234@xxxxxxxxx>
Cc: jdorje@xxxxxxxxxxxxxxxxxxxxx, freeciv-dev@xxxxxxxxxxx, bugs@xxxxxxxxxxxxxxxxxxx
Subject: [Freeciv-Dev] Re: map tiles in city dialog drawn in wrong order (PR#1044)
From: "Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>
Date: Tue, 06 Nov 2001 09:25:24 -0500

This is actually a good example of why the core game coordinate
system should not be generalized to try and include different
environments like the GUI. These problems will continue to crop
up until you have a clean separation between the two with an
explicit transformation to move from one to the other in either
direction. 

The real solution may not be to hardcode the GUI loops, but to 
come up with an appropriate coordinate system/iterators for
GUI operations that specifically takes such things into account.
One can then loop in GUI order over GUI coordinates to manage
such GUI effects and side-effects properly.

When such a system is created with its iterator interfaces, then 
document the subtleties that are part of the macro iterface
clearly to prevent future screwups from misuse.

Cheers,
RossW
=====

At 04:58 AM 01/11/03 +0000, Gaute B Strokkenes wrote:
>On Thu, 1 Nov 2001, jdorje@xxxxxxxxxxxxxxxxxxxxx wrote:
>
>> Changing the loop to use an explicit ordering makes things work.
>> Patch attached.
>> 
>> jasonIndex: client/gui-gtk/citydlg.c
>> ===================================================================
>> RCS file: /home/freeciv/CVS/freeciv/client/gui-gtk/citydlg.c,v
>> retrieving revision 1.100
>> diff -u -r1.100 citydlg.c
>> --- client/gui-gtk/citydlg.c 2001/10/30 11:29:33     1.100
>> +++ client/gui-gtk/citydlg.c 2001/11/01 12:22:48
>> @@ -1753,6 +1753,7 @@
>>  static void city_dialog_update_map_iso(struct city_dialog *pdialog)
>>  {
>>    struct city *pcity = pdialog->pcity;
>> +  int city_x, city_y;
>>  
>>    gdk_gc_set_foreground(fill_bg_gc,
>>    colors_standard[COLOR_STD_BLACK]);
>>  
>> @@ -1760,19 +1761,22 @@
>>    gdk_draw_rectangle(pdialog->map_canvas_store, fill_bg_gc, TRUE,
>>                   0, 0, canvas_width, canvas_height);
>>  
>> -  /* This macro happens to iterate correct to draw the top tiles
>> -  first, so getting the overlap right.  Furthermore, we don't have
>> -  to redraw fog on the part of a fogged tile that overlaps another
>> -  fogged tile, as on the main map, as no tiles in the city radius
>> -  can be fogged. */ city_map_checked_iterate(pcity->x, pcity->y, x,
>> -  y, map_x, map_y) {
>> +  /* We have to draw the tiles in a particular order, so its best
>> +     to avoid using any iterator macro. */
>> +  for (city_x = 0; city_x<CITY_MAP_SIZE; city_x++)
>> +    for (city_y = 0; city_y<CITY_MAP_SIZE; city_y++) {
>> +      int map_x, map_y;
>> +      if (is_valid_city_coords(city_x, city_y) &&
>> +      city_map_to_map(&map_x, &map_y, pcity, city_x, city_y)) {
>>      if (tile_is_known(map_x, map_y)) {
>>        int canvas_x, canvas_y;
>> -      city_get_canvas_xy(x, y, &canvas_x, &canvas_y);
>> +      city_get_canvas_xy(city_x, city_y, &canvas_x, &canvas_y);
>>        put_one_tile_full(pdialog->map_canvas_store, map_x, map_y,
>>                      canvas_x, canvas_y, 1);
>>      }
>> -  } city_map_checked_iterate_end;
>> +      }
>> +    }
>> +
>>    /* We have to put the output afterwards or it will be covered. */
>>    city_map_checked_iterate(pcity->x, pcity->y, x, y, map_x, map_y) {
>>      if (tile_is_known(map_x, map_y)) {
>
>I approve.
>
>(Sure doesn't seem like isometric view is very popular, though...)
>
>-- 
>Big Gaute                               http://www.srcf.ucam.org/~gs234/
>I pretend I'm living in a styrofoam packing crate, high in th'
> SWISS ALPS, still unable to accept th' idea of TOUCH-TONE DIALING!!
>
>



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