From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23051 invoked by alias); 23 Nov 2004 06:27:43 -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 22922 invoked from network); 23 Nov 2004 06:27:27 -0000 Received: from unknown (HELO urk.execulink.net) (199.166.6.45) by sourceware.org with SMTP; 23 Nov 2004 06:27:27 -0000 Received: from diamond.ansuz.sooke.bc.ca (ppp5.ac3.56k.execulink.com [209.239.3.5]) by urk.execulink.net (8.11.6/8.11.6) with ESMTP id iAN6RNR29849 for ; Tue, 23 Nov 2004 01:27:24 -0500 Received: from localhost (mskala@localhost) by diamond.ansuz.sooke.bc.ca (8.10.2/8.10.2) with ESMTP id iAN6LVx04607 for ; Tue, 23 Nov 2004 01:21:32 -0500 Date: Tue, 23 Nov 2004 16:44:00 -0000 From: mskala@ansuz.sooke.bc.ca To: xconq7@sources.redhat.com Subject: Thoughts on terrain imaging Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="50987268-371161834-1101190891=:3911" X-SW-Source: 2004/txt/msg01430.txt.bz2 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --50987268-371161834-1101190891=:3911 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-length: 8251 I started taking a look at how to implement the idea I was describing back in September, of taking a chunk of an image file and displaying it to replace other terrain images. Once I started digging around in the code, I found what I think is probably the best way to do it, which runs as follows: * Extend the current "subimages" concept in the image-family system. You can already specify special types of images, namely "tile", "border", "connection", and "transition", and you can specify (for regular images, which could be cell terrain or units) multiple "subimages". I propose to add a new special type of image called "hexgrid". When you specify a "hexgrid" image, you specify a subrectangle of an image as you normally do with other images, and you also specify a number of rows and columns (of hexagonal cells). Hexagonal chunks are automatically clipped out of the source image starting from your specified coordinates, to make up a number of "subimages" for the image family. * Add data structures to the map to store, for each cell and cell terrain type, pointers to image families and subimage numbers for "override" images. * Change interfaces so that when they go looking for a cell terrain image for a given cell, if there is an applicable override image at that cell, they use it instead. I'm hoping to keep the amount of per-interface code for this as small as possible; that should be reasonably easy to do, because it's mostly just a matter of extending the call interfaces make to say "Hey, what's the image for this terrain type?" to be "Hey, what's the image for this terrain type *at these cell coordinates*?" * Add appropriate forms to GDL to allow setting the override information. I decided to try implementing these ideas, but I wanted to do it in such a way that I could test each step and see that it was working before moving on to the next one, so as a very first step, I wrote a simple game module which would trigger the "subimage" code, figuring that next I could move on to making it clip out the subimages in a hex grid instead of the existing one-dimensional linear offset. The results are at these URLs: http://ansuz.sooke.bc.ca/temporary/maptest.g http://ansuz.sooke.bc.ca/temporary/override.gif Those are supposed to work with the existing code base; the "forest" cells on the map are supposed to be filled with a random mixture of five different hexagonal chunks taken out of override.gif (which, you will note, contains a chunk of the existing map with the colours modified and some minor edits so that I'll be able to see when it's correctly spliced in). In testing that, I discovered a bunch of issues with existing code, with my test files (I haven't touched the code to actually modify it yet at all), or issues that will come up soon: * It doesn't work in the TCL interface except on the highest magnification. At other magnifications, the affected cells are just black. As far as I can tell, for some reason the automatic scale-down code isn't running. Isn't it supposed to? I thought the idea was you could specify just one resolution of an image and any others would be automatically generated if necessary; that certainly works for units, but at least in this case it doesn't seem to work for terrain. * It doesn't seem to work in the SDL interface at all - I get a segfault, see attached backtrace. I haven't tested this extensively at all, so it's possible it may be unrelated, but the same build of the SDL interface seems at least sort of stable with other modules, so I suspect it's something to do with the same issue as in the TCL interface - I didn't specify more than one resolution for the terrain images, and there are issues with generating the other sizes automatically. This could be a problem because someone who's doing this clip-and-insert thing will only naturally have one resolution for the image, and it seems like a bad thing to force the designer to provide multiple sizes of the same image from outside the game; the resize code really should work. * It seems like a shame that images can only have 256 colours, and this'll be a bigger issue when we have image chunks of serious size, where all the hexes in the chunk have to share the same palette. Ideally I think this would be fixed by making XConq capable of loading PNGs, but it looks like there are 8-bit assumptions built into a lot of code, and at this point I don't want to try to change them when that's not my main goal. * It seems like maybe (I'm not quite clear on this) when there are a bunch of subimages in an image, the GIF file is being re-read for each one. That could already be a performance issue for border/connection terrain; but with satellite images there could be hundreds, or thousands, of subimages from the same image, and it would really suck to have to spend the time to load the GIF a thousand times over. Better to cache it somehow; but maybe that's already being done, since border/connection terrain *doesn't* seem to create a huge loading-time problem, and is already loading 63 subimages per terrain type. * There is simply a lot of data involved in covering a whole map with custom images. There's not really any way around that. I think it could be a problem because there are some warnings I don't understand in the code (imf.c lines 88-90 and uses of the flag defined there) about some Windows interfaces having limits on "GDI memory", and there are measures taken to cut features to save on the amount of imagery loaded. For instance, if the flag that says "we have to conserve GDI memory" is set, then when you specify a lot of alternate images (like in my example file, which specifies five) only the first three are used. Well, with a patch of satellite data you pretty much have to load all the subimages - but if there are hundreds of them, and you can't afford to load a lot of images in general, that's going to be a problem. I don't think there's really much way to avoid this, short of simply disabling the image-override mechanism entirely when the "must not load too many images" flag is set. No matter what scheme we use, those images have to be loaded if we're going to use them. Maybe someone who knows more about Windows and what that flag is actually for could shed some light on this issue. * Minor thing, but something I'll include in my patch for sure: the (x n x y) property for image families doesn't seem to permit negative x/y values, and I think you'd be likely to want to use those far more often than you'd want to define both of them to be non-zero, which is behaviour it does permit. Easy to change, just by changing ">0" to "!=0". I'm also not convinced that this parameter is really 100% correctly implemented in general, but that's not really my problem and it obviously does at least sort of work because the terrain in the existing "advanced" game uses it. I became interested in this bit of code because it's closely related to the code I want to add for hex-grid clipping. * If I clip chunks out of an image on a hexagonal grid, what I will get will be overlapping rectangular images (88x96 or similar) without the hex masks that I think the current system might produce. I'm not sure how interfaces use images or whether that's likely to be a problem; I suspect it isn't a problem because of the success of my test files with the current code, but if it turns out to be, then I guess I'll have to write some code to generate a hexagonal clipping mask for the images. The issue is that the interface asks for an image for terrain for a given cell, the imf code hands back an image, but that is a rectangle that covers the bounding rectangle of the cell and includes pixels outside the bounds of the cell, because there's not a hex mask to clip it to the cell... Will the interface do the clipping? Or do I have to generate a mask to go with the image? I guess I'll find that out by experiment later. It seems like something that the interface probably already has to do anyway, so it's probably not a problem I need to solve; and if I did need to solve it, I could, so it's no biggie. -- Matthew Skala mskala@ansuz.sooke.bc.ca Embrace and defend. http://ansuz.sooke.bc.ca/ --50987268-371161834-1101190891=:3911 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=backtrace Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=backtrace Content-length: 3994 bXNrYWxhQG9wYWw6fi94Y21hcCQgZ2RiIC91c3IvbG9jYWwvc3JjL3hjb25x LWxhdGVzdC94Y29ucS9zZGwveGNvbnENCkdOVSBnZGIgNS4zDQpDb3B5cmln aHQgMjAwMiBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24sIEluYy4NCkdEQiBp cyBmcmVlIHNvZnR3YXJlLCBjb3ZlcmVkIGJ5IHRoZSBHTlUgR2VuZXJhbCBQ dWJsaWMgTGljZW5zZSwgYW5kIHlvdSBhcmUNCndlbGNvbWUgdG8gY2hhbmdl IGl0IGFuZC9vciBkaXN0cmlidXRlIGNvcGllcyBvZiBpdCB1bmRlciBjZXJ0 YWluIGNvbmRpdGlvbnMuDQpUeXBlICJzaG93IGNvcHlpbmciIHRvIHNlZSB0 aGUgY29uZGl0aW9ucy4NClRoZXJlIGlzIGFic29sdXRlbHkgbm8gd2FycmFu dHkgZm9yIEdEQi4gIFR5cGUgInNob3cgd2FycmFudHkiIGZvciBkZXRhaWxz Lg0KVGhpcyBHREIgd2FzIGNvbmZpZ3VyZWQgYXMgImkzODYtc2xhY2t3YXJl LWxpbnV4Ii4uLg0KKGdkYikgcnVuIC1nIG1hcHRlc3QuZw0KU3RhcnRpbmcg cHJvZ3JhbTogL3Vzci9sb2NhbC9zcmMveGNvbnEtbGF0ZXN0L3hjb25xL3Nk bC94Y29ucSAtZyBtYXB0ZXN0LmcNCltOZXcgVGhyZWFkIDE2Mzg0IChMV1Ag MjgwMTcpXQ0KDQogICAgICAgICAgICAgIFdlbGNvbWUgdG8gWDExIFhjb25x IHZlcnNpb24gNy41cHJlIChOb3ZlbWJlciAyMDA0KQ0KDQpYY29ucSBpcyBm cmVlIHNvZnR3YXJlIGFuZCB5b3UgYXJlIHdlbGNvbWUgdG8gZGlzdHJpYnV0 ZSBjb3BpZXMgb2YgaXQNCnVuZGVyIGNlcnRhaW4gY29uZGl0aW9uczsgdHlw ZSAibyBjb3B5aW5nIiB0byBzZWUgdGhlIGNvbmRpdGlvbnMuDQpUaGVyZSBp cyBhYnNvbHV0ZWx5IG5vIHdhcnJhbnR5IGZvciBYY29ucTsgdHlwZSAibyB3 YXJyYW50eSIgZm9yIGRldGFpbHMuDQpXYXJuaW5nOiBtYXB0ZXN0Lmc6MjMw OiBDYW4ndCBzZXQgdW5rbm93biBnbG9iYWwgbmFtZWQgYGJpZ2ljb25zJy4N Ck1ha2luZyBjb3VudHJpZXM7IGRvbmUuDQpHcm93aW5nIGNvdW50cmllczsg ZG9uZS4NCkFzc2lnbmluZyBwbGF5ZXJzIHRvIHNpZGVzOyBkb25lLg0KU2V0 dGluZyB1cCBBSXM7IGRvbmUuDQoNClByb2dyYW0gcmVjZWl2ZWQgc2lnbmFs IFNJR1NFR1YsIFNlZ21lbnRhdGlvbiBmYXVsdC4NCltTd2l0Y2hpbmcgdG8g VGhyZWFkIDE2Mzg0IChMV1AgMjgwMTcpXQ0KMHgwODE1NzcxZiBpbiBibGFj a2VuX21hc2tlZF9hcmVhKGFfaW1hZ2VfZmFtaWx5KiwgYV9pbWFnZSosIGlu dCwgaW50LCBpbnQpICgNCiAgICBpbWY9MHg4MjVhOWYwLCBpbWc9MHg4NDZm YjUwLCByZD02NTUzNSwgZz0wLCBiPTY1NTM1KSBhdCBpbWYuYzoxMjMzDQox MjMzICAgICAgICAgICAgaW1nLT5yYXdwYWxldHRlWzQgKiBibGFjayArIDBd ID0gYmxhY2s7DQooZ2RiKSBidA0KIzAgIDB4MDgxNTc3MWYgaW4gYmxhY2tl bl9tYXNrZWRfYXJlYShhX2ltYWdlX2ZhbWlseSosIGFfaW1hZ2UqLCBpbnQs IGludCwgaW50KQ0KICAgIChpbWY9MHg4MjVhOWYwLCBpbWc9MHg4NDZmYjUw LCByZD02NTUzNSwgZz0wLCBiPTY1NTM1KSBhdCBpbWYuYzoxMjMzDQojMSAg MHgwODA1ZTNiZSBpbiBzZGxfY29weV9jb2xvcl9pbWFnZSAoaW1mPTB4MCwg aW1nPTB4ODQ2ZmI1MCwNCiAgICBzdXJmYWNlPTB4ODQ3MzI0OCkgYXQgc2Rs aW1mLmNjOjEyNQ0KIzIgIDB4MDgwNWUxMzMgaW4gc2RsX2ludGVycF9pbWFn ZV8xIChpbWY9MHg4MjVhOWYwLCBpbWc9MHg4NDZmYjUwLA0KICAgIHN1Ymlt Zz0weDg0NmZiNTAsIHN1Ymk9MCwgZm9yY2U9MCkgYXQgc2RsaW1mLmNjOjEw Nw0KIzMgIDB4MDgwNWRmNzcgaW4gc2RsX2ludGVycF9pbWFnZSAoaW1mPTB4 ODI1YTlmMCwgaW1nPTB4ODQ2ZmI1MCwgZm9yY2U9MCkNCiAgICBhdCBzZGxp bWYuY2M6NTgNCiM0ICAweDA4MDVkZWFjIGluIHNkbF9pbnRlcnBfaW1mKGFf aW1hZ2VfZmFtaWx5KiwgYV9pbWFnZSosIGludCkgKA0KICAgIGltZj0weDgy NWE5ZjAsIGltZz0weDg0NmZiNTAsIGZvcmNlPTApIGF0IHNkbGltZi5jYzo0 MA0KIzUgIDB4MDgxNTY4MjEgaW4gYWRkX3NocnVua2VuX2ltYWdlIChpbWY9 MHg4MjVhOWYwKSBhdCBpbWYuYzo4NjMNCiM2ICAweDA4MTU3MTc2IGluIGJl c3RfaW1hZ2UoYV9pbWFnZV9mYW1pbHkqLCBpbnQsIGludCkgKGltZj0weDgy NWE5ZjAsIHc9MCwNCiAgICBoPTEpIGF0IGltZi5jOjEwMzcNCiM3ICAweDA4 MDRmNjE2IGluIGluaXRfdGVycmFpbl9pbWFnZXMgKCkgYXQgc2RsaW5pdC5j YzoxNzkNCiM4ICAweDA4MDRmMzJkIGluIGluaXRfZGlzcGxheSgpICgpIGF0 IHNkbGluaXQuY2M6NzcNCiM5ICAweDA4MDRlMGM1IGluIGluaXRfYWxsX2Rp c3BsYXlzICgpIGF0IHNkbG1haW4uY2M6MjI5Ng0KIzEwIDB4MDgwNGVmOGMg aW4gbGF1bmNoX2dhbWUoKSAoKSBhdCBzZGxtYWluLmNjOjI4NTQNCiMxMSAw eDA4MDQ5ZmQ3IGluIG1haW4gKGFyZ2M9MTM2NzMyODI0LCBhcmd2PTB4MSkg YXQgc2RsdW5peC5jYzoxMTUNCiMxMiAweDQwNDE0YmI0IGluIF9fbGliY19z dGFydF9tYWluICgpIGZyb20gL2xpYi9saWJjLnNvLjYNCihnZGIpIGxpc3QN CjExNSAgICAgICAgICAgICAgICAgICAgIGxhdW5jaF9nYW1lKCk7DQoxMTYg ICAgICAgICAgICAgfQ0KMTE3ICAgICAgICAgICAgIGlmICghb3B0aW9uX3Bv cHVwX25ld19nYW1lX2RpYWxvZykNCjExOCAgICAgICAgICAgICAgICAgcHJp bnRfaW5zdHJ1Y3Rpb25zKCk7DQoxMTkgICAgICAgICAgICAgLyogQXQgdGhp cyBwb2ludCB3ZSBrbm93IHdlIGNhbiB1c2UgcG9wdXBzIGluc3RlYWQgb2Yg c3RkaW8gZm9yDQoxMjAgICAgICAgICAgICAgd2FybmluZ3MgYW5kIG1lc3Nh Z2VzIGFuZCBzdWNoLiAqLw0KMTIxICAgICAgICAgICAgIHVzZV9zdGRpbyA9 IEZBTFNFOw0KMTIyICAgICAgICAgICAgIC8qIEdvIGludG8gdGhlIG1haW4g cGxheSBsb29wLiAqLw0KMTIzICAgICAgICAgICAgIHVpX21haW5sb29wKCk7 DQoxMjQNCihnZGIpIHF1aXQNCg== --50987268-371161834-1101190891=:3911--