From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2154 invoked by alias); 4 Dec 2004 22:38:13 -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 1702 invoked from network); 4 Dec 2004 22:37:44 -0000 Received: from unknown (HELO gouda.execulink.net) (199.166.6.56) by sourceware.org with SMTP; 4 Dec 2004 22:37:44 -0000 Received: from opal.ansuz.sooke.bc.ca (dsl1637.rba1.pppoe.execulink.com [209.213.252.111]) by gouda.execulink.net (8.11.6/8.11.6) with ESMTP id iB4MbhA15739; Sat, 4 Dec 2004 17:37:43 -0500 Date: Sun, 05 Dec 2004 00:04:00 -0000 From: mskala@ansuz.sooke.bc.ca To: xconq7@sources.redhat.com, xconq-general@lists.sourceforge.net Subject: Isometric images, sattelite images, and rotation Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2004/txt/msg01462.txt.bz2 Okay, imagine this scenario: You have a terrain type. You define an image for it. Just one image; you expect the game to automatically scale it to the right size for whatever magnification the user selects. With me so far? I've been working on code to make that work, and it pretty much does. The one source image for the terrain should be a rectangle a little bit taller than it is wide, preferably at as high resolution as possible, containing a hexagonal area that is the actual terrain image, with corners at the top and bottom and flat sides along the left and right of the image. My code will automatically clip four triangles off the corners to make a hexagon out of the retangular image. This (after a fair bit of debugging) works... as long as the user stays in overhead view. There is an issue I'm still working on in that at the lowest magnification levels, where the hex is reduced to a few pixels, the scaler doesn't seem to be generating data and so things go black if there's no flat colour default defined. Current IMF files do define flat colour defaults, but I'd prefer to be able to generate them automatically. When the user switches to isometric view, then the fun begins. In isometric view, North is no longer vertical - it seems to be 30 degrees clockwise of vertical when you first press "@". That puts the corners of the hexagon at the left and right of the image and flat sides along the top and bottom, so merely scaling the original points-to-top-and-bottom image is not good enough; there has to be a rotation applied as well. 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. The existing games and code (prior to my changes) seem to be faking it by having only one "isometric" image for each resolution, not scaling them, and just hoping the user doesn't notice that the images don't rotate when the view rotates. 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. It does seem to automatically switch among subimages for connection and border terrain, so those will continue to go in the right directions as the view rotates. 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. 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? There is also a masking issue with isometric terrain images because many existing isometric terrain images go outside the hex boundaries in order to create a "relief" effect, e.g. for mountains. That's going to require special handling in the scaler - I think I can probably do it, but haven't yet. -- Matthew Skala mskala@ansuz.sooke.bc.ca Embrace and defend. http://ansuz.sooke.bc.ca/