gdext
gdext copied to clipboard
Integer is zero when passing it to function that takes f32/f64
Hi there,
I defined the following function in my gdextension:
#[func]
fn add_two(&mut self, a: f32) -> f32{
println!("a:{}",a);
return a + 2.0;
}
The following call has no problems from gdscript
print(add_two(1.0))
This will print a:1
, which is expected.
However if I call this
print(add_two(1))
This prints a:0
, which is not what I expected.
Is this behavior expected, or is there something else going here I'm missing?
My mind went directly to ABI--I thought for some reason something the rust compiler is doing...?
In any case I looked at the dwarf and it looks like the type abi from my rust gdextension matches that of Godot functions "real_t".
Here is real_t
dwarf info from godot compiled from source:
0x00003839: DW_TAG_base_type
DW_AT_byte_size (0x04)
DW_AT_encoding (DW_ATE_float)
DW_AT_name ("float")
Here is the one for my rust code
0x00024b82: DW_TAG_base_type
DW_AT_name ("f32")
DW_AT_encoding (DW_ATE_float)
DW_AT_byte_size (0x04)
I hope I explained this clearly enough. Am I missing something here?
Thanks in advance!
Here is some more info about my system/environment:
VERSION="22.04 LTS"
ID=pop
ID_LIKE="ubuntu debian"
PRETTY_NAME="Pop!_OS 22.04 LTS"
VERSION_ID="22.04"
HOME_URL="https://pop.system76.com"
SUPPORT_URL="https://support.system76.com"
BUG_REPORT_URL="https://github.com/pop-os/pop/issues"
PRIVACY_POLICY_URL="https://system76.com/privacy"
VERSION_CODENAME=jammy
UBUNTU_CODENAME=jammy
LOGO=distributor-logo-pop-os
Godot_v4.0-beta15_linux.x86_64
rustc 1.65.0 (897e37553 2022-11-02)
My mind went directly to ABI--I thought for some reason something the rust compiler is doing...?
I think conversions from GDScript int
to Rust f32
are not yet implemented.
The initial implementation was quite strict, types needed to match exactly.
In ergonomics sake, we can maybe define some rules regarding which conversions are safe. Unfortunately implicit conversions introduce a lot of potential for error, so I'm not sure if we should support it at all.
Anyway, thanks for reporting!
So i think this issue is at least partially fixed. i.e when done as a ptrcall it will succeed as expected, however when done as a varcall this will report a spurious error that the method does not exist for the second call.
this is caused (i believe) by us panicking when we try to convert a variant containing 1
into a float, which triggers the above message by #254. however with a pointer call we just use as
to convert.
@thebigG do you know if this is still a problem with latest master and latest Godot (4.2-rc1)?
Current status of this, running this code:
var bar: Bar = $Bar
bar.add_two(1.0)
bar.add_two(1)
$Bar.add_two(1.0)
$Bar.add_two(1)
will print a: 1
for the first three, but then error on the fourth one with a type conversion error.
for consistency we should probably try to make it so that 2 and 4 have the same behavior. either both have a type conversion error or they both succeed with type coercion.