From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11976 invoked by alias); 27 Oct 2004 17:25:55 -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 11854 invoked from network); 27 Oct 2004 17:25:51 -0000 Received: from unknown (HELO gencom001.gencom.us) (208.45.97.81) by sourceware.org with SMTP; 27 Oct 2004 17:25:51 -0000 Received: from localhost (localhost [127.0.0.1]) by gencom001.gencom.us (Postfix) with ESMTP id BBE387D38; Wed, 27 Oct 2004 10:26:14 -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-08; Wed, 27 Oct 2004 10:25:55 -0700 (PDT) Received: from [192.168.0.100] (home [67.171.201.213]) by gencom001.gencom.us (Postfix) with ESMTP id 39B6D7D2D; Wed, 27 Oct 2004 10:25:55 -0700 (PDT) From: "D. Cooper Stevenson" Reply-To: cstevens@gencom.us Organization: GenCom To: xconq7@sources.redhat.com Subject: Re: GIS Update Date: Thu, 28 Oct 2004 00:54:00 -0000 User-Agent: KMail/1.6.2 Cc: Lincoln Peters References: <200410270401.09702.cstevens@gencom.us> <1098855994.26829.38.camel@localhost> <200410271721.59236.cstevens@gencom.us> In-Reply-To: <200410271721.59236.cstevens@gencom.us> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200410271730.32774.cstevens@gencom.us> X-Virus-Scanned: by amavisd-new at gencom001 X-SW-Source: 2004/txt/msg01363.txt.bz2 One other thing, complete documentation here: http://wiki.xconqgis.org/index.php?TranslatingToXconq -Coop On Wednesday 27 October 2004 17:21, D. Cooper Stevenson wrote: > 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