From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3696 invoked by alias); 5 Dec 2004 04:59:10 -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 3619 invoked from network); 5 Dec 2004 04:59:05 -0000 Received: from unknown (HELO edam.execulink.net) (199.166.6.57) by sourceware.org with SMTP; 5 Dec 2004 04:59:05 -0000 Received: from opal.ansuz.sooke.bc.ca (dsl1635.rba1.pppoe.execulink.com [209.213.252.109]) by edam.execulink.net (8.11.6/8.11.6) with ESMTP id iB54x2c25919; Sat, 4 Dec 2004 23:59:02 -0500 Date: Sun, 05 Dec 2004 10:27:00 -0000 From: mskala@ansuz.sooke.bc.ca To: Eric McDonald cc: xconq7@sources.redhat.com, xconq-hackers@lists.sourceforge.net Subject: Re: Isometric images, satellite images, and rotation In-Reply-To: <41B2506D.7070902@phy.cmich.edu> Message-ID: References: <41B2506D.7070902@phy.cmich.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2004/txt/msg01465.txt.bz2 On Sat, 4 Dec 2004, Eric McDonald wrote: > > angles for the isometric view. To get it really right we need six > > different images. > > Unfortunately our CVS repo is already burdened with lots of images. I > would be loathe to increase checkout or update times any more than > absolutely necessary. (We can probably win back much space in the repo I hadn't even thought of the idea of six *designer-specified* images; I agree that would be unworkable. The goal I've had in mind throughout here has been for the system to be able to generate all it needs from *one* high-resolution overhead image, because that's what it'll have to do with satellite data. What I was imagining as "the really right thing" was generating six isometric views from the one overhead designer-specified image. That's plenty bad enough because of the memory and initial loading time issues. The way the system is currently designed it has to load or generate, and then store, all the scaled images for all the magnifications, in isometric and overhead, i.e. 7*2=14 images per cell terrain type. (Probably some of those can be eliminated in the case of the lowest magnifications where isometric doesn't make a difference to the shape.) In the case of a patch of satellite data where there is in effect a new terrain type per cell, that could easily run to thousands of images. Going from 2 to 7 (overhead and one isometric to overhead and six isometric) seems like it would be bad. Memory-wise it's probably still only a few megs, but since all the scaling is done during loading, and the rotation is going to take more time, it's going to get annoying really fast. I think maybe we could do it with only three tricky 3D rotations for three of the views, and then just turn those 180 degrees in 2D to generate the other three views, but it's still not something I'd look forward to coding and debugging. > If we can avoid making this a requirement, I think we would be better off. For sure, there's no way the designers can be expected to produce that. I want to avoid even auto-generating so many images, at least during game load. > >That works because the existing > > terrain images don't really have much direction - they're basically > > textures and look the same whether North is the right place or not. > > The Civ2 terrain images do have some direction-specific detail. It appears that there aren't isometric versions of the Civ2 images, and it goes to flat colours with both my code and the previous code. Come to think of it, I don't think I remember seeing isometric versions of much terrain at all. Looking through the images directory, it seems we only have road48x33i.gif, stdt13x9i.gif, and stdt48x33i.gif; that's it. This makes me think that maybe it's not so very bad for satellite terrain to go to flat colors in isometric; most other terrain does the same thing at the moment, and we haven't had many complaints about that. It's possible to argue that in isometric mode, the units are packed closer together and you have terrain relief visible and so there's a whole lot of information to take in already, and terrain images would get in the way of that... in other words (the claim could be made) defaulting to flat colours in isometric is actually a feature. you want to be able to clearly see issues like terrain relief, and the units are packed closer together, so you actually *want* less of the flash and glitter of image terrain. From that point of view, defaulting to flat colours in isometric mode could be claimed to be a feature instead of a bug.... > I share your concern with keeping too many images in memory. As I > mentioned to you when closing out your latest patch, we may want to > consider some sort of caching system and on-demand transforms. Only Very many things in XConq seem to be designed for lazy calculation - don't calculate until used the first time, then calculate once and keep forever. However, even though the imf routines are designed for putting off work until first demand, the Tcl/Tk and SDL interfaces break it by pre-requesting all the image sizes they'll ever use, during their initialization routines. Also, even if we didn't break it, lazy calculation helps with the initial CPU requirement but not with the overall memory requirement. > I think that this may be wise in the shorter term. However, in the > longer term, I would rather get it "right", so that the end-user can > have a seamless experience without feeling like an isometric view is > inferior (in spite of the fact that it shows relief). How would you feel about declaring it to be at least partly the interface's problem? It seems like issues like image rotation by other than 90 degrees are the sorts of issues that interfaces can deal with better than the central code can. Interfaces will usually have access to interface- or platform-specific graphics libraries. In the case of a 3D accelerated interface (which nobody's working on, but I find it easy to imagine that someone might) the interface would also have access to *hardware* for doing this kind of thing, that the kernel couldn't reasonably access, nor compete with as to speed. The "really right" solution sounds like it would need several major elements: * Extensions to data structures and images so that instead of just asking for "this image at that size" you ask for "this image, that size, such-and-such view type, so-and-so view angle". Note that to *really* be right it shouldn't even be limited to overhead and isometric. Note that to really be right, unit images should probably change for view angles and overhead/isometric as well, which opens the door to worrying about unit facing. * Extension to imf code to automatically calculate any needed size/type/angle combinations, preferably with the designer given as much freedom as possible to specify just one input image or a very small number of them. * Upgrade 32-bit colour (three channels plus alpha) throughout the data structures and imf code; because the overhead-to-isometric projection transform is going to be pretty tricky in 8-bit colour, and would have to be thrown out and rewritten anyway at such time as we did go to full colour, so it makes more sense to do that first. * Some kind of image cache to store calculated images, without soaking up too much memory, but keeping enough of them that we aren't constantly recalculating. * Per-interface changes to use all this. I think I'd be happier with telling the interface "You can request image data at whatever size, in a plain overhead view; if you want to show the user something three-dimensional, you're responsible for projecting it". Now that we have isometric it seems like a bad thing to *remove* it, but I don't know that it's a high priority to do a lot of work in the kernel to support extra features in isometric right now. At this point I think I'd like to try and fix that yellow-pixels issue and then see if I can get the satellite image thing to work in overhead, letting it go to default images (non-satellite, tile, or flat colour depending on what the designer has specified) when in isometric. -- Matthew Skala mskala@ansuz.sooke.bc.ca Embrace and defend. http://ansuz.sooke.bc.ca/