FG Index -|- ATLAS Index -|- End
Atlas Build and Running, using Microsoft Visual C/C++ .NET 2003 (MSVC7)
A. Building - Configuration, Compile, and Link - also see update below
21-29 January, 2005 - Change to folder FGCVS\Atlas, set CVSROOT=C:\FGCVS, cvs -up -dP, updates the Atlas directory, with the latest CVS source ... note a number of file changes ...
I do my build in other than the 'CVS' download folder... more that I now have the HDD space
;=)) ... my current local is FG099, so change into there, and do - xcopy /E c:\FGCVS\Atlas\*.*
. -, and a full copy results ... load the Atlas.sln, into MSVC7 ... Ok, to convert ... and
'Build Solution' ... get lots of 'missing' files ... ok, check the 'Properties' of each
project, on the C/C++, General tag ... no 'Additional Include Directories' ... we soon fix
that, and due to my personal folder structure, used for the FlightGear, and 'dependent'
sources, I end up with, including 'png.h', mentioned below -
However, I run into an error, that I have seen before, using MSVC7. It has 'tightened' up the
'exit' prototype - why I do not know ;=(( - and this brings to light, this error -
c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\stdlib.h(256) : error C2381: 'exit' : redefinition; __declspec(noreturn) differs
c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\PlatformSDK\Include\gl\glut.h(147) : see declaration of 'exit'
There is a 'fix' I had used earlier, under a 'FGFS' define, so I add this as a 'Preprocessor' define ... six (6) times ... in Debug and Release, for each of 'Altas', 'Map', and 'MapPS' ... should look for a 'shortcut' to do this once, and apply it to ALL projects in the 'solution', in each 'configuration' ... but later, found a 'better' patch for glut.h ... just update it to 'mirror' the new definition given in stdlib.h ... and all is well ... simple ...
This source uses libpng, which in turn, requires zlib 1.0.4 or later (1.2.2 or 1.1.4 - I use this latter, download, and built with SimGear), and although I have previously used an fltk-png library, I choose to look at a fresh download ... and placed it in folder FG099\png\lpng128 ...
While it seems, MSVC7 has solved 'some' of the problems about 'mixed' runtime libraries ... in certain cases, it simply put out a warning, but 'solves' the problems, and completes the link of the binary executable ... but SOMETIMES it emits an 'error', or 'errors' ... go figure ... Anyway, as repeated often, it is 'better' if you get 'familiar' with the 'Property Pages', 'Configuration Properties', the C/C++ pseudo-folder, the 'Code Generation' tag, the 'Runtime Library' ;=((
As stated in several places, I have decided on using 'Multi-threaded (/MT)' for Release configuration, and 'Multi-threaded Debug (/MTd)' for Debug, throughout. There are several reasons for this, not least of which, is that, one day perhaps, I think of 'adding' threads ... there is a CygWin implementation of the *nix 'thread' functions ... but, I mean a 'more' native implementation ... the only 'cost' of such a choice, is perhaps some 'thread-safe' services involve a little more code, but otherwise, it should have no effect ...
I definitely do NOT choose the various DLL choices! Any, and every 'static' library, can usually be alternatively built as a 'dynamic link library' - DLL, but this has quite a number of drawbacks, with very little gain, if any ;=(( ... it 'complicates' any distribution, and, in fact, more or less, 'forces' the use of a 'windows installer' ... or a read-me, or documents, 'detailing' to users, where all the 'components' need to be placed, in an 'infinitely' variable user definable environment - an almost 'impossible' task ... no, it is simply 'better' that the 'library' code be carried, and loaded, in the single binary executable file ... simple, and neat ...
Sometimes, the compiler/linker, can throw up 'lots' of 'errors' and 'warnings', some of which
seem 'all nonsense'! A recent 'build' of Atlas showed the following final line(s) -
atlas - 69 error(s), 57 warning(s) - 69 ERRORS???
Yuck! What did I do 'wrong'? This is only a sample of the first error -
msvcprtd.lib(MSVCP71D.dll) : error LNK2005: "public: class std::basic_ostream<char,struct std::char_traits<char> > & __thiscall std::basic_ostream<char,struct std::char_traits<char> >::operator<<(class std::basic_ostream<char,struct std::char_traits<char> > & (__cdecl*)(class std::basic_ostream<char,struct std::char_traits<char> > &))" (??6?$basic_ostream@DU?$char_traits@D@std@@@std@@QAEAAV01@P6AAAV01@AAV01@@Z@Z) already defined in SimGear.lib(sg_serial.obj)
Very difficult to 'read', and almost 'impossible' to understand... the full list is here ... but it is not 'worth' the reading effort ;=))
And ALL those 'errors', and 'warnings', were simply due, to the fact that, the Atlas Properties
Pages, under the C/C++ pseudo C/C++ folder, in the 'Code Generation' tag, 'Runtime Library',
was set to 'Multi-threaded Debug DLL (/MDd)', when it should be set to 'Multi-threaded Debug
(/MTd)' to suit my over-all runtime library choice ... a seemingly 'subtle' difference ... but
setting it to my 'choice', namely 'Multi-threaded Debug (/MTd)', re-compiling them all,
produces exactly what we want ... no errors ...
atlas - 0 error(s), 12 warning(s) - ignoring the 'warnings' ...
A second update, 29 January 2005, coincides with a FG development board notice, of a 'release candidate' of Atlas, is. added below ... and the MSVC7 build files ... and some WIN32 exe's ...
B. Running - Order, Configuration, and Output
Before you 'run' Atlas, connected, via 'sockets', udp, to a running FlightGear, you must run Map, to 'generate' the Map Tiles, to match your scenery ... It has a 'global' input command, and it will search a given 'scenery folder', for ALL TerraGear 'btg' files, collect them into a display context, then convert that display to a png output file, using 1x1 degree names, like that for Sydney International airport, and some surrounding scenery, of e151s32.png ...
Since my fg-root/scenery/terrain folder contains the following 10x10 'chunks' - e140s40, e150s30, e150s40 - as well as the San Francisco default scenery chunk of w130n30, running 'Map', in 'global' mode, produces some 150 plus files, 4MB, giving an 'average' size of about 25K each ... this size probably depends on the 'complexity' of the 'scenery' ...the largest seems about 100K, the smallest just 800 bytes ... and, be very patient ... it takes quite a few minutes, plus, to complete its task ...
So in the Map Property Pages, Configuration Properties, Debugging tag, I add the following
'Command Arguments' -
I place a debug trap (break point) in main(), and in the redrawMap() GL (glut) callback, to watch what happens ... I note, that an earlier 'wish-list' item has been implemented in this 'later' cvs source, and that is the inclusion of fg_mkdir.cxx, to create the 'Atlas' output directory ... you HAD to do this manually, in the previous version ... well done - good change ...
I remove my 'checking' break points, except at the exit() point ... and let it run ... if you get the 'focus' right, you can 'view' each 'map tile', as it is formed ... because the re-paint of the GL 256x256 window only happens infrequently ... only after a load of all the scenery of a particular 'area', ... it can 'appear' the glut windows has 'failed' ... but be patient ...
The re-paint occurs just after the console output, like -
Note the 'mixture' of *nix path separator of '/', and the windows 'native' path separator of '\', combined ... thankfully, in many file functions 'either' are allowed ... this almost means we could 'standardise', in a cross-platform projects, like FlightGear/Atlas, using the *nix '/' form ... also thankfully, fg_mkdir.cxx also 'does-not-care' what it is 'passed', and uses '/' internally ...
It takes a 'while' to reconcile the fact that the GL window shows the 'center' lat/lon, while it writes a 'Map Tile Title', using the top, right lat/lon ... but is perhaps 'understandable' ... Atlas places the 'plane' in the 'center' ... it is great, watching this great southern island/continent, Australia, being, at least partially, 'mapped' out ... all from FlightGear/TerraGear BGL vector information, which came from SRM/DEM data ... being sort of 'zipped up' into PNG packets ...
A little 'surprised' at the exit(), when a debug assert fails, showing the source -
* If this ASSERT fails, a bad pointer has been passed in. It may be
* totally bogus, or it may have been allocated from another heap.
* The pointer MUST come from the 'local' heap.
It is even MORE interesting when I discover it is in ~MapMaker(), on a line MSVC6 'refused' to
compile, namely -
With MSVC6 I tried a few variations ... none worked, in MSVC6 ... and the 'nagging' doubt that deleting 'first' does not seem 'right' ... in a push_back, your pointer, if you are storing pointers, is in 'second', isn't it? ... now MSVC7 lets the code through, but the debug heap manager reports that the application is deleting something 'assigned' from 'another' heap ... that one of the 'debug' functions ... 'new' allocates from dbg_new (or new_dbg?), while internal, allocations are from the 'real' new, so some debug-only HEAP code can 'know' who 'allocated' it, by its 'range' ... if you see what I mean ... this certainly seems an occasion when MSVC6 'typing' of code, does a 'better' job than the latest, version 7 compiler ;=()
Above I said 'minutes', but with my initial debug points, tracing through some code here and there, it has been over an hour ... to out the 154 file set ... but they are quite 'bare', but beautiful ... I decide to add --enable-airports --enable-navaids to the command line, and run the Release version, to see how 'short' the time can be ... of course, I am quickly reminded that I had only been 'fixing-to-suit-my-personal-folder-layout' in the Debug configuration ... I must do a little cut, paste, fix ...
First, here is the configuration: Debug, Linker, Input 'Additional Dependencies: line...
ws2_32.lib is a DLL ... the other are 'static' WIN32 COFF 'library' or 'archive' files -
ws2_32.lib pui_d.lib ul_d.lib fnt_d.lib net_d.lib sg_d.lib ssg_d.lib ssgAux_d.lib SimGear.lib libpngd.lib zlib.lib
Here is the configuration: Release -
ws2_32.lib pui.lib ul.lib fnt.lib net.lib sg.lib ssg.lib ssgAux.lib SimGear.lib libpng.lib zlib.lib
You should note the two (2) different 'technologies' for separating the 'debug' from the
'release' code -
1. modify-name - For example, the Debug PLIB files have a '_d' added, png adds a 'd' ... this has the 'advantage' that they can reside in the same folder, PLIB has a post-event to copy the 'results' to a 'common folder, a nice touch ... and
2. modify-folder - For example, simgear and zlib keep the same name, and the MSVS/IDE does the 'separation' by putting them in their own folder ... the Linker, General tag, 'Additional Library Directories' input resolves the 'difference' ... this is my Debug -
and this is the Release -
The 'default' folder names, used by MSVS/IDE, are 'Debug' and 'Release', provide the 'project' is in its own folder ... you can see the png library has hedged its bet BOTH ways ;=)) Not only do they do they use the 'modify-name' technology, but also employ a quite complex 'modify-folder' system ...
Which 'technology' do I 'prefer'? No, either is ok. The PLIB approach is the most 'convenient', since it means only one path has to be entered 'correctly', and is copy/paste-able', like '..\..\PLIB', but this takes a lot more 'setup', with post-event actions added ... and if all the PLIB 'static' libraries were collected into ONE plib.lib, like SimGear does, then we would have the best of both worlds ...
Of course, I add in the command line ... and I remember to use Ctrl+F5 (run without debug), to avoid a 'warning' dialogue that 'tells-you-what-you-already-know' ... ;=(( That was a 'tad' faster ... 154 files in 5 minutes ;=)) ... to process 4 10x10 chunks ... assuming that Map has a 'similar' rendering engine as FlightGear, this would sort of set the 'fastest' that one could fly such a distance, and have the 'Tile Manager' keep up with the loading/rendering task ...
The new-to-XP 'tile' view make a nice collage of Map tiles, even at this 'low' resolution -
Sydney, e151s34.png, is highlighted ... but look at the country, coastline ... all great ... the last two are from the default scenery, thus you can see they contain a bit more 'writing' ... thank you for this tool ... it give me a great 'view' of the 'fabric' of the planet ... I still have to 'experiment' with the 'size' and 'scale' options, let alone 'palette', 'smooth-color', etc ... lot of options to try ;=))
The running of the Atlas tool, together with FlightGear, is talked about back here, in At 2
FG Index -|- ATLAS Index -|- Top -|- End
Update: Sunday, 30 January 2005.
RE: Atlas Release Candidate [http://atlas.sourceforge.net/]
In response to the following board message -
Date: Fri, 28 Jan 2005 13:16:28 +0000
From: "David Luff" David .dot. Luff .at. nottingham .dot. ac .dot. uk
Subject: [Flightgear-devel] Atlas release candidate
I've put a release candidate of Atlas-0.3 up at:
If a few folk could take the time to download this and try it out that
would be great.
Just to confirm I have built, and run Map and Atlas using MSVC .NET 2003 (MSVC7) ... all runs fine, and the following do not really effect the release ... I did not try all 'options', but all that I tried, worked, as expected ...
Regarding the WIN32, non-cygwin, MSVC7 build ...
The download of the Atlas-0.3.0-rc1.tar.gz places a file Atlas-0.3.0-rc1.tar.tar on my disk ...
this makes my WinZip
'cough', until I rename it to Atlas-0.3.0-rc1.tar.gz ... why does the 'default' name of the download change?
Also, when I de-compressed, and compared the source files to those from a cvs update, I found
them the same, except
the line endings in the tar.gz were *nix form, while the cvs up has 'windows' (cr/lf) line endings ... Does my cvs update do this 'change'? Does the server cvs image contain cr/lf ... no problems ... just a puzzle ...
Anyway, the actions taken during the MSVC7 build ...
The only 'minor' code change, was in Map.cxx, to 'move' the line -
#include <GL/glext.h> to inside the #ifdef UL_GLX block ...
other, non-code items -
1. update map.vcproj to include the 'new' fg_mkdir.cxx - this has now also been included in cvs - March 2005
2. The current MSVC7 project files (Atlas, Map & MapPS.vcproj) -
(a) contain no 'Additional Include Directories' ...
(b) some non-standard static libraries, like simgear_d.lib ...
(c) single path to I: drive, for "Additional Library Directories' ...
(d) runtime library is not 'Multi-threaded (/MT)' - uses DLL ...
(e) missing sg.lib and zlib.lib ...
While I 'understand' that we can each have our own 'personal' arrangement for the prerequisite libraries ... where they are built ... where they are copied ... what their final name is ... so whatever is put in the project files is probably wrong ... but I would opt for a 'single' root, and all others' relative to that root ... as a sort of generic 'start' ...
Assume I have a root of FG099, for the developing next 'release' ... and then I have 'children', sub-directories, like -
png\lpng128 - source http://www.libpng.org/pub/png/libpng.html
SimGear (also contain zlib-1-1-4)
jpeg-6b - source [http://ijg.org/]
An alternative, for png and jpeg is fltk-1.1.6, but the 'core' of fltk is not needed for Atlas ...
This gives me an 'Additional Include Directories' of -
And of course, the 'Additional Dependencies' will change, depending on the configuration -
for Release -
wsock32.lib pui.lib ul.lib fnt.lib net.lib sg.lib SimGear.lib zlib.lib libpng.lib libjpeg.lib
for Debug -
wsock32.lib pui_d.lib ul_d.lib fnt_d.lib net_d.lib sg_d.lib SimGear.lib zlib.lib libpngd.lib libjpeg.lib
Note, the socket library must be added to the 'Atlas' project ... you can add the 'newer' ws2_32.lib, but the 'old' wsock32.lib will still work ...
This Atlas Proj Zip contains the files I used to build this Atlas Runtime Zip, containing the release version of Map and Atlas WIN32 executables ...
WARNING: These these are 'unsigned' exe files, and Atlas does sockets communication, thus you should get a 'warning' in XP, with a firewall enabled, and it is your 'choice' to continue, or not ... ;=)) You also have to have glut32.dll installed ...
Anyway, thanks to Per Liedman and David Luff, and thank you David for your helpful site, and download ... I should perhaps join the Atlas board ... sometime ...
Enjoy it all ... regards Geoff ...
Previous versions - AtlasProj.zip contains files I used to build this AtlasRT.zip, contain release version of Map and Atlas WIN32 executables ...
|- Previous -|- FG Index -|- ATLAS Index -|- Top -|- Next -|