"Truly infinite move distance"

[optim-ally]

This is listed as the first of the "crucial features" still to be implemented.

Moves are currently stored as strings (e.g. "62,22>120,82=N"). These can theoretically represent moves of arbitrary distance.
Once loaded into the browser, however, they get converted to Number types for manipulation:

infinitechess.org/game/formatconverter1.js

Lines 807 to 814 in 52fb167

	/**
	* Returns a length-2 array of the provided coordinates
	* @param {string} key - 'x,y'
	* @return {number[]} The coordinates of the piece, [x,y]
	*/
	function getCoordsFromString(key) {
	return key.split(',').map(Number);
	}

This bounds useable move distance to Number.MAX_SAFE_INTEGER which is 2⁵³ - 1. Coordinates larger than this may not be compared correctly, for example when checking if a destination square is on the same file.

There are already some BigInt helpers in the codebase - I don't know how close these are to being used. Using BigInt for coordinate calculations and comparisons would allow arbitrarily large and safe move distances but it may not be worth it. There could be a considerable impact on speed just to be able to say that "infinite move distance" is supported. Perhaps users can choose a "truly infinite" setting to enable BigInt calculations? Some benchmarking is needed before switching over.

If we decide that BigInt is worth the slowdown then the bottleneck may once again become the game storage. The string representation is only "infinite" if the database supports arbitrary string lengths.

[this-is-not-available]

There is a discussion about this here
https://discord.com/channels/1114425729569017918/1260305383302631484
(I think)

[Naviary2]

Discussion here Basically, a bit ago I started on a library supporting fast arbitrary-precision decimal and integer arithmetic, using BigInts paired with fixed-point arithmetic. A dedicated portion of the BigInts least-significant bits are dedicated towards the decimal portion of the number.

But this library isn't required to store the coordinates of the pieces, those are integers and BigInts can be used. But if we want to make this "truly infinite", we also need arbitrary decimal precision to store the player's position, and zoom level.

I don't think we'll have to worry about BigInts, yes they are slower than doubles, but they are the fastest thing we have when it comes to arbitrary integer arithmetic. The mesh of the pieces only needs to be calculated once, and in games with 32 pieces, that's pretty much instantaneous even if you are at extreme distances.

But, to not hurt already-high-performance, I suggest games are stored in their current format, until someone makes a move that is beyond Number.MAX_SAFE_INTEGER. At that point the gamefile gets converted into BigInts, and you get a slight performance decrease, likely only noticable in games with over 10,000 pieces.

Probably we should have the player position and zoom level always stored as a BigDecimal though (the name of the library being written), for simplicity's sake, even if they haven't moved past Number.MAX_SAFE_INTEGER. 2 arbitrarily large numbers is nothing to calculate once per frame.

That BigInt helper in the codebase is outdated, it will be replaced by this custom library.

Speed is also a huge priority of mine so I want to make sure this is optimized as possible as very much playable before we switch.

[Naviary2]

Waiting on #83 , as we have been needing a new gamefile format, and this feature also changes the format of gamefiles when people move beyond Number.MAX_SAFE_INTEGER.