Expand precision=double to ints

[Repiteo]

Describe the project you are working on

A project substituting floats for 64-bit fixed-point numbers

Describe the problem or limitation you are having in your project

Any project attempting to utilize fixed-point to any scaleable degree would have to implement custom types for Vector2 and Vector3 equivalents. Vector2i and Vector3i are not acceptable substitutes, as they will truncate their 64-bit precision for 32-bit. Unlike what double precision does for floating-point, there is no way to prevent this truncation for integers

Describe the feature / enhancement and how it helps to overcome the problem or limitation

This headache would be mitigated if an equivalent to real_t was added for ints. As far as I can tell, there's no real reason to have them excluded from the double precision format, as the combined performance hit is rather negligible. I imagine the necessity isn't comprable, double-precision floats take that hands-down, but I wouldn't consider that a reason for exclusion

Such an equivalent being added would mean less concern about precision or data being lost in translation across the project via potential conversions to & from int/Vector2i/Vector3i. The need for specialized classes would still probably be necessary, but not to NEARLY the same extent

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

#ifdef PRECISION_IS_DOUBLE
typedef double real_t;
typedef int64_t int_t;
#else
typedef float real_t;
typedef int32_t int_t;
#endif

If this enhancement will not be used often, can it be worked around with a few lines of script?

Technically, yes; the situation I described is admittedly niche & a fixed-point system should ideally have plenty of designated and isolated classes/functions in its own right (hell, one already exists). But as far as working around the inherent truncation from ints to Vector2i/Rect2i/etc, absolutely not

Is there a reason why this should be core and not an add-on in the asset library?

This is core functionality, an add-on couldn't address this

[dsnopek]

Thanks for creating this proposal! I had intended to make one like it myself :-)

[Calinou]

I wonder if int_t can be confused for int64_t and int32_t. real_t is distinctively different from any C++ standard type after all. Should we name it something that's impossible to mistake for a C++ standard type, such as integer_t?

[Repiteo]

I'm not married to int_t as the name, that was more as a proof-of-concept. integer_t is a bit more verbose, but it certainly wouldn't be mistaken for a C++ standard type, so I have no objections

[dsnopek]

Since this has a very Godot-specific use (expanding the size of integers used in Vector2i and Vector3i) maybe it could be vector_int_t? int_vector_t?

Or, perhaps, the typedef could be local to the individual classes? So, like:

class Vector2i {

#ifndef PRECISION_IS_DOUBLE
	typedef int32_t integer_t;
#else
	typedef int64_t integer_t;
#endif

	union {
		struct {
			union {
				integer_t x;
				integer_t width;
			};
			union {
				integer_t y;
				integer_t height;
			};
		};

		integer_t coord[2] = { 0 };
	};
};

This would involve duplicating the typedef in both Vector2i and Vector3i, but it's just a tiny bit of duplication.

In any case, this way we wouldn't be polluting the global namespace with this weird type, it'd be scoped to just the classes use it.

Just some random ideas :-)