From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17628 invoked by alias); 23 Nov 2004 19:41:21 -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 17468 invoked from network); 23 Nov 2004 19:41:08 -0000 Received: from unknown (HELO ob2.cmich.edu) (141.209.20.21) by sourceware.org with SMTP; 23 Nov 2004 19:41:08 -0000 Received: from egate1.central.cmich.local ([141.209.15.85]) by ob2.cmich.edu (8.12.10/8.12.10) with ESMTP id iANJWC0n014308; Tue, 23 Nov 2004 14:32:15 -0500 Received: from leon.phy.cmich.edu ([141.209.165.20]) by egate1.central.cmich.local with Microsoft SMTPSVC(5.0.2195.6713); Tue, 23 Nov 2004 14:40:34 -0500 Received: from localhost (localhost [127.0.0.1]) by leon.phy.cmich.edu (Postfix) with ESMTP id 5AB2970012; Tue, 23 Nov 2004 14:40:46 -0500 (EST) Date: Tue, 23 Nov 2004 22:08:00 -0000 From: Eric McDonald To: mskala@ansuz.sooke.bc.ca Cc: xconq7@sources.redhat.com, Subject: Re: Thoughts on terrain imaging In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 23 Nov 2004 19:40:34.0798 (UTC) FILETIME=[4CDAA8E0:01C4D194] X-CanItPRO-Stream: default X-Spam-Score: -0.9 () X-Bayes-Prob: 0.0001 X-Scanned-By: CanIt (www . canit . ca) X-SW-Source: 2004/txt/msg01432.txt.bz2 Hi Matthew, So far, I've had only a brief time to look at your proposal. I will give it a more in-depth glance tonight. Some of the areas you touched on, I have very little knowledge about, because I was content to let Hans deal with them. If you want, I will set up a branch in CVS for you sometime in the next few days or week. You will need to have a Sourceforge user account so that you can be added to the project as a developer. I figure this might be easier than you submitting a bunch of patches which people would have to apply if they wanted to test out your work. A couple of quick responses: On Tue, 23 Nov 2004 mskala@ansuz.sooke.bc.ca wrote: > * 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. For the per-cell case, you may want to implement new layers. I believe that the 'aref' and 'aset' macros in 'world.h', IIRC, would be worth looking at. (Layer allocation is handled elsewhere.) > * 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, Yes. The informal UI API exists primarily in 'ui.h', 'kpublic.h', and 'ui.c'. The more code that can kept within the common API, the better. As I work on the SDL interface, I will probably be moving more code into the common API. Just yesterday, I identified another chunk that is common, but currently distributed amongst the interfaces. The hope is that, eventually, we will have a well-defined, formalized UI API, and will thus be able to attract more UI developers. > http://ansuz.sooke.bc.ca/temporary/maptest.g > http://ansuz.sooke.bc.ca/temporary/override.gif I will look at it tonight. Regarding the bug reports: if you're offering to fix the bugs, then that's great. If you would like some help fixing them, please add them to the project's bug tracking system on Sourceforge, and I will try to help you clear out some of them. As far as GDI memory goes, this is something that Hans has been complaining about for quite some time. From what little reading that I have done, there appears to be an upper limit on the number of GDI handles available (and possibly the amount of GDI object heap available) in Win32. It varies from version to version. So, this is strictly a Win32 consideration, and it may only be applicable to the Tcl/Tk interface, because Tk does a lot of things behind ones back. I think that we have more control of our situation in SDL. And, of course, Curses is irrelevant in this regard. Thanks, Eric