From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32433 invoked by alias); 27 Oct 2004 17:17:24 -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 32398 invoked from network); 27 Oct 2004 17:17:22 -0000 Received: from unknown (HELO gencom001.gencom.us) (208.45.97.129) by sourceware.org with SMTP; 27 Oct 2004 17:17:22 -0000 Received: from localhost (localhost [127.0.0.1]) by gencom001.gencom.us (Postfix) with ESMTP id 742F87D2F; Wed, 27 Oct 2004 10:17:41 -0700 (PDT) Received: from gencom001.gencom.us ([127.0.0.1]) by localhost (gencom001.gencom.us [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05816-06; Wed, 27 Oct 2004 10:17:22 -0700 (PDT) Received: from [192.168.0.100] (home [67.171.201.213]) by gencom001.gencom.us (Postfix) with ESMTP id 019CB7CD5; Wed, 27 Oct 2004 10:17:21 -0700 (PDT) From: "D. Cooper Stevenson" Reply-To: cstevens@gencom.us Organization: GenCom To: xconq7@sources.redhat.com Subject: Re: GIS Update Date: Wed, 27 Oct 2004 17:25:00 -0000 User-Agent: KMail/1.6.2 Cc: Lincoln Peters References: <200410270401.09702.cstevens@gencom.us> <1098855994.26829.38.camel@localhost> In-Reply-To: <1098855994.26829.38.camel@localhost> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200410271721.59236.cstevens@gencom.us> X-Virus-Scanned: by amavisd-new at gencom001 X-SW-Source: 2004/txt/msg01362.txt.bz2 On Wednesday 27 October 2004 05:46, Lincoln Peters wrote: > > How about that? > > Quite impressive. > Thank you! > Do you think that this data map nicely to the terrain types in an > existing terrain module (plains, forest, desert, mountains, swamp, > shallows, sea), or does this call for a new terrain module to be of any > real interest? If at this point you're just dealing with landcover, I > could create a simplified spin-off of my proposed omniterr.g terrain > module toward that end (no coatings would be needed). Why didn't I think of that?!!? I think you've hit the nail right on the head. It would certainly be ideal to simply have a GIS terrain module that couples seemlessly with the NLCD 92 data. This would deprecate the need for a conversion script. I may be making this sound harder than it is. Again, here's a link to the "Xconqified" GIS landcover map: http://wiki.xconqgis.org/images/grass2xconq/seattle_lowres.jpg Now, compare this with the ASCII GIS text file export linked here: http://wiki.xconqgis.org/map_files/landcover_export.txt The file format is simple. The file reads from top left to lower right; one row per line. Here is the specific landcover specification: http://landcover.usgs.gov/classes.asp When you compare the ASCII export with the map, you can see how they coincide. For example, starting from the top left, there are: 11 squares of Evergreen forest followed by... 1 square of mixed forest 5 squares of Transitional ... I always have to caveat that I've not actually performed a detailed comparison between the map and the ASCII output but my holistic analysis (spot checking and some "tea leaf" reading) tells me that it's accurate. > > Elevation data, of course, is a fairly simple matter to import. > Although as far as I can tell, it only affects the isometric view code > and (sometimes) the fractal percentile terrain generator. > I think you're right. I can see that it will be increasingly important to use elevation as a determinate of such factors such as unit speed, engagement advantage and "who can see whom." This is known. The good news is that I think Xconq's engine can be extended to use elevation in these ways. I may be out in left field here; Eric or others may say, "Xconq already does read elevation." > > What kind of CPU and memory does the process require? It probably > wouldn't be an issue on newer computers (especially those built > specifically for playing games), but somewhere out there, someone is > probably still playing Xconq through an ASCII terminal with the Ncurses > interface, and you can guess how much power that thing would have... I'm with you. The good news is that we can sandwich the Seattle (or any other) GIS based map in Xconq and it would run on curses based terminals because we're staying within the parameters of the Xconq game engine. To put it another way, we're currently just making maps that happen to be accurate within roughly 100 meters :) . The bad news is that if we do real time rendering of the Earth, the "ncurser's" will be kind of out of luck. This is because the rendering process will require GRASS GIS on the system. Now, don't worry, I compiled it in 20 minutes. It's a good thing (tm). There may be a compromise. What would happen if we had a centralized GIS server that 486's could connect to through their If you'll let my imagination run wild for a moment, what would happen if real people (playing paintball? field operations?) had GIS transponders that would be connected to the server via satellite? The GIS unit itself would need simply be a small, single-board Linux computer with an LCD screen and GIS transponder. These units probably use an ncurses interface because bandwidth in the field is at a premium. To put it another way, you don't want to be attacked while waiting for a ton of graphical data. A simple 'X' where the enemy is will do, thank you ;) The long and short of it is that the server would do the heavy lifting while the client simply passes ncurses data sent from the server. Oh, yeah. The server could be a super cluster. Yes, I know how to build them and I think we could do it. Ponder this. > Looks like we might be able to dramatically improve the isometric view > code (at least for some games) without having to make any major changes > to the actual view code! Of course, since I've never messed with the UI > code, I'm guessing there. I hope so! I think that by using GIS data, it should be possible to click on a unit and have a 360 deg. view of what that unit can see. That includes airplanes. I can just see Eric rubbing his temples as his mind calculates what needs to be coded :) -Coop