public inbox for xconq7@sourceware.org
 help / color / mirror / Atom feed
From: mskala@ansuz.sooke.bc.ca
To: Eric McDonald <mcdonald@phy.cmich.edu>
Cc: xconq7@sources.redhat.com
Subject: Re: Terrain images proposal
Date: Sun, 26 Sep 2004 16:43:00 -0000	[thread overview]
Message-ID: <Pine.LNX.4.21.0409261206170.20741-100000@diamond.ansuz.sooke.bc.ca> (raw)
In-Reply-To: <4156E7EB.9080705@phy.cmich.edu>

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/

  reply	other threads:[~2004-09-26 16:30 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 [this message]
2004-09-26 17:30     ` Eric McDonald
2004-09-26 17:55       ` mskala
2004-09-26 18:23         ` Eric McDonald
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=Pine.LNX.4.21.0409261206170.20741-100000@diamond.ansuz.sooke.bc.ca \
    --to=mskala@ansuz.sooke.bc.ca \
    --cc=mcdonald@phy.cmich.edu \
    --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).