From: Eric McDonald <mcdonald@phy.cmich.edu>
To: mskala@ansuz.sooke.bc.ca
Cc: xconq7@sources.redhat.com
Subject: Re: Terrain images proposal
Date: Sun, 26 Sep 2004 18:23:00 -0000 [thread overview]
Message-ID: <41570273.5010509@phy.cmich.edu> (raw)
In-Reply-To: <Pine.LNX.4.21.0409261316540.24746-100000@diamond.ansuz.sooke.bc.ca>
mskala@ansuz.sooke.bc.ca wrote:
> What I had in mind was that each cell has only one override image, if any,
> and if it has one, that completely replaces the regular terrain image.
This is what I had in mind as well. But, perhaps I misunderstood you,
when you were saying things about providing a starting position from
which source map images would be embedded into the area display. The
impression I had gotten from you is that you were interested in being
able to associate a whole region of cells (and not just one cell) with a
source map image. The problem that I saw is what if you have a source
image that is about 10x10 cells and starts at, say, (1,1), and then you
specify another source image at, say, (4,4)? There is an overlap. From
which source image do you extract the cell image?
>So
> when XConq wants to draw the cell terrain in a cell, at present it looks
> up the cell's terrain type and then looks up the image for that terrain
> type.
Correct.
>With my change, it would look for the image for that terrain type
> and that cell position; if there was one, it would use that, otherwise it
> would use the default image for that terrain type.
Right. I thought this was what we were talking about earlier when we
referred to "overriding" the image associated with the terrain type.
> If you tell XConq you are defining an override image for a given cell but
> the image you specify doesn't cover the cell, then (depending on
> implementation) that's either a syntax error, or it fills in the extra
> space with black or some other well-defined pattern, or it's undefined,
> and in any case, the solution is not to do that if you don't like the
> result.
If the image is smaller than the cell region; it might be best to
convert it into a patterned tile within the cell region.
> A critical point here is that the entire rectangle in the image would not
> necessarily appear on the map.
Well obviously I agree with this on a per cell image basis. It is how
Xconq already works. The image is clipped with a hexagonal mask, if you
will.
But, I had thought that you were suggesting that whole rectangles
(spanning multiple cells) simply be embedded into the map at given
coordinates. Based on your response, I think this is not what you
actually had in mind....
Eric
next prev parent reply other threads:[~2004-09-26 17:55 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-26 15:24 mskala
2004-09-26 16:30 ` Eric McDonald
2004-09-26 16:43 ` mskala
2004-09-26 17:30 ` Eric McDonald
2004-09-26 17:55 ` mskala
2004-09-26 18:23 ` Eric McDonald [this message]
2004-09-26 19:19 ` mskala
2004-09-27 18:05 ` Eric McDonald
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=41570273.5010509@phy.cmich.edu \
--to=mcdonald@phy.cmich.edu \
--cc=mskala@ansuz.sooke.bc.ca \
--cc=xconq7@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).