Terrain images proposal

Terrain images proposal

[mskala]

Here's what I think should happen for terrain images:

* associate with each cell of the map an optional "override" image name
  and x,y coordinate.
* when looking for the image for that cell, first check whether there is
  an override; if so, look in the specified image *at* the specified x,y
  coordinate
* new subform of "area", which takes as input an image name and some x,y
  coordinates specifying a starting point in the image and in the
  map.  When this is specified it overlays the map cells on the image,
  computes the x,y coordinates of each cell in the image, and sets the
  override coordinates accordingly.  The result is that the image appears
  on the map in that region instead of the auto-generated hex grid cells
  that would otherwise appear.  Note that the image has not been processed
  except maybe by being converted to GIF or whatever - it isn't pre-cut
  into hexes and re-arranged.  Note that this subform could be specified
  multiple times, so that you could re-use the same customized image in
  multiple parts of the map and/or only customize an image for part of the
  map while sticking to auto-generation elsewhere.

I think that would be pretty simple to implement and I'm willing to try if
people would like me to.  An issue I forsee is what happens when terrain
changes during a game.  One solution might be to simply blow away the
"override" values as soon as the terrain changes in a cell; then the
designer, if they're going to allow terrain changes while also having a 
custom image map, had better provide default images that will look good 
combined with the custom map.  Another possibility might be to make these
overrides be per terrain type; that mixes badly with per-cell terrain
types, but if we had for each terrain type the ability to specify an
"override map image" then the system could show the appropriate slice of
the large image for each terrain type.
-- 
Matthew Skala
mskala@ansuz.sooke.bc.ca                    Embrace and defend.
http://ansuz.sooke.bc.ca/

Re: Terrain images proposal

[Eric McDonald]

mskala@ansuz.sooke.bc.ca wrote:

> * associate with each cell of the map an optional "override" image name
>   and x,y coordinate.

This sounds nearly identical to the proposal for two new optional layers 
that I made yesterday. The only possible difference that I see is that 
you seem to be suggesting that a source map image name be associated 
with each hex (cell). Is there a need to have multiple source map 
images? Or, can we get by with a GDL global that indicates a single 
source image, and thus not have to associate it on a per hex (cell) basis?

> * when looking for the image for that cell, first check whether there is
>   an override; if so, look in the specified image *at* the specified x,y
>   coordinate

Probably hexes (cells) in the proposed image coords layers could be 
flagged with -1, if no override was in effect.

> * new subform of "area", which takes as input an image name and some x,y
>   coordinates specifying a starting point in the image and in the
>   map.  When this is specified it overlays the map cells on the image,
>   computes the x,y coordinates of each cell in the image, and sets the
>   override coordinates accordingly.  The result is that the image appears
>   on the map in that region instead of the auto-generated hex grid cells
>   that would otherwise appear.  Note that the image has not been processed
>   except maybe by being converted to GIF or whatever - it isn't pre-cut
>   into hexes and re-arranged.  Note that this subform could be specified
>   multiple times, so that you could re-use the same customized image in
>   multiple parts of the map and/or only customize an image for part of the
>   map while sticking to auto-generation elsewhere.

I am not sure how well a rectangular region of arbitrary size (if I 
understand you correctly) would mix into a sea of hexes. I think that, 
if anything, you would end up with a region looking like a postage stamp 
or a picture that was cut with the scissors that have "teeth".

> I think that would be pretty simple to implement and I'm willing to try if
> people would like me to.  

If you see the way and have the will, then go for it. By all means.

>An issue I forsee is what happens when terrain
> changes during a game.  One solution might be to simply blow away the
> "override" values as soon as the terrain changes in a cell; then the
> designer, if they're going to allow terrain changes while also having a 
> custom image map, had better provide default images that will look good 
> combined with the custom map.  

Agreed.

>Another possibility might be to make these
> overrides be per terrain type; that mixes badly with per-cell terrain
> types, but if we had for each terrain type the ability to specify an
> "override map image" then the system could show the appropriate slice of
> the large image for each terrain type.

The existing 'imf' form already allows for extracting arbitrary pixel 
positions from an image file and associating them with an image for use 
by Xconq. See, for exmaple, 'lib/pg.imf'.

Eric

Re: Terrain images proposal

[mskala]

On Sun, 26 Sep 2004, Eric McDonald wrote:
> > * associate with each cell of the map an optional "override" image name
> >   and x,y coordinate.
> 
> This sounds nearly identical to the proposal for two new optional layers 
> that I made yesterday. The only possible difference that I see is that 

Yes - I hadn't read your message yet when I wrote that; the two ideas are
basically the same.

> you seem to be suggesting that a source map image name be associated 
> with each hex (cell). Is there a need to have multiple source map 
> images? Or, can we get by with a GDL global that indicates a single 
> source image, and thus not have to associate it on a per hex (cell) basis?

My thinking was that someone might want to have a map which is mostly
generated from tiles in the normal way, but with a few small (in relation
to the map size) images pasted in in places where the tiling doesn't look
good enough.  In such a case they might want to use two different source
images, although anything that could be done that way could also be done
by putting the data into one image and looking at different parts of
it.  Part of my thinking was that it would be nice to not have to edit or
specially generate an image - if we could just use GDL to direct XConq on
how to cut chunks out of one or more existing images, then we have one
less tool to write or manual processing/editing step to do in defining a
game.

One concern I have about using a layer to specify x,y coordinates is that
then the data to go into the layer probably can't be manually generated,
so it means adding another tool to choose the x,y coordinates and put them
in that layer for XConq to read.  If we could instead specify "start at
these coordinates, fill these many cells up and these many cells over, use
this step size" then it becomes something that we can manually specify,
at the cost of only slight complexity in the XConq code that reads that
specification.

Maybe we could use a layer and also add a "by-grid" or similar layer
sub-form to automatically generate the coordinates.  That might address my
concern while still using an existing data structure.

> I am not sure how well a rectangular region of arbitrary size (if I 
> understand you correctly) would mix into a sea of hexes. I think that, 
> if anything, you would end up with a region looking like a postage stamp 
> or a picture that was cut with the scissors that have "teeth".

Well, either you cover the entire map with your image, or else you already
face, anyway, the issue that your image has to match up along its edges
with the tiled terrain that it's going next to.  If we allow some cells to
have image-overrides and other cells to not have them, then I think we're
going to get that issue in any case.
-- 
Matthew Skala
mskala@ansuz.sooke.bc.ca                    Embrace and defend.
http://ansuz.sooke.bc.ca/

Re: Terrain images proposal

[Eric McDonald]

mskala@ansuz.sooke.bc.ca wrote:

>>you seem to be suggesting that a source map image name be associated 
>>with each hex (cell). Is there a need to have multiple source map 
>>images? Or, can we get by with a GDL global that indicates a single 
>>source image, and thus not have to associate it on a per hex (cell) basis?
> 
> My thinking was that someone might want to have a map which is mostly
> generated from tiles in the normal way, but with a few small (in relation
> to the map size) images pasted in in places where the tiling doesn't look
> good enough.  In such a case they might want to use two different source
> images, although anything that could be done that way could also be done
> by putting the data into one image and looking at different parts of
> it.  Part of my thinking was that it would be nice to not have to edit or
> specially generate an image - if we could just use GDL to direct XConq on
> how to cut chunks out of one or more existing images, then we have one
> less tool to write or manual processing/editing step to do in defining a
> game.

The idea is interesting. The only problem is that Xconq has 4 different 
GUI's that "need" to be maintained. Supposing that you actually figured 
out a good way to implement your above suggestion, you would most likely 
end up writing the code 4 different times. (The "5th GUI", the curses 
interface, shouldn't cause too many problems, I think. :-)

Another issue is "z-ordering". You would probably have to provide some 
mechanism so that the order in which redraws were stacked could be 
determined (not only can regular hexes and embedded images overlap with 
one another, but multiple embedded images can overlap with one another 
as well).

> One concern I have about using a layer to specify x,y coordinates is that
> then the data to go into the layer probably can't be manually generated,
> so it means adding another tool to choose the x,y coordinates and put them
> in that layer for XConq to read.  

Right. I think that with the present set of problems we are facing, 
there is no good solution that will come cheaply. Either we will end up 
developing external tools or we will end up doing some (potentially 
heavy?) hacking of Xconq.

>If we could instead specify "start at
> these coordinates, fill these many cells up and these many cells over, use
> this step size" then it becomes something that we can manually specify,
> at the cost of only slight complexity in the XConq code that reads that
> specification.

I think the more serious issues will occur in the display aspect of 
things and not the reading aspect.

> Maybe we could use a layer and also add a "by-grid" or similar layer
> sub-form to automatically generate the coordinates.  That might address my
> concern while still using an existing data structure.

Yes, possibly.

> Well, either you cover the entire map with your image, or else you already
> face, anyway, the issue that your image has to match up along its edges
> with the tiled terrain that it's going next to.  If we allow some cells to
> have image-overrides and other cells to not have them, then I think we're
> going to get that issue in any case.

True.

Eric

Re: Terrain images proposal

[mskala]

On Sun, 26 Sep 2004, Eric McDonald wrote:
> Another issue is "z-ordering". You would probably have to provide some 
> mechanism so that the order in which redraws were stacked could be 
> determined (not only can regular hexes and embedded images overlap with 
> one another, but multiple embedded images can overlap with one another 
> as well).

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.  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.  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.  If you attempt to
define more than one override image for a cell position, that's either a
syntax error, or the last one you define overwrites any previous
one.  Stacking order is never an issue - there is only one in the stack.
It does become an issue for aux terrain, but it always was.

If you attempt to define an override image for a cell that is "normal"
terrain, that's fine, no problem, then it stops being "normal" terrain.  
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.

A critical point here is that the entire rectangle in the image would not
necessarily appear on the map.  When you tell XConq "take this cell out of
this image" then that cell becomes a hexagonal window into the image, so
unless you do that with a cell that goes over the edge of the image (and
normally you wouldn't), you don't see the edge of the image.  That's not
so unusual, because it's the way that terrain images already work; you
specify a recantangle in an image, but only the hex shape is actually
visible.
-- 
Matthew Skala
mskala@ansuz.sooke.bc.ca                    Embrace and defend.
http://ansuz.sooke.bc.ca/

Re: Terrain images proposal

[Eric McDonald]

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

Re: Terrain images proposal

[mskala]

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/

Re: Terrain images proposal

[Eric McDonald]

mskala@ansuz.sooke.bc.ca wrote:

> Whichever one the designer specified last - just like properties and table
> entries. 

That's probably fine.

> The idea is that the cell
> only *has* one image; 

Well sure. I don't think either of us would dispute that.

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

Right. I figured that this is what you meant from your previous 
response. This is reasonable; I see no real issues with it.

> The region
> stops hard at the hex boundaries, though.

I think this is the only part of your proposal that I was initially 
unclear about.

Eric