From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 872 invoked by alias); 5 Dec 2004 00:04:08 -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 827 invoked from network); 5 Dec 2004 00:04:03 -0000 Received: from unknown (HELO rwcrmhc13.comcast.net) (204.127.198.39) by sourceware.org with SMTP; 5 Dec 2004 00:04:03 -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 <2004120500040201500n4b1he>; Sun, 5 Dec 2004 00:04:02 +0000 Message-ID: <41B2506D.7070902@phy.cmich.edu> Date: Sun, 05 Dec 2004 02:24: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: Isometric images, sattelite images, and rotation References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004/txt/msg01463.txt.bz2 mskala@ansuz.sooke.bc.ca wrote: > But it gets worse, because the user can choose between six different > 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 and in the file releases, if we go from GIF to PNG, since PNG generally achieves better compression.) While I agree that having a stock of 6 different isometric images, plus an overhead one, might be ideal, I think it places a large space burden on the Xconq project, and another burden on designers of terrain tiles. If we can avoid making this a requirement, I think we would be better off. >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. > If we're going to use satellite imagery, first we have the issue of > rotating the clipped-out hexagons by 30 degrees to make them appear > points-to-the-side, and then we're faced with the issue of rotating them > into six different orientations as the view rotates, because the "North = > 30 degrees counterclockwise of up" assumption only holds in one of the six > orientations. If we have to precalculate all this we multiply the loading > time for these terrain images by seven, not to mention the memory > requirements and API/data structure issues, and I'm already concerned that > the sheer number of terrain images is going to be too much just with > loading top-down satellite imagery. 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 transform an image when its corresponding orientation/projection info does not match the current display orientation/projection. I really have no idea about what sort of CPU impact this would have. This, if feasible, would hopefully address both the storage space and memory usage concerns. > Possibly the easiest thing to do is just disable satellite imagery when in > isometric mode, and demand that the game designer provide some reasonable > default terrain images for use in isometric views. Thoughts? 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). Eric