[Mono] Replace float with real_t, other misc C# improvements #17134
Conversation
Wow, super exciting Aaron! :) |
Ah, this is still [c#] only. It still requires the real_t patch I started on. Good work on C# though. |
Yes @fire so you should rebase your branch soon but as my patch doesn't add any compiler flags and doesn't break any existing functionality I decided to commit back to master. |
@@ -220,13 +220,13 @@ public Vector2 Tangent() | |||
} | |||
|
|||
private static readonly Vector2 zero = new Vector2 (0, 0); | |||
private static readonly Vector2 one = new Vector2 (1, 1); |
akien-mga
Mar 1, 2018
•
Member
Could you squash that into the original commit?
Could you squash that into the original commit?
aaronfranke
Mar 1, 2018
Author
Member
I've never done that before. After looking it up, I am confused, don't you have the option to "squash and merge"?
I've never done that before. After looking it up, I am confused, don't you have the option to "squash and merge"?
akien-mga
Mar 1, 2018
Member
We do, but it has various flaws, so we don't use it. See http://docs.godotengine.org/en/latest/community/contributing/pr_workflow.html#mastering-the-pr-workflow-the-rebase
We do, but it has various flaws, so we don't use it. See http://docs.godotengine.org/en/latest/community/contributing/pr_workflow.html#mastering-the-pr-workflow-the-rebase
aaronfranke
Mar 2, 2018
Author
Member
Thanks for that article link, it's quite helpful. I was able to figure it out, it's now just one commit.
Thanks for that article link, it's quite helpful. I was able to figure it out, it's now just one commit.
CC @neikeq |
Sorry, I'm still busy with final exams and this looks like a PR to review well before merging. I'll be back for sure on Tuesday. |
I'm not sure about providing a method with float parameters and another for double. I understand why you made it this way, so the same code compiles both with |
Hopefully I can test this on some projects tomorrow. I think I'll need to do some changes to the bindings generator. |
I do believe it would be a good idea to build with double by default, once support for doubles is completed (#17134 and #12299), and if we can ensure project compatibility and high performance (@NathanWarden has shown concern about
|
The rarer case is that If it doesn't make a mess out of the project it would be nice to be able to keep both for now, but I would completely understand if we just went all double to keep things clean. |
@neikeq I have more code to contribute, unrelated to double-precision support so therefore I'll put it in a separate PR. But I can't do that until this PR is merged since it's built on top of this PR's code. |
After thinking for a bit, I don't think any changes are required in the bindings generator. We would need to make the editor build the solution with the REAL_T_IS_DOUBLE flag.
Yes, I understand the reasoning behind it. But I still think it would cause confusion. If REAL_T_IS_DOUBLE was the default, the story would be different. Any way, everything else looks good, so I won't prevent this from being merged if the community is in favour of it. BTW, we will need to have some unit tests soon, to make sure nothing breaks. |
Purely accepting Otherwise, is testing the only concern preventing merging then? |
We will need testing at some point, regardless of this PR. It also bothers me to do this things without knowing what the plans are for REAL_T_IS_DOUBLE in the engine. These do not block this PR from being merged though, since this code doesn't change anything (except the two methods for float and double thing) unless REAL_T_IS_DOUBLE is enabled. You can see the same changes already being done in the engine. |
I wish there was a team or something I could tag regarding C# changes. This way we could get some quick feedback from other people about what they thing on changes like the alternative method thing in this PR. |
I see. You'll have to ask @fire about the plans for the compiler flag(s). This PR basically not changing many things without the compiler flag enabled is exactly why I decided to create a PR directly to Godot rather than a PR to @fire 's fork. If it doesn't break anything I want to push upstream whenever possible. A mailing list or something for C# changes sounds like a great idea, for reviewing and feedback. If you make one, feel free to add me to it: |
@PJB3005 @mysticfall @paulloz @NathanWarden Sorry to bother you. You were quite active recently on mono related issues and PRs so I would like your opinion on this matter. IINW, this is in order to make the following code compile whether
The reasons I don't like this are:
What do you think? |
Hey, nothing to be sorry about, feel free to tag me if needed/wanted. I personally share @neikeq's reluctances regarding the parameters inconsistency and the fact that (imho) when explicitly giving a Sidenote, VERSION.txt should be incremented. |
Ah, yes. There is another PR which already incremented it to 2. Weird that's not causing a conflict. |
I don't mind being mentioned. Hell I was wondering about how Godot's support for doubles was anyways so this is nice to see. Hell sign me up for that mailing list idea if it goes anywhere. If constructors get the overloads then regular methods need it too, probably. To avoid confusion you could use The problem kinda is that there's no way you're gonna get code to be compatible to both double and float reasonably (without using floats everywhere, thus defeating a lot of the point) because C# doesn't allow you to typedefs that can be imported like Rust does. I'd say compiler warning for doubles if they'd be trimmed is as good idea. |
Honestly, I haven't thought about the fact that the behavior is inconsistent with other methods. To me this is a bigger issue than any confusion caused by accepting Arguably there are not many precision issues if you choose to use only I think I'll go ahead and make a fixup commit to make constructors |
Incrementing version is causing Git to throw a fit... I'll keep it at 2 for now (it can be incremented later, or changes can be forced by deleting Honestly, there are a lot of issues with checking the version in this way. We should re-think our approach. A text file storing a version number is not ideal. |
Replace float with real_t in most files, defined at the top of each file via using. Objects such as Vector3 now accept doubles as inputs, and convert to real_t internally. I've added default Vectors such as Vector3.Zero. Other misc C# improvements such as Mathf.RoundToInt(). Color continues to use float only because high precision is not needed for 8-bit color math and to keep things simple. Everything seems to compile and work fine, but testing is requested, as this is the first time I've ever contributed to Godot.
Thanks! |
@neikeq The biggest issue is that it hinders the ability for us to have simultaneous Mono PRs.
Furthermore, it makes changing features of C# more difficult, especially if people don't know about incrementing VERSION and wonder why code changes do nothing (as I've experienced) Alternative: Perhaps a checksum of each file to find out of the files changed (and if so, recompile) |
If it needs versioning for consistency checking then I like the checksum approach @aaronfranke mentioned, and then rebuild if that changed. If it doesn't need versioning, then it seems to me like it could just recompile no matter what. C# builds super fast to start with and the code base for this is pretty small which makes it even faster. But, I completely agree, the first time I tried to change anything in the C# project it was pretty confusing. It would be nice to make this not be an issue for any developers who want to help improve the C# side of things. :) |
Cherry picked into 3.0.3 |
I've replaced
float
withreal_t
in most files, defined at the top of each file viausing
and#if
.Note that this is a stepping stone to double-precision support in Godot C#, I don't expect it to compile with
REAL_T_IS_DOUBLE
yet. What this patch does do is abstract much of what used to befloat
toreal_t
. It seems to works perfectly fine when compiled withfloat
with my test code, though I would recommend testing this patch with actual projects to make sure it works. There's not really any downside to merging this patch, assuming everything works as expected.Color continues to use
float
only because high precision is not needed for color math and to keep things simple. The String-float parsing is also left asfloat
for now.I've added default Vectors such as Vector3.Zero etc. I used a
private static readonly
variable and apublic static
getter, following the example of the existingQuat.Identity
code.I made a few other misc C# improvements such as
Mathf.RoundToInt()
.Again, I would advise testing before merging. I may have missed a thing or two. If you are having issues with compiling the changes, delete
~/.local/share/godot/mono
and remake the Mono glue.