Re: Variable tileset size

[Matthias Grimm <matthias.grimm@xxxxxxxxxx>]

On Mon, 28 Feb 2005 18:14:14 +0000
Jens Granseuer <jensgr@xxxxxxx> wrote:

> As Dave mentioned that depends on the size. Large files (upwards of
> about 200k I'd say) I prefer not to have posted to the list (though
> not
> so much for myself as I usually have to grab them anyway).

Ok. The source itself is only 8K (zipped) but the image package is
roundabout 500 KByte.  I will prepare a basic package just to show
how it works and send it to Dave.

> We can put the package somewhere on the web server (a new contrib/
> dir maybe) and then add a page in the wiki for it, or for fiddling
> with tiles/units in general. Dave already volunteered to do the upload
> which suits me just fine. ;-)

That would be nice. For now I would prefer a contrib directory because
the tool is neither handled by autotools nor integrated in the main
projects configure/make/make install procedure. It will make updates
more easy for me because the main source isn't interfered. We could
change this if the tool is more complete.

> >     I tried to fiddle out what to do in the source but saw that I
> >     don't
> >     know enough for a patch yet. I found the following defines in
> >     mapview.h that must become properties of the objects tileset and
> >     unitset. Unfortunately there are two objects that handles
> >     tileset
> >     images. In future this objects should be changed to handle
> >     tileset
> >     images in different sizes to be fast, even this might become
> >     very
> >     memory consuming.
> 
> Hm, I'm not sure I understand what you are trying to say here. Which
> objects are you talking about? TerrainSet and UnitSet? Is there a
> performance problem somewhere, or are you just speculating?

Yes, you are right. I ment TerrainSet and UnitSet. Both classes define a
property "Surface tiles". To realize zoom we can choose two ways here:
1. Reload the tileset each time the map should be zoomed and update the
    objects TerrainSet and UnitSet or
2. we add an array of Surfaces to each class and the property tiles
    will be redirected to the currently active zoomlevel (tileset) each
    time the map is zoomed.

Solution 1 is time consuming because the tileset has to be reloaded
again and again and it will  last some time switching from one zoom
level to another.
Solution 2 is memory consuming because you have to hold multiple
tilesets of different size in memory to be able to switch fast between
zoom levels.

Disadvantageous is that two classes handle tileset graphics so all the
zooming code must be implemented twice unless you create a basic class
to handle tilesets in general. But I haven't thought it well out yet.

> >     GFX_WIDTH         32    This should be provided by the *.tiles
> >     file 
> >     GFX_HEIGHT        28    This should be provided by the *.tiles
> >     file
> >     GFX_OVERLAP_X   9     = width / 4 - 1
> 
> Looks more like width / 4 + 1... :-P

Ooops. Thats right.

> >    I forgot to say: This is a feature request ;-)
> 
> Oh! Well. Actually, I don't think this should take very long.

Nice to hear this :-) Don't forget the editor comet.

> I'm not yet sure about a rather fundamental issue, though. We have
> to make sure that terrain and units fit together size-wise. How do
> we do that?
> Do we only allow zooming to levels which both sets support? What if
> there are no shared sizes (e.g. terrain is 64x56 only and units 32x28
> only)? Do we scale? Up? Down? Do we just bail out with an error? Or do
> we lump terrain and units together in a single file? This matching
> business is much more difficult to get right than adding support for
> different sizes.

The problem looks confusing but I think it is not as complicated as it
seems. Currently each tileset has to be processed by mktileset or
mkunitset. In future we could combine this programs into a single
tool that always create tile- and unitsets in all needed sizes. All that
Cf is needed to know is which zoom levels are available. The case, that
a desired size isn't available, doesn't exist then.

 Best Regards
    Matthias