This is the mail archive of the xconq7@sources.redhat.com mailing list for the Xconq project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Terrain images proposal


On Sun, 26 Sep 2004, Eric McDonald wrote:
> 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 

That is what I meant, but I expected you would specify a range of cells
that could be completely covered by the image.  XConq would not
automatically choose the range of cells to match the image size, certainly
not to apply the image to cells that the image doesn't fully cover.  
Trying to specify a cell to be taken from an image where the image does
not completely cover the cell, would be an error; XConq might or might not
be able to handle the error gracefully, but it wouldn't be the behaviour I
intended people to use even if it was handled in some graceful way.

> 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?

Whichever one the designer specified last - just like properties and table
entries.  XConq does not maintain knowledge of all the images ever
specified at a cell - it just maintains at most one image per cell and
overwrites that as each new one is specified.  The idea is that the cell
only *has* one image; syntax might allow that one image to be specified
more than once, but if you do so it's just for convenience, like "I want
to use this image over most of the area, but override it at this cell, so
I'll specify a different image in this small area that which I happen to
have mentioned once already".

> 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....

What I had in mind was that you specify a roughly rectangular region of
cells (yes, it'll have wiggly borders because it's made up of hexes) so
that each one of them is clipped from the image in much the way hexes are
already clipped from images.  Within that region it looks like a chunk of
the image is seamlessly embedded, because the cells are clipped from
seamlessly adjacent hexagonal areas in the original image.  The region
stops hard at the hex boundaries, though.

Imagine that I'm building a tabletop wargame in meatspace.  I start with a
chunk of hex paper and a nice big photograph.  I lay out a hex grid on the
photograph and cut it into hexagonal pieces.  There will be chunks around
the edges where the edge of the photograph cuts through a hex, so I have
some non-hexagonal chunks, but mostly I have a bunch of hexagonal chunks
of photo paper.  Now I glue the really-hexagonal pieces to the hex paper
in the same arrangement they had in the original photo.  I throw out the
non-hexagonal chunks.  I paint terrain into some other cells of my hex
paper - the ones not covered by photo.  I end up with a map that has a
chunk of photograph in it, and also some non-photograph terrain, but only
one of those or the other (not both) in any given cell.  There's an area
of the map that looks like a continuous photograph without hex boundaries
visible, but that's only because I was really really careful with my
cutting and pasting so that the seams don't show.  Around the edge of that
area, where the photograph cells abut the painted cells, it's up to me to
do my best job with the painting to make the boundary look good - or else
use a photograph that really covers the entire area of every cell of my
map, to avoid that issue.  Maybe there's more than one chunk of photo on
my map, too, but for each cell I chose only one hexagonal piece of photo
to glue on.  Maybe I used rubber cement, and when I found that I wanted to
glue a photo onto a hex where I had already glued a photo, I peeled off
the old one, discarded it, and pasted the new one in place - last
specified source overrides all previous specifications.

What I want to do with XConq is something similar.  For each cell, or
maybe for each (cell,terrain-type) pair, I store "What photograph (image
file) is this from, if any?" and "Where in that photograph is this
from?".  I also want to automate the cutting/pasting by having some kind
of input syntax that says "Here's a chunk of cells.  Take images for these
from this area of this image file, and compute the coordinates to make
them line up nicely.  I expect that this image file will cover all the
cells I told you to use it for; if it doesn't, that's my mistake and you
may abort."
-- 
Matthew Skala
mskala@ansuz.sooke.bc.ca                    Embrace and defend.
http://ansuz.sooke.bc.ca/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]