Add virtual memory address reporting of Variant objects in the editor debugger

[crazychenz]

Describe the project you are working on:

I am working on a small grid-based puzzle game. When I rotate (without rounding) Vector2(-1, 0) 180 degrees, I expect Vector(1, 0). Unfortunately, due to #37647, #27665, #17971, #288, and so forth, there are apparent inconsistencies with floating point precision in GDScript.

Describe the problem or limitation you are having in your project:

This floating point precision issue in my case is simply resolved with a round() (or possibly is_equal_approx()). The fact that there is a floating point precision issue is not my issue here.

My issue is that troubleshooting the above state was very difficult using standard debugging techniques. I would have expected to see a more accurate representation of what the engine was interpreting as the value instead of what it wanted to present to the user for usability purposes.

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

I believe that the debugger in Godot should allow developers to drill down into the actually memory locations of the objects or values they are inspecting. I would very much like to see some sort of hex representation of the data being pointed to by a Variant struct/object instance (directly in the GDScript debugger).

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:

As a use case, I would expect that a user should be able to retrieve the virtual memory address of any Variant object that is tracked by Godot. This would allow a loose coupling between any memory analyzer within or attached to the process to display the "real data". This would include using windbg on windows or gdb in GNU environments. Ideally, Godot would also provide its own runtime memory manipulation tools within the editor as a Debugger tool.

Implementation wise:
Looking at variant.h, I think that you just need to provide a global scope function that takes a Variant and depending on the type either returns &Variant._data or Variant._get_obj().obj. Perhaps something like:

var variant = Vector2(1, 0)
var pointer = __get_virtual_memory_address(variant)
print("Pointer: %s")

would output something like:
Pointer: 0xFFFFFF34A8432

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

I do not believe this can be worked around in scripts.

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

Godot Engine needs to expose the virtual memory addresses of objects or Variant objects and the rest may be implementable in an external asset. That said, I believe this should be included in core because of the lack of tools to detect/inspect/analyze the issues described in the tickets at the beginning of this issue.

[crazychenz]

Just found OS.dump_memory_to_file(). This is currently not implemented:

void OS::dump_memory_to_file(const char *p_file) {

	//Memory::dump_static_mem_to_file(p_file);
}

If it were implemented, it could maybe be used in conjunction with a reported virtual memory address to solve the problem explained above.

[Calinou]

(Note: I wrote the comment below before reading the rest of your proposal.)

As for the floating-point issue, Godot 4.0 will have Vector2i, Rect2i and Vector3i types (they're already available in master). These are integer equivalents of Vector2, Rect2 and Vector3 respectively. This should solve floating-point precision errors for methods that return integer vectors.