default.htm

功能：基于windows mobile 的地图查看器。使用vs2005开发

        <h3>
            GPS
        </h3>
        <p>
            this was just begging to be done. i believe i wrote the very 1st GPS reader for
            the CF about 2.5 years ago for the <a href="http://www.brains-n-brawn.com/noSink">/noSink</a>
            article. the problem is i haven't done anything with since GPS since then, and there
            are a ton of new GPS class libraries that have been written since then. so i started
            trying them out, and none of them would work. ends up that my old Pretec CompactFlash GPS just wasn't cutting it. but i already had a Pharos 360 GPS from the MS Streets
            and Trips 2005 package, and just headed over to CompUSA to buy a CompactFlash adapter.
            plugged it in and some of the class libs actually started working. ended up going
            with one of the <a href="http://www.develop.com/compactframework/">older ones</a>
            from JW Hedgehog. so all i did was quickly tie that into the app, and now the app
            just keeps the lat/lon updated from the GPS, so the display is always centered on
            your current location. so it works but would be alot cooler if i had the satellite
            images working too.</p>
        <p>
            <img src="images/gpsForm.jpg" />
            <img src="images/gpsLoc.jpg" /></p>
        <ul>
            <li>gps form</li>
            <li>gps locked into my location. my city is too small to even be listed. and yes, i
                have been to both those hooters</li>
        </ul>
        <h3>
            Performance
        </h3>
        <p>
            when you first started reading this article, you probably thought i was crazy. are
            you kidding me? you want to have WW running on your Pocket PC ... and with Managed
            Code! well, i think its doing pretty darn good on a 2 year old device that was never
            intended to run 3D graphics, and is using software emulation. but i cant say that
            it was all that easy, i definitely had to be concious of performance. the first
            battle was with the CPU. WW on the desktop doesnt have to cache much data because
            todays machines have processing power to spare, and they have video cards to offload
            the rendering. the PPC device has limited power, nor does it have a graphics processing
            unit (GPU); so /cfWW
            could not afford the luxury to crunch the same numbers over and over again. to get
            past this i had to do most of the calculations up front during the initialization
            of the program, so that when the program was running it could use all the CPU just
            to handle control input and render accordingly. this takes away slightly from the
            user experience, but keeps the framerate up. in general, this runs at about 10 fps.
            thats low for todays games, but it looks pretty good on a PPC. i do get lag whenever
            i have to load tiles when switching to a higher resolution. when devices get GPUs
            then they will be able to use the CPU for doing calculations and the GPU for rendering.
            the second problem i ran into was limited RAM because of all the caching i was doing.
            there are times when /cfWW is using all the 32 available megs of RAM on the 64 meg
            device. to get around this i just cant turn all the features on at once, and i have
            to unload the cached data when some features are turned off. this also takes away
            a little from the user experience when they are waiting for a data set to load,
            but it keeps more RAM available for rendering and the framerate stays higher. this
            also meant that i had to be real careful of disposing of resources, particulary
            Mesh, Texture, and VertexBuffer objects. wrote a quick little app to reflect against
            the MD3DM assembly to list all the objects that have a Dispose method. NOTE that
            Font has a Dispose method, but does not implement IDisposable? finally, i totally
            ignored a performance feature of MD3DM. it has the cabability to work with fixed
            point math instead of floating point, so this should provide a performance increase
            on small devices without FPU processors. early on i chose to ignore this feature
            and just use floating points for a couple of reasons. first, i wanted to keep the
            code as close as possible to WW. second, from testing on the preview device, it
            did not show any performance improvement between the samples that were implemented
            in both floating point and fixed point. i would definitely rethink this for a production
            quality application or for a device with a GPU</p>
        <pre>
Device
IndexBuffer
VertexBuffer
GraphicsStream
Surface
Texture
SwapChain
Sprite
Font (NOT IDisposable)
BaseMesh
Mesh</pre>
        <p>
        </p>
        <img src="images/splash.jpg" border="1" />
        <img src="images/fpsDiag.jpg" /><ul>
            <li>splash screen while calculations are done and data is cached. i've always wanted
                an app that said 'Initializing Earth ...'</li>
            <li>showing FPS count in upper-left corner and diagnostic info in lower-right. only
                5.5 megs of RAM free</li>
        </ul>
        <h3>
            Conclusion
        </h3>
        <p>
            this explained how i ported the basic functionality of NASAs WorldWind to run on
            a PocketPC using MD3DM. its uses all of the installed data including BlueMarbleTextures,
            Boundaries, and Placenames, it also runs the Add-on for Landmarks and Flags of the
            World. next, i created my own add-on for Hooters restaurants that runs on both the
            desktop and the device. finally, it integrated GPS to make it a truly mobile application.
        </p>
        <p>
            TODO video?</p>
        <p>
            personally, i'm very happy with the outcome because it works better than i initally
            thought it would. plus i learned quite a bit about WW, MD3DM, and CFv2. since WW
            is the largest public DirectX codebase that i know of, i think it speaks alot to
            the power of the MD3DM API that i was able to recreate so much of its functionality
            in a short amount of time. also, i think it speaks to the power of the PocketPC
            platform in general, because i definitely would not have even attempted this on
            any other portable device. especially considering i was starting from ground 0 with
            DirectX and only worked on this for 100 hours in my spare time over the last month</p>
        <h3>
            Source
        </h3>
        <p>
            the source code is listed below ... but ... you really wont be able to use it for
            a while. first, i was developing with an early version of the Magneto OS, installed
            on a loaner Pocket PC provided by MS. the other option is to use the Magneto emulator,
            but its way too slow when it comes to running MD3DM applications. you really need
            a device to do MD3DM development, and they currently are not publicly available.
            second, the source does not include the desktop application that i wrote to convert
            all the data into a device friendlier format. i need to
            clean that code up before
            i can give it away publicly. the other option is to actually just give away the
            converted data, except there is something like 250 megs of it ... and my server
            cannot handle that. when new devices start hitting the market, i'll look into getting
            the code or the data to you somehow.</p>
        <p>
            TODO provide /cfWorldWind code</p>
        <p>
            <img src="images/desktopHooters.jpg" />&nbsp;</p>
        <ul>
            <li>hooters placename data running on the desktop version of WorldWind</li>
        </ul>
        <p>
            but just so you dont go away empty handed, here is the Placenames for getting the
            Hooters restaurants on WorldWind. first, you must create a Hooters directory under
            the \Data\Earth\Placenames\ directory. then you need to copy the files into that
            directory. finally, you need to add the following section to the Placenames.xml
            config file.</p>
        <ul>
        <li><a href="HootersPlacenames.zip">Desktop WW Hooters Placenames Add-On</a></li>
        </ul>
        <pre>&lt;TiledPlacenameSet ShowAtStartup="true"&gt;
  &lt;Name&gt;Hooters&lt;/Name&gt;
  &lt;DistanceAboveSurface&gt;0&lt;/DistanceAboveSurface&gt;
  &lt;MinimumDisplayAltitude&gt;0&lt;/MinimumDisplayAltitude&gt;
  &lt;MaximumDisplayAltitude&gt;500000&lt;/MaximumDisplayAltitude&gt;
  &lt;PlacenameListFilePath&gt;Data\Earth\Placenames\Hooters\ww.wpl&lt;/PlacenameListFilePath&gt;
  &lt;DisplayFont&gt;
    &lt;Family&gt;Arial&lt;/Family&gt;
    &lt;Size&gt;8&lt;/Size&gt;
    &lt;Style&gt;
      &lt;IsBold&gt;true&lt;/IsBold&gt;
    &lt;/Style&gt;
  &lt;/DisplayFont&gt;
  &lt;WinColorName&gt;Orange&lt;/WinColorName&gt;
&lt;/TiledPlacenameSet&gt;</pre>
        <p>
            <span style="font-size: 12pt"></span>
        </p>
        <h3>
            Updates
        </h3>
        <p>
            of course the desktop version of WW implements alot more, including : scripting,
            terrain, highres satellite imagery, MODIS data, and caching. /cfWW is setup to implement
            all this additional functionality, but i will not think about attempting it until
            a newer device is available with a faster CPU, more RAM, and preferably a GPU. the
            second version would probably just work off of data that had been cached on the
            desktop. a third version would then actually pull the data down directly over the
            internet.</p>
        <h3>
            Future
        </h3>
        <p>
            on the seventh day, i rested. on the eighth day, i started in on my next project
            ... later</p>
	</body>
</HTML>