[Freeciv-Dev] Re: (PR#2516) introducing an enum citizen_type

["Rafa³ Bursig via RT" <rt@xxxxxxxxxxxxxx>]

Dnia 2002.12.09 18:08 Jason Short via RT napisa³(a):
> On Mon, 2002-12-09 at 11:23, Rafa³ Bursig via RT wrote:
> > Dnia 2002.12.09 06:01 Jason Short via RT napisa³(a):
> 
> > > New patch attached.  This adds pcity as a parameter to
> > > get_citizen_sprite (reserved for future use...), as well as making
> the
> > > other changes pointed out by Raimar.
> > >
> > The idea is nice but I see 2 problens.
> >
> > 1) Male and Female separation - if you remove this there should be
> > precise rules to all creator of tile themes with male and female
> > graphic. (Exp. Female first Male secound ) That code could proper
> load
> > and draw it.
> 
> This is only true if you think male and female citizens always need to
> be present and need to be hard-coded in some place.  The former is not
> true for specialists, and I don't see why the latter should ever be
> true.
> 
But we must know if it exist in the tile theme and then proper draw it

> > 2) Setup Sprite Array moment - if it is done on start client ( now )
> 
> > and you want use citizens styles (connect with city style ) you must
> 
> > use numbers to define gfx ( this is now ) in tilespec files. Creator
> of
> > this themes must synhronise those numbers of tiles with city styles.
> 
> > IMO my solution is better becouse in tilespec files we use name of
> > citizens style ( not number ). In this case setup moment should be
> do (
> > partial ) with setup city styles after game start.
> >
> > somting like that ...
> >
> > tilespec_setup_citizens_tiles( int style )
> > {
> >    if (!sprites.citizen[0].sprite[0]) {/* check generic elvis */
> >      int i;
> >      char buffer[64];
> >      for (i = 0; i < NUM_TILES_CITIZEN; i++) {
> >        my_snprintf(buffer, sizeof(buffer), "citizen.%s_%s",
> >               city_styles[style].citizens_graphic,
> > get_citizen_name(i) );
> >        sprites.citizen[i].sprite[ style + 1 ] =
> > hash_lookup_data(sprite_hash, buffer);
> >        if (!sprites.citizen[i].sprite[ style + 1]) {
> >          break;
> >        }
> >        sprites.citizen[i].count++;
> >      }
> >    }
> > }
> >
> > this funct should be call at end of handle_ruleset_city(...) or in
> > tilespec_setup_city_tiles(...)
> > ( here still lack solution on Male/Femal problem )
> 
> You miss the point.  There will not be one citizen per city style, but
> rather each style will also have the option for multiple citizens.
> 
In that case sprite struct should look like

sprites.citizen[type].style[ style ].sprite[ citizen ]

this should fix problem male/female but draw code still must know about 
that.
And fill procedure should look like

tilespec_setup_citizens_tiles( int style )
{
   if (!sprites.citizen[0].style[0].sprite[0]) {/* check generic elvis 
*/
     int type , n;
     char buffer[64];
     for (type = 0; type < NUM_TILES_CITIZEN; type++) {
       for (n = 0; n < NUM_TILES_CITIZEN; n++) {
         my_snprintf(buffer, sizeof(buffer), "citizen.%s_%s_%d",
                  city_styles[style].citizens_graphic, 
get_citizen_name(type), n );
         sprites.citizen[type].style[style].sprite[ n ] = 
hash_lookup_data(sprite_hash, buffer);
         if (!sprites.citizen[type].style[style].sprite[ n ]) {
          break;
         }
       }
       sprites.citizen[type].style[style].count = n;
       assert( n > 0 );
     }
   }
}

Rafal

--------------------------------------------------------------------------
Wyslij swiateczne zyczenia:
>>> http://pocztowki.interia.pl <<<