[Freeciv-Dev] Re: (PR#2960) First step towards eliminating sprite padding

["Eric S. Raymond" <esr@xxxxxxxxxxx>]

Jason Short via RT <rt@xxxxxxxxxxxxxx>:
> I really don't want to introduce a hack in the sprite loading code to do
> this.  We should fix it at the core, by changing the drawing code to be
> able to handle offset sprites.

OK.

> My idea on this for some time has been to introduce
> 
>   struct drawn_sprite [
>    struct Sprite sprite;
>    int x_offset, y_offset;
>   };

Good.  Yes.  Then, later, we can introduce other annotations into the
structure if we need to.

> and change function prototypes to
> 
>   int fill_tile_sprite_array_iso(struct drawn_sprite **sprs,
>                                  struct Sprite **dither,
>                                  int x, int y, bool citymode,
>                                  int *solid_bg)
> 
>   int fill_tile_sprite_array(struct drawn_sprite **sprs,
>                              int abs_x0, int abs_y0,
>                              bool citymode, int *solid_bg,
>                              struct player **pplayer)
> 
> with corresponding changes inside and outside these functions.

That's a good API.

> (Note, this is similar or identical to something you recently proposed as the
> "long-term solution".)

Yes, it is.  I didn't do PR2960 that way because I thought it would be better
to go for the simple solution, rather than the complicated and bug-prone one.
But this business with the explosion sprite has persuaded me otherwise.

According, I withdraw the 2960 patch in its present form.  Instead I'm
willing to do the top half of this change.  I had already thought out
how the tilespec.c code would have to be retrofitted to support a
drawn-sprite structure, so I can probably do that part faster than
you.

So, unless for some reason you want to do the whole thing yourself, 
I'll define drawn_sprite and bring it down to the draw-library level; 
you guys can then worry about making the actual bits dance.
--
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>