[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: Variable tileset size
- To: crimson-users@xxxxxxxx
- Subject: Re: Variable tileset size
- From: Jens Granseuer <jensgr@xxxxxxx>
- Date: Tue, 01 Mar 2005 17:25:38 +0000
- Delivered-to: email@example.com
- Delivered-to: firstname.lastname@example.org
- Delivered-to: email@example.com
- Delivery-date: Tue, 01 Mar 2005 12:31:12 -0500
- In-reply-to: <firstname.lastname@example.org> (from email@example.com on Mon Feb 28 22:42:37 2005)
- References: <firstname.lastname@example.org> <1109614454l.26418l.4l@fizz> <email@example.com>
- Reply-to: crimson-users@xxxxxxxx
- Sender: owner-crimson-users@xxxxxxxx
On 28.02.2005 22:42, Matthias Grimm wrote:
> 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.
> 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.
Ok, now I see where you're coming from. Nice thing is that engine support
as such doesn't require the zooming stuff, so I can do that first, and
try to break my head later ;-)
> > > GFX_OVERLAP_X 9 = width / 4 - 1
> > Looks more like width / 4 + 1... :-P
> Ooops. Thats right.
No, looks better, but is still wrong. It should really be
9 * (width / 32) for the current outline. But I'm thinking about defining
that in the set as well, so the engine could theoretically support
different shapes (still have to be hexagons, though).
> > > 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.
We'll get that one for free. Well, mostly.
> 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.
Might be the best solution indeed, although I think I'd prefer on-the-fly
scaling for unavailable sizes to not bloat the sets.