How did you do that?

The map works the same way (I assume - I don't know for sure) as the latest generation of commercial map sites - Windows Live Local , Google Maps, Yahoo! Maps, etc. Which is...

There are two parts: an HTML page and a special Web server application.

There's an HTML page with script in it. The page keeps track of three things: where your view is centered (in my case, astrographic coordinates), what your zoom level is (pixels/parsec) and what view options you have selected (coded into a binary number). When the page loads it runs a simple subroutine that tries to answer the question: "gosh, what should the user see here?"

This subroutine first figures out how big the window frame is, then breaks it down into 256x256 pixel "tiles", and then figures out specifically which tiles it needs to fill the frame based on where the user is looking.

Here's an example tile URL:

http://www.travellermap.com/Tile.aspx?x=-1.2&y=-1.0&scale=2&options=881

(For historical reasons the x/y values are actually scaled by the zoom level, so if you change the zoom level your point of focus will change. Strictly speaking, the x and y are in screen space rather than world space, but it's all just a transform away.)

The HTML page then just says "add a tile image at this URL to the page at this position" - in HTML parlance, it just creates a new IMG element with a SRC like the above and and uses STYLE to position it. It does this until the window frame is full. Drag/scrolling is actually pretty easy - the page captures mouse events and when the mouse drags, say, 10 pixels to the left, it simply offsets the HTML element which contains all of the tiles by 10 pixels to the left. And then (here's the magic bit) it simply runs the whole logic all over again - "gosh, what should the user see here?" which determines if any new tiles need to get loaded around the edges. Any time you change options the same thing happens - it just throws away the images you're looking at and figures out which tiles to ask for.

That leaves the server side. In this case it's an ASP.NET 2.0 web application on IIS6, but you could do the same thing with pretty much any server. The nice thing about ASP.NET is that you get GDI+ (a high fidelity graphics subsystem of Windows) available easily, but again there are equivalents for PHP if you were doing this on Apache.

The web app handles the incoming request for a tile URL (like the above), creates a temporary image in memory, and falls into a big rendering routine. Based on the zoom level, it figures out what to draw - from the whole galaxy to borders and rifts to routes and dot-maps to hexes and systems. Based on that, it figures out which data files to load (from a cache) and it either loads XML vector shapes which define the borders/rifts, a big XML file which defines which sectors are where and the metadata, or (at a low level) the standard .SEC files. It figures out what subset of that should be drawn in the current tile and draws it. (The way modern graphics systems work, you can draw "sloppily" outside the bounds of a box and it'll get clipped. This is convenient - I just draw everything "close" to a tile, and the right stuff shows up.)

Then the server takes the image in memory, converts it to a GIF, and returns it to the Web browser. Rinse and repeat.

Make sense? Ω