This is the mail archive of the
xconq7@sources.redhat.com
mailing list for the Xconq project.
Re: Image handling: update on my status and plans
- From: Eric McDonald <mcdonald at phy dot cmich dot edu>
- To: mskala at ansuz dot sooke dot bc dot ca
- Cc: xconq7 at sources dot redhat dot com, xconq-hackers at lists dot sourceforge dot net
- Date: Sun, 19 Dec 2004 00:30:41 -0700
- Subject: Re: Image handling: update on my status and plans
- References: <Pine.LNX.4.53.0412182130480.1577@opal.ansuz.sooke.bc.ca>
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