Algorithm for calculating jump distances

[forthekill]

Yep, great work! Keep going - only a few hundred more features to go! Ping me if you need any advice. The two things I'd advise going after sooner rather than later are (1) some sort of styling abstraction, and (2) coordinate transforms.

(The days where TravellerMap.com should rely on server-side rendering are numbered. Map sites in general are moving towards sending vector data down to the browser to render using Canvas or SVG.)

1. I'm assuming you mean removing the styling and color settings from the drawing code so that ultimately it is easier for users to set their own scheme without messing with the code? I could create something like a config.js file to set those variables to make it easier.

2. Can you elaborate? I'm not sure what you mean.

 

[inexorabletash]

1. I'm assuming you mean removing the styling and color settings from the drawing code so that ultimately it is easier for users to set their own scheme without messing with the code? I could create something like a config.js file to set those variables to make it easier.

Exactly. Then it's easier to support predefined styles, user defined styles, styles that vary with scale, etc.

2. Can you elaborate? I'm not sure what you mean.

Coordinate system transforms are important in three ways. First, it's convenient if you can write high level code like "draw a route from 1204 to 1407" and have some common code that maps that to the pixel locations, taking into account even/odd hexes. You presumably already have that for drawing the worlds.

Secondly, you'll want to look at coordinate systems that go beyond a single sector. Initially this is helpful so you can draw routes that go in and out of sectors, but then you can do things like Domain maps. So you may want to consider mapping everything from sector-local coordinates to global coordinates, then back to render-space coordinates. I babble on about the different coordinate systems I use on my API page. travellermap.com/map.js also has some calculations in the Astrometrics section that may be reusable.

Thirdly, canvas (and most other drawing APIs) support setting rendering transforms. It's incredibly convenient when rendering individual hexes, for example, if the center of the hex is at x=0, y=0, positive y is up, and a hex is 1 coordinate across. For example, with the canvas API you might do:

context.save();
context.translate(centerOfHexX, centerOfHexY); // from note #1
context.scale(pixelsPerParsec, -pixelsPerParsec);
// your world drawing code here - center is at 0,0, hex is 1.0 across
context.restore();

(I can never remember if you want to translate by (x,y) or (-x,-y), and scale by (ppp,-ppp) or (1/ppp, -1/ppp), sorry if I got it backwards)

 

[forthekill]

Exactly. Then it's easier to support predefined styles, user defined styles, styles that vary with scale, etc.

I broke out that stuff to simple variables within the file for now. I'll make sure anything I add in the future takes that into account.

Coordinate system transforms are important in three ways. First, it's convenient if you can write high level code like "draw a route from 1204 to 1407" and have some common code that maps that to the pixel locations, taking into account even/odd hexes. You presumably already have that for drawing the worlds.

Currently I have a function that just calculates the hex info based on side length, and the start point (currently the leftmost point) for drawing a hex using the hex number to calculate the offset. It also calculates each of the other 5 drawing points as well as the center point.

So, for example, I can call that function from within my world drawing function to get the info for hex 0412, and draw the world using the center point.

I am thinking of adding properties to the object the hex function returns to store the world name location, starport location, hex number location, etc. so everything is in one function, rather than calculating that stuff in the drawing functions.

Secondly, you'll want to look at coordinate systems that go beyond a single sector. Initially this is helpful so you can draw routes that go in and out of sectors, but then you can do things like Domain maps. So you may want to consider mapping everything from sector-local coordinates to global coordinates, then back to render-space coordinates. I babble on about the different coordinate systems I use on my API page. travellermap.com/map.js also has some calculations in the Astrometrics section that may be reusable.

This sounds like some real fun stuff, even with my math-friendly brain. Forgive me if I procrastinate that part

Thirdly, canvas (and most other drawing APIs) support setting rendering transforms. It's incredibly convenient when rendering individual hexes, for example, if the center of the hex is at x=0, y=0, positive y is up, and a hex is 1 coordinate across. For example, with the canvas API you might do:

context.save();
context.translate(centerOfHexX, centerOfHexY); // from note #1
context.scale(pixelsPerParsec, -pixelsPerParsec);
// your world drawing code here - center is at 0,0, hex is 1.0 across
context.restore();

(I can never remember if you want to translate by (x,y) or (-x,-y), and scale by (ppp,-ppp) or (1/ppp, -1/ppp), sorry if I got it backwards)

Hmm that's interesting. I'll have to look into that.

By the way, thanks for the feedback. I have a long way to go from taking this from fun experiment to usable library.