Gideros 2019.12 released

MoKaLux · December 2019

thank you for the reply. Are you using windows as well?
I let the browser load the app for a least 10 mins but nothing, like an infinite loop.

hgy29 · December 2019

Yes on windows. Btw the web player on the wiki is 2019.12, so yes it works, however some calls are very slow. I identified texture loading as being one of the slow things, in particular when caching ttfont. I’ll investigate next year, for now Merry Christmas to you all!

MoKaLux · December 2019

I think I found my errors! I was missing two plugins harfbuzz and json

The problem here is that the new gideros didn't throw any errors with those valuable infos. I had to use previous gideros to have the errors in plain:
"json is missing line 35..."

SinisterSoft · January 2020

You need to add the plugins to the project. Right click the plugin text on the project file tree.

MoKaLux · January 2020

@SinisterSoft I did that but for me I can't export to html5. It seems to be broken.

MoKaLux · January 2020

@SinisterSoft I did that but for me I can't export to html5. It seems to be broken.

hgy29 · January 2020

FYI there is a 2019.12.1 version of Gideros available, with a few fixes, in particular for HTML5.

hgy29 · January 2020

oleg said:
@hgy29
I found an error in the formula instead of '-y' should be replaced by 'y'

@oleg, I double checked and heading value is correct on all the android phones I have, and consistent with what an iPhone gives too, that is heading=0 when I face the north and heading=90 when I face the east.

MoKaLux · January 2020

I am sorry to tell but html5 export doesn't work for me. Html5 export works for me in previous gideros (prior to 2019.12).

hgy29 · January 2020

@MoKaLux do you use compression with html5 ? if not can you try ?

MoKaLux · January 2020

good news that worked @hgy29 I am so happy, thank you very much

.
I never used the compression before because of the warning: higher memory usage during loading

but it seems to run faster than before so I am going to compress html5 from now on.

hgy29 · January 2020

great! so now I just have to fiure out why uncompressed mode no longer works. Actually I always use compression, since it adds another layer of obfuscation

MoKaLux · January 2020

hgy29 said:
great! so now I just have to fiure out why uncompressed mode no longer works. Actually I always use compression, since it adds another layer of obfuscation

Don't worry too much, you can make it to always compress if you like?

oleg · January 2020

hgy29 said:

oleg said:
@hgy29
I found an error in the formula instead of '-y' should be replaced by 'y'
@oleg, I double checked and heading value is correct on all the android phones I have, and consistent with what an iPhone gives too, that is heading=0 when I face the north and heading=90 when I face the east.

This is not an argument!

Try changing the formula like I said and checking the modified formula on your devices.
-Do not use GPS data, but only using magnetic sensor data!
-Remove the cover (case) from the phone - it may have magnets to automatically turn off the screen.

I have tested both formulas, the old formula does not always show incorrectly, it shows incorrectly depending on the position of the phone. The new formula always shows the correct result

ps/ I'm not mistaken! Or in different phones the axes of the magnetic sensors have been changed
in that case it is more logical to put "y" instead of "-y"

hgy29 · January 2020

Okay, I did more tests and an in fact magnetic data on android is very very noisy... I am wondering if my phones even have a magnetic sensor TBH. I agree that, in theory, the original formula doesn't seem right, but your doesn't seem right either, so I am not sure what to think yet. I would have done just "atan2(x,y)", without adding pi. I googled a bit and it look like it should have been right: https://arduino.stackexchange.com/questions/18625/converting-three-axis-magnetometer-to-degrees

Could it really be that different phones have different axis ????

hgy29 · January 2020

It seems that computing true heading is not as easy as using magnetic field, because it depends on where on earth you are (and that may be explaining why we don't see the same results). But I have few pointers here: https://stackoverflow.com/questions/42200059/calculate-true-heading-correctly-in-android

SinisterSoft · January 2020

on a side note, just so people know...

In the new 2019.12.1 there are two new plugins:
easing and scenemanager

So you don't need to include the sources for those in your code anymore, just require them if you want them, eg:

require "easing"
require "scenemanager"

Don't forget to add them in the project plugins too.

This makes it much easier for us to make demos that include easing and scenemanager functions - I'll be posting an example later today of some skeleton game code that has menus controlled by touch, mouse, keyboard or gamepad controller.

MoKaLux · January 2020

the new gideros update looks awesome, thank you for your hard work @hgy29

Viva Gideros!

oleg · January 2020

hgy29 said:
It seems that computing true heading is not as easy as using magnetic field, because it depends on where on earth you are (and that may be explaining why we don't see the same results). But I have few pointers here: https://stackoverflow.com/questions/42200059/calculate-true-heading-correctly-in-android

I managed to get a very stable operation of the compass on android, without the noise and rotation of the phone - with the same formula as I said

Magnetic sensors are not available on all phones, it is very easy to check, you can swipe the magnet from the bottom of the phone from the bottom up and the phone should switch off

Or you can use the program:
https://play.google.com/store/apps/details?id=com.cpuid.cpu_z

"It seems that computing true heading is not as easy as using magnetic field, because it depends on where on earth you are "

-
There is a difference between the upper and lower hemispheres of the earth - in Australia the magnetic field will point to the sky, and in Europe the magnetic field will point to the earth, but the direction of the pole will be indicated equally in Australia and Europe.

" I would have done just "atan2(x,y)", without adding pi."

- You are right if you keep the phone parallel to the ground, but the number pi is required to calculate the correction to rotate the phone relative to the ground. - instead of the number pi, you can use the accelerometer sensor to make a correction.

" but your doesn't seem right either, so I am not sure what to think yet."

If we compare 2 formulas - which is now: 'A' - then it is not logical that the y-axis is expanded. Logical option 'b'

a)Math.atan2(x, -y) + Math.PI) * (180 / Math.PI);
 
b)Math.atan2(x, y) + Math.PI) * (180 / Math.PI);

--And option 'B' works - on all my devices. And it works better than all the compass apps available in the Google Play Store I tested

oleg · January 2020

SinisterSoft · January 2020

Here is the skeleton game code I mentioned earlier, it needs the latest Gideros:
http://forum.giderosmobile.com/discussion/7975/skeleton-game-code?new=1

hgy29 · January 2020

oleg said:

Magnetic sensors are not available on all phones.

I know they aren't, but Gideros heading API only check magnetic sensor (at least on Android). If I get values, then the magnetic sensor must be present. Not sure about calibration though.

oleg said:

There is a difference between the upper and lower hemispheres of the earth - in Australia the magnetic field will point to the sky, and in Europe the magnetic field will point to the earth, but the direction of the pole will be indicated equally in Australia and Europe.

It is a bit more complex than that, magnetic field does not always point to 'true north'. In france it is almost true north, in ukraine you'll get a 10° offset, and so on. You can see the full map here: https://upload.wikimedia.org/wikipedia/commons/1/11/World_Magnetic_Declination_2015.pdf
Of course if you are only interested in magnetic north as opposed to true north, then you don't need to care. For a mapping applications, true north is certainly better.

oleg said:

- You are right if you keep the phone parallel to the ground, but the number pi is required to calculate the correction to rotate the phone relative to the ground.
- instead of the number pi, you can use the accelerometer sensor to make a correction.

I agree that accelerometer should be used, but I can't see any logic in adding 180° to account for non parallelism to ground. Adding a constant offset would just correct for application orientation, if different from the sensor orientation. In android, magnetic sensor axis are supposed to match the phone axis in its standard orientation, which is supposed to be portrait, although not clearly stated (https://developer.android.com/reference/android/hardware/SensorEvent). If the phone is not held strictly horizontally, then the 'z' component of the magnetic field should be used in our computation, which we never do.

oleg said:

--And option 'B' works - on all my devices. And it works better than all the compass apps available in the Google Play Store I tested

I don't deny that current option is wrong in theory, and that yours is more logical, but adding that 180° offset shouldn't be needed. I am ok to reverse the sign of y, but unless you can explain me why that 180° offset is needed in theory, I'll keep feeling that we missed something. I'd rather do it right once and for all, that's all.

oleg · January 2020

"It is a bit more complex than that, magnetic field does not always point to 'true north'. In france it is almost true north, in ukraine you'll get a 10° offset, and so on. You can see the full map here: https://upload.wikimedia.org/wikipedia/commons/1/11/World_Magnetic_Declination_2015.pdf
Of course if you are only interested in magnetic north as opposed to true north, then you don't need to care. For a mapping applications, true north is certainly better."

The compass is not designed to show the axis of the earth
The compass is designed to show a magnetic pole - and it shows a magnetic pole without displacement

It doesn't matter where the magnetic pole is - it's just a reference point for azimuth calculation

"I agree that accelerometer should be used, but I can't see any logic in adding 180° to account for non parallelism to ground. Adding a constant offset would just correct for application orientation, if different from the sensor orientation. In android, magnetic sensor axis are supposed to match the phone axis in its standard orientation, which is supposed to be portrait, although not clearly stated (https://developer.android.com/reference/android/hardware/SensorEvent). If the phone is not held strictly horizontally, then the 'z' component of the magnetic field should be used in our computation, which we never do."

Imagine that a compass is a 3d sphere that is rotated by its pole to a magnetic pole.
We need to make a 3d sphere projection on a 2d image
To do this we need to calculate the rotation of the sphere along the X axis and the Y axis
This formula is described in Wikipedia, I cannot mention the title of the article because I have read a lot of articles on this topic

I am ok to reverse the sign of y, but unless you can explain me why that 180° offset is needed in theory, I'll keep feeling that we missed something.

hgy29 · January 2020

oleg said:

It doesn't matter where the magnetic pole is - it's just a reference point for azimuth calculation

Gideros is supposed to give both the magnetic heading and the true heading, I understand you are not interested in true heading, but for completeness it should be computed, and by the way I need it for my apps more than magnetic heading.

oleg said:

We need to make a 3d sphere projection on a 2d image

Actually I pretty much know how this is supposed to be done, and I still don't see any justification to the pi / 180° offset. The link I posted earlier about guys wondering how this should be done on stackoverflow give the same results as my own maths did. So I probably miss something, like android reversing some axis or having another convention, I just can't figure out why this had do be done. Without further explanation I will change the formula in gideros code, but I really like to understand what I do!

oleg · January 2020

Gideros is supposed to give both the magnetic heading and the true heading, I understand you are not interested in true heading, but for completeness it should be computed, and by the way I need it for my apps more than magnetic heading.

I do not understand you, I did not say that only magnetic data should be given, I said that 'only the magnetic sensor data should be used to verify the correctness of the formula'
Because the formula is about a magnetic sensor

Actually I pretty much know how this is supposed to be done, and I still don't see any justification to the pi / 180° offset. The link I posted earlier about guys wondering how this should be done on stackoverflow give the same results as my own maths did. So I probably miss something, like android reversing some axis or having another convention, I just can't figure out why this had do be done. Without further explanation I will change the formula in gideros code, but I really like to understand what I do!

180/pi -In order to translate radians to degrees

hgy29 · January 2020

I am not questioning the radian to degree conversion, but the pi offset added to the arctan() result:
double magneticHeading = (Math.atan2(x, y) + Math.PI) * (180 / Math.PI);

oleg · January 2020

hgy29 said:
I am not questioning the radian to degree conversion, but the pi offset added to the arctan() result:
double magneticHeading = (Math.atan2(x, y) + Math.PI) * (180 / Math.PI);

https://dustinpfister.github.io/2019/03/19/js-math-atan2/

hgy29 · January 2020

oleg said:

https://dustinpfister.github.io/2019/03/19/js-math-atan2/

Understood, but we are in the single point case here, since the origin is ourselves and the only point we have is the magnetic direction, so the pi addition doesn't apply.

oleg · January 2020

hgy29 said:

oleg said:

https://dustinpfister.github.io/2019/03/19/js-math-atan2/
Understood, but we are in the single point case here, since the origin is ourselves and the only point we have is the magnetic direction, so the pi addition doesn't apply.

Understood, but we are in the single point case here, since the origin is ourselves and the only point we have is the magnetic direction, so the pi addition doesn't apply.

The best way out would be to make the compass 3 arrows of 3m different formulas and test their behavior

a) magneticHeading = (math.atan2(fx, fy) + math.pi) * (180 / math.pi);
b)	 magneticHeading2 = (math.atan2(fx, fy)) * (180 / math.pi);
c)	 magneticHeading3 = (math.atan2(fx, -fy) + math.pi) * (180 / math.pi);

Only formula (A) gives correct readings
Formula (b) points in the opposite direction

--If screen rotation is enabled on the phone - formula b does not work and formula a is working correctly

hgy29 · January 2020

I made a lots of tests and implemented true heading computation as well as full 3D heading/azimuth computation according to android source (it means no longer self math and atan, android functions are called instead to do the job). What comes out:
1° My compasses were not properly calibrated, I fixed that
2° Original Gideros function (atan2(x,-y)+180°) to compute magnetic heading was correct on my phones (it gives the same result as google functions, and the results are correct in practice)
3° Changing it to (atan2(x,y)+180°) as suggested by @oleg gives incorrect results
4° Making it just atan2(x,y) as suggested by me is incorrect too
5° Using atan2(-x,y) gives correct results (that's logical, if 2° works)

This leads me into thinking that magnetometer placement isn't what I expected by reading the docs, and maybe even not consistent across devices. If we suppose that this is the case, and that, hopefully, accelerometer is still always placed in the same orientation as the magnetometer (as required per android specs), then using google functions which correlate accelerometer to magnetometer may fix it (I am not sure actually)...

I tested with gideros compass example, on samsung A3 and A70.

Howdy, Stranger!

Categories

In this Discussion

Top Posters

Gideros 2019.12 released

Comments

Howdy, Stranger!

Quick Links

Categories

In this Discussion

Top Posters

Gideros 2019.12 released

Comments