Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Int/Float vs Long/Double #185

Open
CedNaru opened this issue Jul 27, 2020 · 7 comments
Open

Int/Float vs Long/Double #185

CedNaru opened this issue Jul 27, 2020 · 7 comments
Assignees

Comments

@CedNaru
Copy link
Member

CedNaru commented Jul 27, 2020

A quick summary of the use of 32/64 bits values in Godot.

Godot internally uses 32 bits Integers in its structs/classes and 32 bits Floats as well (named real-t).
Godot supporting 64 bits float is still no ready but should be possible by changing real-t to 64bits.
In some rare functions, Godot still uses 64 bits variables when it's explicitly needed (like returning a 64 bits Hash).

In order to communicate with the scripting API (for GdScript and GdNative), Godot creates the Variant class to wrap any primitives, core, and object Godot can use.
Variant internally stores a 4bits variable to identify the type. There is no information about the size of Int/Float inside. So for convenience, they are widened to the largest one (aka 64 bits).

Godot sends all its information to native scripts as Variant and the ClassDB doesn't hold information about the actual size either. The direct consequence is that we can't use 32bits values in the Icalls, so all of them have to return Long/Double.

The native functions we register to Godot don't have to be Long/Double. The Int and Float parameters will be cast to Long/Double behind the hood and cast back to their original size automatically when the native functions are called from Godot.

The last case is about the core types. Their internal variables should be 32 bits to match Godot and to keep their size in check. The main issue is the consistency of types, we would end up core types returning 32bits values and Icalls returning 64 bits.

So the idea is to keep the internal values of cores as 32 bits, but all methods/properties will still return a 64 bits version.
That way we keep the memory footprint at a minimal size but still remains consistent with Godot Objects.

Summary:

  • Icalls: 64 bits only
  • Registered Function: Support 32 and 64 bits with auto wrapping.
  • Cores: Internally use 32 bits but returns 64 bits.

What do you think ?

@chippmann
Copy link
Contributor

@CedNaru

Registered Function: Support 32 and 64 bits with auto wrapping

You mean the entry generation and like it is currently on master merge

@CedNaru
Copy link
Member Author

CedNaru commented Jul 27, 2020

Yes that's what I meant.

@chippmann
Copy link
Contributor

Ok.
I think this is the best approach we have on this problem. So I'm in.

@piiertho
Copy link
Member

If we cannot get the size info, we don't have choice :/

@raniejade
Copy link
Contributor

Cores: Internally use 32 bits but returns 64 bits.

@CedNaru what do you mean by this?

Registered Function: Support 32 and 64 bits with auto wrapping.
Includes properties and signals as well right? And when you say auto-wrapping, do you mean widening and de-widening (when appropriate) when sending and receiving real numbers to/from godot?

@CedNaru
Copy link
Member Author

CedNaru commented Jul 28, 2020

Cores internally use 32 bits, but the property getters and setters will use a 64 bits type, it would be then narrowed.
Same with the functions of core type. Let's say I want to write vect2.length(), despite the x and y being Float, the function would return a Double.

And yeah I meant registered function, properties and signals with widening ( and opposite) when necessary. Just like Cedric already did. I said wrapping, because we would directly use Variant wrapping and unwrapping but it was probably clumsy to use that term now that it's going to be removed.

@chippmann
Copy link
Contributor

@CedNaru this can be closed now right?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants