NDK C returns weird floating number

I probably missing something simple. Currently I am using C for some calculations, at this stage i am not using any android java code that will come later. I have experience using C for android apps but not unity.

My floats are returning really weird number like 1.03730-43 and after a few clicks it goes to 0

This is what i currently have.

jni.cpp

Code (csharp):

1.  
2. #include <jni.h>
3.  
4. #include <string.h>
5. #include <stdio.h>
6. #include <math.h>
7. #include <android/log.h>
8. #include <stdlib.h>
9. #include <string.h>
10. #include <stdbool.h>
11.  
12. extern "C"
13. {
14.   int xint(int a, int b)
15.   {
16.   return a * b; //works great
17.   }
18.  
19.   int add(float a, float b)
20.   {
21.   return a + b; //return (float)(a + b) also produces a weird number
22.   }
23.  
24.     }
25.  

I am compiling as using ndk-build.cmd. I did not set any 1.6 or 1.7 settings as i am not using java.
I am currently using JavaPluginSample from unity as a testbed.


C# code.

Code (csharp):

1.  
2. using UnityEngine;
3. using System.Collections;
4. using System.Runtime.InteropServices;
5. using System;
6. using UnityEngine.UI;
7.  
8. public class Freedom : MonoBehaviour {
9.    [DllImport ("jni")]
10.    private static extern float add(float x, float y);
11.  
12.    [DllImport ("jni")]
13.    private static extern int xint(int x, int y);
14.  
15.    int test = 2;
16.    float addme = 99.25f;
17.  
18.    public Transform passedvalue;
19.    public Transform passedvalue2;
20.  
21.    // Use this for initialization
22.    void Start () {
23.  
24.    }
25.  
26. //linked to a Unity 4.6 button
27.    public void youclikedme(){
28.  
29.  
30.  
31.      addme = add (addme,addme);
32.      passedvalue.GetComponent<Text>().text = addme + "";
33.  
34.      test = xint (test,44); //works
35.      passedvalue2.GetComponent<Text>().text = test + "";
36.  
37.    }
38.  
39.    // Update is called once per frame
40.    void Update () {
41.  
42.    }
43. }
44.  

 

Please use 'code' tags to format your code in your post to a more readable format.

 

That's float drift. The "-43" on the end is shorthand for scientific notation "x 10 ^ -43". So you've got a number which is effectively zero, but is not being stored as actual 0 for some reason.

 

Yeah i figured it out once i took a break.. the mostly likely cause for the problem occurred to me and I checked and it was just the case.

float add(float a, float b)

Got so exhausted trying to figure out why jfloat and jint was return weird numbers. I think u dont use those unless you want to communicate with java.

To top that of all missing eclipse Ant build options, multiple ant sdk setup issues, jdk updates, missing system variables. When i was testing with a java build which i wont use for now.

Anyway I hope this might be useful for other people I think most of the C tutorials out there are too complex or incomplete (they dont have enough code to let you recompile the C files), or needs some annoying ant build to get it working.

Beyond that be nice if you could actually run these directly in the Unity Editor. I compiled 50 unity apks across many different projects to get something working.

 

I think this is a unity bug. The transform components have this problem too so I wouldn't be surprised. Its been there since 4.6 if you have an older version of unity like 4.3 try the plug in there and I am willing to bet it works just fine.

 

Oh crap yeah, that is true >.< I usually have my scanner eyes checking lol. But anyways if you do happen to get a weird number with floats its unity being unity. I have had issues with floating points too only in 4.6 and higher.

 

Which part? Float drift is a fundamental issue with the way floating point numbers are implemented in computing, it's not specific to Unity.

 

No not float drift, if you use the 4.6+ you will notice float values can sometimes act strange. Not sure if anyone else has encountered this issue.

 

What kind of "strange"?

 

@Polymorphik - no bug here.

The result, as OP even pointed out, was that their C-function was returning an int, but the C#-function was wrapped to return a float.

The C-function converted its float to an int before returning. So the raw binary data sent back was formatted as an int.

That 32-bit information then gets converted to float on the C# side. This data isn't interpretted as int->float conversion. It thinks the int data IS a float. So it just reads the binary data as a float.

Unless I'm misinterpreting what you're saying... what 'strangeness'?

 

In editor scripts I build, the float field will display a number very close to zero but not zero. This happens regularly when the previous value was not zero and was changed using a handler. Try changing the float fields in 4.6 using the slider and you will see what I mean.

 

What makes you so sure it's not float drift?

 

That's just float drift, it's not unique to Unity 4.6.