public inbox for xconq7@sourceware.org
 help / color / mirror / Atom feed
* Image handling: update on my status and plans
@ 2004-12-19  7:31 mskala
  2004-12-22 20:59 ` Eric McDonald
  2004-12-23  5:00 ` Isometric Terrain Elijah Meeks
  0 siblings, 2 replies; 8+ messages in thread
From: mskala @ 2004-12-19  7:31 UTC (permalink / raw)
  To: xconq7, xconq-hackers

Hi, all.  I've been busy for the last few days with school stuff (and
writing the world's smallest P2P file sharing application, which you may
have seen on Slashdot), and I'm about to go on vacation December
21-January 1, during which time I'll only have limited email access and
no real chances to hack on XConq, but here's an update on where I stand
and what I'm up to at the moment:

The bug that has some terrain types disappearing in the smallest
magnification in Tcl/Tk isometric mode:  it appears that what's happening
is that for some terrain types, but not others, there is no "flat colour"
generated.  This isn't new with the scaling code, it seems to be a very
old bug and even includes image families for which the designer has
actually specified a flat colour.  The result is that those fields of the
data structure are left uninitialized, sometimes end up negative, and the
interface skips over those pixels.  I don't know more details yet.

The "yellow pixels" bug in Tcl/Tk isometric:  I'm still not quite sure
what's going on here, but it seems to be associated only with certain
terrain types, (usually, water), and it displays weird patterning
behaviour that makes it look like it's associated with grid cell
coordinates rather than images.  Hypothesis: the interface decides how far
up to shift each cell based on the cell's elevation, and draws a
"pedastal" of that height underneath the cell image.  The bad cells seem
to all be at zero elevation, and all be drawn one pixel lower on the
screen than they should be.  Instead of seeing a one-pixel rim above the
cell we see scattered pixels because the images are designed with a
"relief" effect (which I think is suspect because water should be smooth,
but that's the way they're designed) and the poking-up pixels of the
relief hide all but a few pixels in the dead space.  Some kind of rounding
error in the vertical position deciding code seems like it could plausibly
cause this, especially because it appears in diagonal bands across the
screen - maybe X is being added to Y and rounded down where it should be
rounded up, or something like that, in calculating the height of the
pedastals.

Come to think of it, the same thing might be happening in the lowest
magnification, too - if it's drawing one-pixel images one pixel lower than
they should be, and clipping them at the bottom of the space they're
supposed to be in, then it would be clipping them away entirely and
producing the display we're seeing.  So these two bugs may actually be the
same bug; but it's unlikely that I'll have time to pursue it beyond
writing this message until January.

Caching, scaling, etc:  What I think needs to happen is for there to be an
API for requesting images with much more flexibility than it currently
has.  When an interface requests an image, instead of just specifying a
family and a size (or range of sizes, with my recent patch) it should
specify:

* The unit, terrain, or other type this image is for
* The individual unit or individual terrain cell coordinates, if any (or
  "generic")
* The image size
* The view angle, which I think is best specified as a 3x2 matrix
  describing what direction (in the returned image) is the image X,
  the image Y, and the image Z.  Size would actually be best merged into
  these numbers too, although I anticipate that I may have to write some
  "utility" functions to populate the matrix correctly for standard
  overhead and isometric views.
* Whether colour or black and white is desired
* Whether a tile instead of an image is acceptable, unacceptable, or
  preferred.
* As well as the current callbacks, there needs to be a callback
  for invalidating the "hook" information associated with an image.
* note it *doesn't* specify the image family anymore... that's for the
  kernel to decide!  Similarly, issues like "which one of the several
  subimages for this terrain type?" become the kernel's decision rather
  than the interface's, so that changes to these decisions (as needed
  to implement satellite map) only have to be implemented in one place.

The interfaces need to be modified to make these calls, and to respect the
invalidation callback - so they have to make API calls to the kernel every
time they want to use images.  For its part, the kernel has to serve those
API calls fast enough on average for interfaces to be able to afford not
to cache images themselves.  The current caching-by-interfaces behaviour
means not only that the kernel can never destroy an image once it exists
(because the interface might still want it) but also that the interfaces
may incorrectly apply a cached image to something it doesn't belong on.
I think that may be the cause of Elijah's recent low-priority bug (with
the units not having customized images when they first appear) - the
interface is applying its cached "generic" image for that unit type - and
it's also the cause of a lot of headaches in dealing with things like the
hexgrid modifications (for which I have partial code but don't want to
proceed further until the API changes have been made).

So, those API changes (and making the data structures 32-bit) are what I
hope to do in the new CVS branch.  What I would like would be for one
overhead image at high resolution to become the source for all the other
views and sizes, with opportunistic use of other designer-supplied images
if they exist.  Isometric (or, hypothetically, other 3D) images raise some
issues, because in order to do the "relief" effect seen in the current
system really properly, we'd need to start with an overhead image and a
height field and then render it.  That's do-able, but a fair bit of work
and an imposition on the image designers, too, to make the height fields.
An alternative would be to (configurably, we can hope) just go to a
designer-specified image like the ones we're using, with the relief
permanently built in, and then not rotate it when the view rotates.
That's what we do now, and it looks actually pretty good, but it's visibly
a symbolic rather than realistic representation of terrain, and we'd
still need to think about rotation for satellite images to work because
those won't stand for rotating the entire image without rotating the
individual hexes.

Code to manage the cache would also have to be written, but I think that's
easy - just build a circular double-linked list of images that have
been synthesized (alongside whatever other structure we're storing them
in), move a cached image to the front whenever we search for it and find
it in the cache, and cannibalize the one from the back whenever we want to
generate a new image and have already got a full cache.  As long as the
interfaces aren't keeping stale pointers around, we're fine.
-- 
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: Image handling: update on my status and plans
  2004-12-19  7:31 Image handling: update on my status and plans mskala
@ 2004-12-22 20:59 ` Eric McDonald
  2005-01-04 19:15   ` mskala
  2004-12-23  5:00 ` Isometric Terrain Elijah Meeks
  1 sibling, 1 reply; 8+ messages in thread
From: Eric McDonald @ 2004-12-22 20:59 UTC (permalink / raw)
  To: mskala; +Cc: xconq7, xconq-hackers

mskala@ansuz.sooke.bc.ca wrote:
> Hi, all.  I've been busy for the last few days with school stuff (and
> writing the world's smallest P2P file sharing application, which you may
> have seen on Slashdot),

Nifty. Looks like they didn't spell your surname correctly though. I see 
that Ed Felten seems to have fueled your competitiveness; I recognize 
that name from elsewhere; I think he had something to do with the DeCSS 
stuff or maybe a DMCA lawsuit....

> and I'm about to go on vacation December
> 21-January 1, 

Enjoy the holidays.

> The "yellow pixels" bug in Tcl/Tk isometric:  I'm still not quite sure
> what's going on here, but it seems to be associated only with certain
> terrain types, (usually, water), and it displays weird patterning
> behaviour that makes it look like it's associated with grid cell
> coordinates rather than images.  Hypothesis: the interface decides how far
> up to shift each cell based on the cell's elevation, and draws a
> "pedastal" of that height underneath the cell image.  The bad cells seem
> to all be at zero elevation, and all be drawn one pixel lower on the
> screen than they should be.  

I brushed past the responsible code a few times earlier today. After I 
get done with my 'draw_unit_*' remodeling/simplifying/API-improving, I 
will try to remember to take a look at this.

>Instead of seeing a one-pixel rim above the
> cell we see scattered pixels because the images are designed with a
> "relief" effect (which I think is suspect because water should be smooth,
> but that's the way they're designed)

The terrain generator ensures that the all terrain with the 'liquid' 
property set has a uniform elevation with all neighboring liquid terrain.

> * Whether a tile instead of an image is acceptable, unacceptable, or
>   preferred.

Good thought.

> * note it *doesn't* specify the image family anymore... that's for the
>   kernel to decide!  Similarly, issues like "which one of the several
>   subimages for this terrain type?" become the kernel's decision rather
>   than the interface's, so that changes to these decisions (as needed
>   to implement satellite map) only have to be implemented in one place.

This will be good, I think. You may also want a way to pass in interface 
hints. For example, if Sdlconq doesn't naturally support tiling, then it 
may need to tell the kernel that so that it can choose an appropriate 
flat color instead.

> The interfaces need to be modified to make these calls, and to respect the
> invalidation callback - so they have to make API calls to the kernel every
> time they want to use images. 

I am presently refactoring the Tkconq unit image code. I think that 
after I am done, it will be easier to implement any API changes from the 
Tkconq perspective.

As far as the interfaces calling the kernel every time for an image, I 
am mostly for it, since this keep things more consistent and take most 
of the image-handling burden away from the interfaces. However, if we 
ever evolve Xconq into a client-server model, I might be concerned about 
traffic in the case of a network game. Of course, the image-handling 
part of the "kernel" might be able to be linked into the client apps. I 
would then want to make sure that we were using unit views rather than 
raw units in the API, since only the server/arbiter should be able to 
touch raw units (clients could request shadow copies, but only for the 
sides they were associated with).
But, that is all a bunch of what-ifs in the future. I think your API 
recommendations are a move in the right direction and should be pursued. 
We can deal with other hurdles later.

> I think that may be the cause of Elijah's recent low-priority bug (with
> the units not having customized images when they first appear) - the
> interface is applying its cached "generic" image for that unit type 

I share this suspicion.

> So, those API changes (and making the data structures 32-bit) are what I
> hope to do in the new CVS branch.  

It's all yours. Probably the most I'll do with it is occasionally merge 
in diffs from the mainline.

>What I would like would be for one
> overhead image at high resolution to become the source for all the other
> views and sizes, with opportunistic use of other designer-supplied images
> if they exist.

I think this is the right approach.

>  Isometric (or, hypothetically, other 3D) images raise some
> issues, because in order to do the "relief" effect seen in the current
> system really properly, we'd need to start with an overhead image and a
> height field and then render it.  That's do-able, but a fair bit of work
> and an imposition on the image designers, too, to make the height fields.

In the case of using height fields, it might be better to use a solid 
color or a elevation-based color gradient (thinking in terms of 
snow-capped mountains).
In times that I have thought about "3D terrain" in the past, it had not 
occurred to me that designer-specified height fields might be specified. 
My thinking has been:
(1) Calculate elevation gradients (slopes) from cell edge to cell edge.
(2) Generate a random elevation "spectrum". Let the designer specify 
error bars for both the amplitude and peak density.
(3) FFT (or otherwise convolve) the spectrum into a "noisy" function.
(4) Add said function to the calculated slope lines.
(5) Sample points on the resultant functions; these points are the 
height field.
It might also be sufficient to just throw down some splines. As long as 
the endpoints are at the correct heights at the cell edges, the designer 
could just specify a "ruggedness" or "elevation variation" parameter, 
and intra-cell elevation variation could be inferred from that.

I do think that anything involving 3D terrain with true intra-cell 
relief is probably worth another separate branch, and is probably too 
much bother for the present, considering what else we have going on. 
Then again, if you can do it in 6 lines....

> Code to manage the cache would also have to be written, but I think that's
> easy - just build a circular double-linked list of images that have
> been synthesized (alongside whatever other structure we're storing them
> in), move a cached image to the front whenever we search for it and find
> it in the cache, and cannibalize the one from the back whenever we want to
> generate a new image and have already got a full cache.  As long as the
> interfaces aren't keeping stale pointers around, we're fine.

Yeah, that would probably work. At minimum, the cache would have to be 
sized as numutypes + numttypes + nummtypes, otherwise there will be too 
many cache misses in the worst case (one of everything shown in the map 
window), and it would start to resemble a hamster running on the inside 
of a wheel.

Eric

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Isometric Terrain
  2004-12-19  7:31 Image handling: update on my status and plans mskala
  2004-12-22 20:59 ` Eric McDonald
@ 2004-12-23  5:00 ` Elijah Meeks
  2004-12-23  6:25   ` Eric McDonald
  2004-12-24 20:20   ` Stan Shebs
  1 sibling, 2 replies; 8+ messages in thread
From: Elijah Meeks @ 2004-12-23  5:00 UTC (permalink / raw)
  To: xconq7, xconq-hackers


It's been a while since I checked out the isometric
terrain feature and it looks spectacular.  Has it
always looked this good or is this the result of
Matthew's improvements?  A couple questions:

Is there any support for elevation and making certain
hexes higher than others?  I didn't notice but it
could have been that the games I was playing didn't
have any elevation data.

What image does it call for iso terrain?  In Opal, it
defaults to the base color and I'd like to fix this.


		
__________________________________ 
Do you Yahoo!? 
The all-new My Yahoo! - What will yours do?
http://my.yahoo.com 

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Isometric Terrain
  2004-12-23  5:00 ` Isometric Terrain Elijah Meeks
@ 2004-12-23  6:25   ` Eric McDonald
  2004-12-24 20:20   ` Stan Shebs
  1 sibling, 0 replies; 8+ messages in thread
From: Eric McDonald @ 2004-12-23  6:25 UTC (permalink / raw)
  To: Elijah Meeks; +Cc: xconq7, xconq-hackers, xconq-developers

Elijah Meeks wrote:

> Is there any support for elevation and making certain
> hexes higher than others?

It works fine with the Advances game.

> What image does it call for iso terrain?  In Opal, it
> defaults to the base color and I'd like to fix this.

With the Tcl/Tk interface, the code seems to be finding an image which 
has a height that is about 75% of the width. This corresponds well to 
'stdt13x9i.gif' and 'stdt48x33i.gif', both are somewhat less than 3/4 
but greater than 2/3 of the width, and so when Xconq is drawing in 
isometric mode, it will look up those images (see 'terrain.imf' for 
details).

However, I would caution you from going down that route, as Matthew is 
proposing to generate everything (including isometric views) from a 
single overhead image. So, your work could end up being all for naught.

Eric

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Isometric Terrain
  2004-12-23  5:00 ` Isometric Terrain Elijah Meeks
  2004-12-23  6:25   ` Eric McDonald
@ 2004-12-24 20:20   ` Stan Shebs
  2004-12-25 19:57     ` Elijah Meeks
  1 sibling, 1 reply; 8+ messages in thread
From: Stan Shebs @ 2004-12-24 20:20 UTC (permalink / raw)
  To: Elijah Meeks; +Cc: xconq7, xconq-hackers

Elijah Meeks wrote:

>It's been a while since I checked out the isometric
>terrain feature and it looks spectacular.  Has it
>always looked this good or is this the result of
>Matthew's improvements?  A couple questions:
>
>Is there any support for elevation and making certain
>hexes higher than others?  I didn't notice but it
>could have been that the games I was playing didn't
>have any elevation data.
>
>
Panzer and Gettysburg both show you elevations. Note that there
is a command to control vertical exaggeration, which is
interesting to play with. The games also show you that doing
elevation is not straightforward with tiles - in this day and
age, it would actually be both simpler and more efficient to
build a new interface that used full 3D polygons.

>What image does it call for iso terrain?  In Opal, it
>defaults to the base color and I'd like to fix this.
>
I made specially-shaped images, partly because you want a bit
of overlap - trees should partly cover grassland behind, etc.

Stan


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Isometric Terrain
  2004-12-24 20:20   ` Stan Shebs
@ 2004-12-25 19:57     ` Elijah Meeks
  0 siblings, 0 replies; 8+ messages in thread
From: Elijah Meeks @ 2004-12-25 19:57 UTC (permalink / raw)
  To: Stan Shebs; +Cc: xconq7, xconq-hackers

> elevation is not straightforward with tiles - in
> this day and
> age, it would actually be both simpler and more
> efficient to
> build a new interface that used full 3D polygons.

Ahem...  Um, it is Christmas, you know...

> I made specially-shaped images, partly because you
> want a bit
> of overlap - trees should partly cover grassland
> behind, etc.

I noticed this effect with the mountains, hadn't
noticed it so much with the trees, and it's very cool.
 




		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - now with 250MB free storage. Learn more.
http://info.mail.yahoo.com/mail_250

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Image handling: update on my status and plans
  2004-12-22 20:59 ` Eric McDonald
@ 2005-01-04 19:15   ` mskala
  2005-01-04 19:45     ` Eric McDonald
  0 siblings, 1 reply; 8+ messages in thread
From: mskala @ 2005-01-04 19:15 UTC (permalink / raw)
  To: Eric McDonald; +Cc: xconq7, xconq-hackers

On Sun, 19 Dec 2004, Eric McDonald wrote:
> that Ed Felten seems to have fueled your competitiveness; I recognize
> that name from elsewhere; I think he had something to do with the DeCSS
> stuff or maybe a DMCA lawsuit....

He was an expert witness in the Federal Microsoft anti-trust case, and
more recently was attacked by the RIAA after leading the team that
broke the SDMI Challenge files.

> The terrain generator ensures that the all terrain with the 'liquid'
> property set has a uniform elevation with all neighboring liquid terrain.

I think what triggers the bug is elevation=0 rather than liquid terrain as
such, but the way the games are designed means that terrain at elevation 0
normally will be liquid.

> As far as the interfaces calling the kernel every time for an image, I
> am mostly for it, since this keep things more consistent and take most
> of the image-handling burden away from the interfaces. However, if we
> ever evolve Xconq into a client-server model, I might be concerned about
> traffic in the case of a network game. Of course, the image-handling
> part of the "kernel" might be able to be linked into the client apps. I

Well, by "kernel" I just meant the code common to all interfaces - it
could well be part of the client-side library rather than the kernel
kernel that lives on the server.  The point is that we shouldn't have to
make each change to the "decide what image to show" code in more than one
place in the source tree; I think we're on the same page about that.

> My thinking has been:
> (1) Calculate elevation gradients (slopes) from cell edge to cell edge.

That's a bit more complexity than I had in mind - what I was thinking of
was simply code that could automatically generate something similar to the
current designer-specified isometric images.  The way those work is with
one image per terrain type.  That image is of a three-dimensional chunk of
(for instance) mountains, with a hexagonal base but sticking up
vertically, probably outside the hex tile boundaries, to express vertical
height.  When the interface draws it on the screen, it also draws a
pedestal underneath it (isometric view of a hexagonal prism) to represent
the height of the hex, which is the height of the bottom of the relief
shown in the image.

One problem with the current approach is that if the view is rotated, the
designer-specified image can't be rotated because doing so would require
converting the 2D image back to 3D, rotating, and then converting back,
and the relief makes that impossible.  It would be unpleasant, but
theoretically possible, without the relief.  The current scheme of NOT
rotating isometric terrain images when the view rotates actually looks
quite good, but it is visibly a schematic rather than realistic portrayal
of terrain.

What I was imagining for automatic generation would be that the designer
specifies a hexagonal overhead view (they already do), the program renders
that into 3D as a flat hexagon, and then if the designer wants relief,
they specify a height field which is used to add the relief.  There would
be just one image, or one image for each of the six view directions, or
one or six images multiplied by the number of "variant" images, generated
per terrain type - not one per hex.  The objective would be to create
images similar to the ones that designers are currently specifying by
hand.  I had not intended that this feature would be combined with the
satellite-image feature - in theory it could be, I suppose, but that would
be another significant computational load.

> It might also be sufficient to just throw down some splines. As long as

I think that anything which takes into account per-cell elevation
gradients, is best left to the hypothetical future developer of a true-3D
interface.
-- 
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: Image handling: update on my status and plans
  2005-01-04 19:15   ` mskala
@ 2005-01-04 19:45     ` Eric McDonald
  0 siblings, 0 replies; 8+ messages in thread
From: Eric McDonald @ 2005-01-04 19:45 UTC (permalink / raw)
  To: mskala; +Cc: xconq7, xconq-hackers

On Tue, 4 Jan 2005 mskala@ansuz.sooke.bc.ca wrote:

> > that name from elsewhere; I think he had something to do with the DeCSS
> > stuff or maybe a DMCA lawsuit....
> 
> He was an expert witness in the Federal Microsoft anti-trust case, and
> more recently was attacked by the RIAA after leading the team that
> broke the SDMI Challenge files.

Ah, that's right. It was SDMI, not DeCSS.

> > The terrain generator ensures that the all terrain with the 'liquid'
> > property set has a uniform elevation with all neighboring liquid terrain.
> 
> I think what triggers the bug is elevation=0 rather than liquid terrain as
> such, but the way the games are designed means that terrain at elevation 0
> normally will be liquid.

Right. I was saying that 'liquid' acts an elevation leveler. 
Usually, this means leveling the terrain to a height of 0. 
However, if the problem is caused by elevation == 0, then why 
don't I see it on all cells that are part of the same ocean? This 
is what I was getting at.

> kernel that lives on the server.  The point is that we shouldn't have to
> make each change to the "decide what image to show" code in more than one
> place in the source tree; I think we're on the same page about that.

Yes, absolutely.

> one image per terrain type.  That image is of a three-dimensional chunk of
> (for instance) mountains, with a hexagonal base but sticking up
> vertically, probably outside the hex tile boundaries, to express vertical
> height.  

Right.

> What I was imagining for automatic generation would be that the designer
> specifies a hexagonal overhead view (they already do), the program renders
> that into 3D as a flat hexagon, and then if the designer wants relief,
> they specify a height field which is used to add the relief.  

I see.

Eric

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2005-01-04 19:45 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-12-19  7:31 Image handling: update on my status and plans mskala
2004-12-22 20:59 ` Eric McDonald
2005-01-04 19:15   ` mskala
2005-01-04 19:45     ` Eric McDonald
2004-12-23  5:00 ` Isometric Terrain Elijah Meeks
2004-12-23  6:25   ` Eric McDonald
2004-12-24 20:20   ` Stan Shebs
2004-12-25 19:57     ` Elijah Meeks

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