From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29830 invoked by alias); 19 Dec 2004 03:31:36 -0000 Mailing-List: contact xconq7-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: xconq7-owner@sources.redhat.com Received: (qmail 29806 invoked from network); 19 Dec 2004 03:31:27 -0000 Received: from unknown (HELO gouda.execulink.net) (199.166.6.56) by sourceware.org with SMTP; 19 Dec 2004 03:31:27 -0000 Received: from opal.ansuz.sooke.bc.ca (dsl712.rba1.pppoe.execulink.com [66.203.188.207]) by gouda.execulink.net (8.11.6/8.11.6) with ESMTP id iBJ3VP518002; Sat, 18 Dec 2004 22:31:25 -0500 Date: Sun, 19 Dec 2004 07:31:00 -0000 From: mskala@ansuz.sooke.bc.ca To: xconq7@sources.redhat.com, xconq-hackers@lists.sourceforge.net Subject: Image handling: update on my status and plans Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2004/txt/msg01481.txt.bz2 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/