* Terrain images proposal @ 2004-09-26 15:24 mskala 2004-09-26 16:30 ` Eric McDonald 0 siblings, 1 reply; 8+ messages in thread From: mskala @ 2004-09-26 15:24 UTC (permalink / raw) To: xconq7 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/ ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Terrain images proposal 2004-09-26 15:24 Terrain images proposal mskala @ 2004-09-26 16:30 ` Eric McDonald 2004-09-26 16:43 ` mskala 0 siblings, 1 reply; 8+ messages in thread From: Eric McDonald @ 2004-09-26 16:30 UTC (permalink / raw) To: mskala; +Cc: xconq7 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Terrain images proposal 2004-09-26 16:30 ` Eric McDonald @ 2004-09-26 16:43 ` mskala 2004-09-26 17:30 ` Eric McDonald 0 siblings, 1 reply; 8+ messages in thread From: mskala @ 2004-09-26 16:43 UTC (permalink / raw) To: Eric McDonald; +Cc: xconq7 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/ ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Terrain images proposal 2004-09-26 16:43 ` mskala @ 2004-09-26 17:30 ` Eric McDonald 2004-09-26 17:55 ` mskala 0 siblings, 1 reply; 8+ messages in thread From: Eric McDonald @ 2004-09-26 17:30 UTC (permalink / raw) To: mskala; +Cc: xconq7 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Terrain images proposal 2004-09-26 17:30 ` Eric McDonald @ 2004-09-26 17:55 ` mskala 2004-09-26 18:23 ` Eric McDonald 0 siblings, 1 reply; 8+ messages in thread From: mskala @ 2004-09-26 17:55 UTC (permalink / raw) To: Eric McDonald; +Cc: xconq7 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/ ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Terrain images proposal 2004-09-26 17:55 ` mskala @ 2004-09-26 18:23 ` Eric McDonald 2004-09-26 19:19 ` mskala 0 siblings, 1 reply; 8+ messages in thread From: Eric McDonald @ 2004-09-26 18:23 UTC (permalink / raw) To: mskala; +Cc: xconq7 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Terrain images proposal 2004-09-26 18:23 ` Eric McDonald @ 2004-09-26 19:19 ` mskala 2004-09-27 18:05 ` Eric McDonald 0 siblings, 1 reply; 8+ messages in thread From: mskala @ 2004-09-26 19:19 UTC (permalink / raw) To: Eric McDonald; +Cc: xconq7 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/ ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Terrain images proposal 2004-09-26 19:19 ` mskala @ 2004-09-27 18:05 ` Eric McDonald 0 siblings, 0 replies; 8+ messages in thread From: Eric McDonald @ 2004-09-27 18:05 UTC (permalink / raw) To: mskala; +Cc: xconq7 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2004-09-26 19:19 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-09-26 15:24 Terrain images proposal 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 2004-09-26 19:19 ` mskala 2004-09-27 18:05 ` 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).