What kind of parameter coupling is the least taxing for the caller when data needs to be mapped?

Question

I'm creating a math library that will deal with points as function inputs (as shown below).

public struct Point { public int X; public int Y; }

public static class MyLib
{
    public static float CalculateSomething(Point point1, Point point2) 
    { ... }
    ...
}

My plan is to be able to use it alongside various graphics/gaming libraries and as such that will require transformation from whatever that Point type is from the graphics library to the one provided by my library before it can be used.

Using a Point struct (or class in Java version) as a Parameter Object, which would be object parameter coupling is a clean and nice way to simplify knowing what to pass in but it also requires mapping it to my Point struct/object first before every function call:

var mappedPoint1 = new Point(point1.x, point1.y);
var mappedPoint2 = new Point(point2.x, point2.y);
var result = MyLib.CalculateSomething(mappedPoint1, mappedPoint2);

An alternative could be to use a simple data parameter coupling where only primitive types are passed as parameters:

var result = MyLib.CalculateSomething(point1.x, point1.y, point2.x, point2.y);

I can also see pros/cons to this approach as well since it doesn't require mapping to a data object but does have problems if they mess up the order of primitive types being passed in. Or if more parameters are needed, it would start to become a large parameter list.

What kind of coupling here will be the least taxing on the calling code? While primitive parameters are the simplest to interface with the point abstraction brings clarity and context but also demands more work and mapping code.

Answer 1

Gaming engines and libraries I've worked with usually provide both object parameter and simple data parameter coupling via overloaded methods.

Are you going to use Point internally to your algorithms, or is the first step always going to be to decompose Point into simple data? Most definitions of geometry in game engines have useful operations on them such as distance that you yourself might want to use in your functions. If you plan to use the objects internally to your function definitely define object parameters and define simple data parameter overloads, otherwise don't even bother with the object parameters. Simplicity is often better.

If you have a handful of game engines that you want to target specifically, a third option is to define library-specific bindings of your functions that use the libraries objects as parameters. E.g. I can pass in a Vector2 from LibGDX by importing the LibGDX bindings of your library. This seems like too much work though.

Properly documented code will be the best way to help a user with your library.