From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5029 invoked by alias); 19 Dec 2004 07:31:12 -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 4993 invoked from network); 19 Dec 2004 07:31:02 -0000 Received: from unknown (HELO rwcrmhc11.comcast.net) (204.127.198.39) by sourceware.org with SMTP; 19 Dec 2004 07:31:02 -0000 Received: from [192.168.181.128] (c-67-176-41-158.client.comcast.net[67.176.41.158]) by comcast.net (rwcrmhc13) with ESMTP id <20041219073101015008p7ake>; Sun, 19 Dec 2004 07:31:02 +0000 Message-ID: <41C52E21.8030407@phy.cmich.edu> Date: Wed, 22 Dec 2004 20:59:00 -0000 From: Eric McDonald User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) MIME-Version: 1.0 To: mskala@ansuz.sooke.bc.ca CC: xconq7@sources.redhat.com, xconq-hackers@lists.sourceforge.net Subject: Re: Image handling: update on my status and plans References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004/txt/msg01482.txt.bz2 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