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

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