Provide point types with coordinate system type-safety

[jbytheway]

Summary

SUMMARY: Infrastructure "Provide point types with coordinate system type safety"

Purpose of change

Cataclysm has a lot of different coordinate systems. It's confusing to work with them, but even more so it's confusing to read code working with points and have no idea what type system they're in.

This PR aims to provide a collection of point/tripoint types which encode the coordinate system in their type, so that it becomes clear what points mean and easier to correctly use APIs that have point/tripoint arguments or return values.

Describe the solution

• New namespace coords to contain all the details.
• Enums therein to define all the possible scales and origins for which we need coordinate systems.
• A class template wrapping a point or tripoint, with added coordinate system info.
• Functions project_to and project_remain for coordinate system transformations. Between them, these two functions can do anything that any of the functions in coordinate_conversions.h can do.
• Typedefs for the common point/tripoint and coordinate system combinations for ease of use.
• Suitable operator overloads.
• constexpr all the things.
• Add Catch::Generator and Catch::StringMaker specializations for easier working with point/tripoint in tests.
• Write tests for all the above.

Deferred to a future PR:

• Support for vehicle space coordinates.
• Support for map space coordinates.

Note that this initial PR does not intend to actually convert code to use the new types, although I will try to do at least some experiments with them to verify that things work smoothly.

For the purposes of this PR, look at the tests for usage examples. For broader context, see #41693 which demonstrates the use of these types on a fairly large scale for various overmap-related stuff.

Describe alternatives you've considered

There are other ways to express the coordinate systems than the scale/origin pair I've chosen. This approach is very nice for the conversion functions. I think it will owrk nicely in general, but that requires further experimentation.

Additional context

The new class template is mostly agnostic to the underlying implementation of the point type, so there is room to support more storage choices in the same framework, e.g. if we wanted to have a more compact type that used less memory and offered less precision.

[BevapDin]

Maybe a tag type (not enumeration value) is better. It allows easier adding of new systems. All properties (like scaling/absolute vs relative) can be done withing that tag type.

E.g.

class sub_map_system;

class map_system {
// this would allow converting map_system to sub_map_system, but not to say vehicle coordinates
// instead of a debug message this would yield a compiler error (as there is no factor_to( vehicle_system) function)
    static int factor_to( const sub_map_system & ) {
        return 12;
    }
};

[jbytheway]

I think the code is simpler with two independent features rather than a tag type that controls all aspects. Could use types rather than an enum. I chose the enum because more meta-programming logic can be written in "regular C++" constexpr functions, rather than type-specialization style, which I was hoping would be clearer and easier to follow.

I'll try to keep both approaches in mind, though, if this version gets unwieldy.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[jbytheway]

Thanks, stalebot. Still working on it :).

[mlangsdorf]

vehicle scale should possibly be split into two scales: vehicle_mount (the unrotated nominal displacement from the 0,0,0 position) and vehicle_actual (the current projection of a vehicle_mount along a tileray). Perhaps those should be special origins.

[jbytheway]

Yeah, I haven't delved too deeply into vehicle stuff yet. My thoughts were that the mount coords would be origin vehicle, scale vehicle, while the projected-into-world coordinates would be origin vehicle, scale map_square. But I'm not too tied to that idea yet.

[mlangsdorf]

I'm not too particular about how they're laid out, I just hate:
void coord_translate( int dir, const point &pivot, const point &p, point &q ) because it's not immediately clear that p and q are actually supposed to be separate types and whether pivot is the same or a different type.

If that becomes
void coord_translate( int dir, const veh_veh_point &pivot, const veh_veh_point &p, veh_ms_point &q ) then I'm satisfied, aside from veh_veh_point looking kind of silly.

[mlangsdorf]

scale veh should be scale mnt, so:
void coord_translate( int dir, const veh_mnt_point &pivot, const veh_mnt_point &p, veh_ms_point &q )
which doesn't look too bad.

[jbytheway]

Now that #41693 demonstrates the end-goal of this effort a little more clearly I think this PR is in a state where it can be reasonably reviewed, and I'm marking it ready.

The code here still doesn't actually do anything, but adding enough to allow it to will make for a huge PR (like #41693) so I'm offering this as the first bite-sized chunk. More will follow once this is merged.

[jbytheway]

Hah, I've just realised that it's exactly one year from opening this PR that I mark it ready for review. Interesting coincidence...

[jbytheway]

Hopefully now fixed the clang-tidy issues. The test failures looked unrelated.

[jbytheway]

CI now looks good to me (as good as it can be, right now, anyway).