* GIS Tutorial Online
@ 2004-09-25 2:12 D. Cooper Stevenson
2004-09-25 4:57 ` Eric McDonald
0 siblings, 1 reply; 8+ messages in thread
From: D. Cooper Stevenson @ 2004-09-25 2:12 UTC (permalink / raw)
To: Xconq Mailing List
All,
Nice GIS image here:
http://wiki.xconqgis.org/images/grass_tutorial/kfalls.jpg
Complete tutorial (including screen images) on the Wiki here:
http://wiki.xconqgis.org/index.php?UsgsMapImportHowto
There's so much work to do! I'll answer each of your emails soon...
-Coop
--
-------------------------------------------------------------
| Cooper Stevenson | Em: cooper@gencom.us |
| GenCom | Ph: 541.924.9434 |
| "Working For IT" | Www: http://www.gencom.us |
--------------------------------------------------------------
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: GIS Tutorial Online
2004-09-25 2:12 GIS Tutorial Online D. Cooper Stevenson
@ 2004-09-25 4:57 ` Eric McDonald
[not found] ` <1096084730.4154ecfabcb19@mail.gencom.us>
0 siblings, 1 reply; 8+ messages in thread
From: Eric McDonald @ 2004-09-25 4:57 UTC (permalink / raw)
To: cstevens; +Cc: Xconq Mailing List
D. Cooper Stevenson wrote:
> Complete tutorial (including screen images) on the Wiki here:
>
> http://wiki.xconqgis.org/index.php?UsgsMapImportHowto
Nice work.
Thanks,
Eric
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: GIS Tutorial Online
[not found] ` <1096084730.4154ecfabcb19@mail.gencom.us>
@ 2004-09-25 14:04 ` Eric McDonald
2004-09-25 16:16 ` mskala
0 siblings, 1 reply; 8+ messages in thread
From: Eric McDonald @ 2004-09-25 14:04 UTC (permalink / raw)
To: cstevens; +Cc: xconq7
sales@gencom.us wrote:
> Now, one way to do this is to define a unique terrain type per tile. This, I
> think (and seems to be the consensus), does not seem to be the "cleanest" way
> to go.
I think it depends a lot on what you are trying to achieve. If you are
planning on having more than one type of data associated with each hex
(elevation, vegetation, terrain ruggedness), then it would seem that you
would run into a multidimensional "data boxing" problem (which can be
solved with multidimensional boxing routines that you would have to
write) if you were trying to use less than 1 terrain type per image. If
you only care about elevation data, say, then you can easily just bin
the data according to elevation ranges, and thus don't need 1 terrain
type per hex image. The alternative to multidimensional boxing is to
have a 1:1 correspondance between terrain type and hex image.
I'm not sure what Matthew (IIRC?) had in mind when he disagreed with the
1 terrain type per hex image idea. Maybe we are all miscommunicating
what we really mean....
> It would be better, I think, to specify each tile as a file name (probably x,y
> such as 0x0.gif, 0x1.gif and so on) and have these images referenced by Xconq
> individually.
I have no problem with multiple files in an intermediate processing
step, but all the terrain images for a given terrain image set should be
kept in one file, when all is said and done. See 'stdt44x48.gif',
'advt44x48.gif', and 'civt44x48.gif' in the 'images' directory for
examples of what I am talking about.
Also, see 'terrain.imf' in the 'lib' directory to see how the various
images are indexed within the files and assigned names.
> I know that Hans created and implemented a similiar patch that permitted units
> to have more than one image.
Right. There are several places you need to look to see how this was
handled. A good starting pointing would be the properties files.
If you look in 'utype.def' in the 'kernel' directory, you will notice
that the 'image-name' property is a list; you can tell this because it
is a "DEF_UPROP_L" macro (the "L" is for "list"). By contrast, if you
look in 'ttype.def', you will notice that the 'image-name' property is a
string; you can tell this because it is a "DEF_TPROP_S" macro (the "S"
is for "string").
Now, if you want to find out places where the 'image-name' property for
units is used in the Xconq code, then you can just search the C source
files in the 'kernel' directory and the various UI directories for
'u_image_name', as this is Xconq's internal name for the property (as is
indicated in the definition).
The other thing to do is search for 'image-name' in 'keyword.def'. This
file enumerates all of the internal constants associated with GDL
(Xconq's game design language) keywords. You will find that the name of
the constant associated with 'image-name' is 'K_IMAGE_NAME'; you can
search Xconq's sources for this to find out where and how it is being
used. You most likely encounter it in 'read.c' and 'write.c', which are
related to the reading in of Xconq games and the writing out of Xconq
saved games.
A final note: IIRC, there are arrays that store the unit images (or at
least their name lists/strings), so that they can be looked up and
utilized quickly. One would probably want to do the same if one chooses
this route for terrain images.
Of course, if one chooses to not bother with mutliple images per terrain
type, then writing new Xconq code should not be necessary....
Hope that helps,
Eric
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: GIS Tutorial Online
2004-09-25 14:04 ` Eric McDonald
@ 2004-09-25 16:16 ` mskala
2004-09-25 17:32 ` Eric McDonald
[not found] ` <1096130231.41559eb7e1508@mail.gencom.us>
0 siblings, 2 replies; 8+ messages in thread
From: mskala @ 2004-09-25 16:16 UTC (permalink / raw)
To: Eric McDonald; +Cc: cstevens, xconq7
On Fri, 24 Sep 2004, Eric McDonald wrote:
> I'm not sure what Matthew (IIRC?) had in mind when he disagreed with the
> 1 terrain type per hex image idea. Maybe we are all miscommunicating
> what we really mean....
Just that it seems like it'll multiply terrain types unnecessarily, and
terrain types are somewhat expensive. If I have two chunks of almost
identical desert, but they have different images, then I have to duplicate
the definition of "desert" throughout my game definition. Even if I
define a list variable for "all desert hexes", that's only a syntactic
convenience - the actual game definition still has two separate complete
copies of the definition. It's especially a problem because "two" in this
case is probably more like "hundreds". I don't want to look at the help
menu that will result from having hundreds, or thousands, of defined
terrain types... I'd much rather be able to define images per-hex instead
of per-terrain-type; that seems like it would serve the same goal and be
much nicer.
On multidimensional "binning", that's a well-studied problem and relevant
to my research, so I'd be happy to expound on the different standard
algorithms for it if people would like. I did some of that (with just two
dimensions) in defining terrain types on the Antarctica map, as described
in the document about that which I posted on the Wiki; there, I wasn't
doing it in an automated way but just by hand, manually examining the
scatter plot and tweaking classification rules to get results I liked.
By the way, has anyone tried playing the "standard game adapted for
Antartica" module I posted? I'd be interested to hear how people liked it
if they tried it.
> I have no problem with multiple files in an intermediate processing
> step, but all the terrain images for a given terrain image set should be
> kept in one file, when all is said and done. See 'stdt44x48.gif',
It would be really nice, too, if that one file could be just the direct
image (possibly scaled to size), and then XConq smart enough to clip out
hexagonal chunks in the right places. That would mean changing the
read-from-image code to use a hex grid corresponding to the map instead of
the current square grid, but it would mean eliminating an especially nasty
cut-and-rearrange step in creating the file.
--
Matthew Skala
mskala@ansuz.sooke.bc.ca Embrace and defend.
http://ansuz.sooke.bc.ca/
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: GIS Tutorial Online
2004-09-25 16:16 ` mskala
@ 2004-09-25 17:32 ` Eric McDonald
[not found] ` <1096130231.41559eb7e1508@mail.gencom.us>
1 sibling, 0 replies; 8+ messages in thread
From: Eric McDonald @ 2004-09-25 17:32 UTC (permalink / raw)
To: mskala; +Cc: cstevens, xconq7
mskala@ansuz.sooke.bc.ca wrote:
> Just that it seems like it'll multiply terrain types unnecessarily, and
> terrain types are somewhat expensive. If I have two chunks of almost
> identical desert, but they have different images, then I have to duplicate
> the definition of "desert" throughout my game definition. Even if I
> define a list variable for "all desert hexes", that's only a syntactic
> convenience - the actual game definition still has two separate complete
> copies of the definition. It's especially a problem because "two" in this
> case is probably more like "hundreds". I don't want to look at the help
> menu that will result from having hundreds, or thousands, of defined
> terrain types... I'd much rather be able to define images per-hex instead
> of per-terrain-type; that seems like it would serve the same goal and be
> much nicer.
In principle, I agree with you. I think that it comes down to the
question of whether you or Coop are up to hacking on Xconq to add the
necessary support, either more than one image per terrain type or
pulling an hex image directly from a map image (as you suggest below). I
have enough other things I plan on doing that I doubt I would
participate in such an endeavor, except to merge and test patches, and
provide feedback and guidance where I am able. I am certainly not going
to discourage either of you from working on the kernel and UI code.
> On multidimensional "binning", that's a well-studied problem
Sure, I know. And I only called it "boxing" because I thought people
might be tired of seeing me write "bin" or participles thereof over the
course of the last few days....
>and relevant
> to my research, so I'd be happy to expound on the different standard
> algorithms for it if people would like.
Good.
> By the way, has anyone tried playing the "standard game adapted for
> Antartica" module I posted? I'd be interested to hear how people liked it
> if they tried it.
I tried your original when you posted it to the list. I haven't tried
any updates that you may have made to it. I've been pretty busy just
trying to keep up with Elijah lately. :-)
>>I have no problem with multiple files in an intermediate processing
>>step, but all the terrain images for a given terrain image set should be
>>kept in one file, when all is said and done. See 'stdt44x48.gif',
>
> It would be really nice, too, if that one file could be just the direct
> image (possibly scaled to size), and then XConq smart enough to clip out
> hexagonal chunks in the right places. That would mean changing the
> read-from-image code to use a hex grid corresponding to the map instead of
> the current square grid, but it would mean eliminating an especially nasty
> cut-and-rearrange step in creating the file.
This would be a useful feature. One could then envision ye olde time map
with a fancy compass rose, spouting whales, and sea monsters as part of
the background artwork. I would certainly be supportive of anyone who
wished to add such a feature.
Eric
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: GIS Tutorial Online
[not found] ` <1096130231.41559eb7e1508@mail.gencom.us>
@ 2004-09-25 17:59 ` Eric McDonald
2004-09-25 19:24 ` D. Cooper Stevenson
0 siblings, 1 reply; 8+ messages in thread
From: Eric McDonald @ 2004-09-25 17:59 UTC (permalink / raw)
To: cstevens; +Cc: mskala, xconq7
sales@gencom.us wrote:
> Quoting mskala@ansuz.sooke.bc.ca:
>>I'd much rather be able to define images per-hex instead
>>of per-terrain-type; that seems like it would serve the same goal and be
>>much nicer.
>
> To me this makes sense. This would mean that map attributes are defined in a
> uniform array per tile. The _tile_ is the object. It then carries with it a
> number of attributes such as terrain type, elevation, climate, etc.
An individual hex only has certain attributes that can be associated
with. Among them, terrain type and elevation. As it stands now, images
are only associated with terrain types, and not directly with hexes. An
hex acquires an image via its terrain type. As far as other attributes
such as climate, terrain ruggedness, vegetation, etc... go, you must
find some way of artificially simulating those attributes. I suggested
one way (creating defined groupings in the game definition file), and
Lincoln suggested another (using coatings as sort of customizable
"attribute layers").
It should be noted that Xconq has the concept of layers, which were
mentioned in a references I sent you a while back ago. Layers track
things such as terrain, winds, coatings, connectors, borders, land or
sea, etc.... One can argue about what a Xconq map hex is, but one way to
look at it is something that has a coordinate position and has "depth"
into one or more layers. All hexes have depth into the terrain layer, as
this tracks terrain type and how is an hex is able to "know" what it
looks like.
> Does this mean major changes to the Xconq code, Eric? Would we have to change
> the Xconq kernel or could we get away with doing this on the module side?
I have made no attempt to quantify how much work will be involved. In
the reply I sent you last night (to your "cstevens" address and not the
"sales" address), I outlined some of the areas you will probably want to
look at. I think it is reasonable to assume that you will have at least
some coding that needs to be done in the kernel and the user interfaces.
>>It would be really nice, too, if that one file could be just the direct
>>image (possibly scaled to size), and then XConq smart enough to clip out
>>hexagonal chunks in the right places. That would mean changing the
>>read-from-image code to use a hex grid corresponding to the map instead of
>>the current square grid, but it would mean eliminating an especially nasty
>>cut-and-rearrange step in creating the file.
>
> I agree. This way if Eligah wanted to create his "Lord of the Rings" map, he
> could simply do so starting with a Middle Earth map
If people want to try doing things this way, it could probably be done
by creating two new layers (x-pixel-coords and y-pixel-coords), which
would contain the pixel coords within the map image that are associated
with each hex. Then, instead of indirectly accessing an hex image
through terrain type, it would be pulled from this layer instead. I
haven't thought through the details; _just throwing out an idea....
Eric
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: GIS Tutorial Online
2004-09-25 17:59 ` Eric McDonald
@ 2004-09-25 19:24 ` D. Cooper Stevenson
2004-09-26 2:29 ` Eric McDonald
0 siblings, 1 reply; 8+ messages in thread
From: D. Cooper Stevenson @ 2004-09-25 19:24 UTC (permalink / raw)
To: Eric McDonald; +Cc: mskala, Xconq Mailing List
On Sat, 2004-09-25 at 10:32, Eric McDonald wrote:
>
> If people want to try doing things this way, it could probably be done
> by creating two new layers (x-pixel-coords and y-pixel-coords), which
> would contain the pixel coords within the map image that are associated
> with each hex. Then, instead of indirectly accessing an hex image
> through terrain type, it would be pulled from this layer instead. I
> haven't thought through the details; _just throwing out an idea....
>
This would save a _ton_ of work. Do you think you could still give
others the flexibility of assigning other tile attributes (vegetation,
climate, rainfall, etc) using this method?
-Coop
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: GIS Tutorial Online
2004-09-25 19:24 ` D. Cooper Stevenson
@ 2004-09-26 2:29 ` Eric McDonald
0 siblings, 0 replies; 8+ messages in thread
From: Eric McDonald @ 2004-09-26 2:29 UTC (permalink / raw)
To: cstevens; +Cc: mskala, Xconq Mailing List
D. Cooper Stevenson wrote:
> On Sat, 2004-09-25 at 10:32, Eric McDonald wrote:
>
>>If people want to try doing things this way, it could probably be done
>>by creating two new layers (x-pixel-coords and y-pixel-coords), which
>>would contain the pixel coords within the map image that are associated
>>with each hex. Then, instead of indirectly accessing an hex image
>>through terrain type, it would be pulled from this layer instead. I
>>haven't thought through the details; _just throwing out an idea....
>>
> This would save a _ton_ of work. Do you think you could still give
> others the flexibility of assigning other tile attributes (vegetation,
> climate, rainfall, etc) using this method?
Xconq does not inherently know anything about the attributes you listed,
and so it would currently be meaningless to associate portions of an
image created from such GIS data with them. To handle such things, you
would need to determine how they were relevant to your game, and then
use the appropriate GDL tables and properties to emulate them with
respect to their repesentation as coatings, say.
Eric
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2004-09-25 19:24 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-09-25 2:12 GIS Tutorial Online D. Cooper Stevenson
2004-09-25 4:57 ` Eric McDonald
[not found] ` <1096084730.4154ecfabcb19@mail.gencom.us>
2004-09-25 14:04 ` Eric McDonald
2004-09-25 16:16 ` mskala
2004-09-25 17:32 ` Eric McDonald
[not found] ` <1096130231.41559eb7e1508@mail.gencom.us>
2004-09-25 17:59 ` Eric McDonald
2004-09-25 19:24 ` D. Cooper Stevenson
2004-09-26 2:29 ` Eric McDonald
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).