Quick Links: Download Gideros Studio | Gideros Documentation | Gideros Development Center | Gideros community chat
Gideros 2019.12 released - Page 2 - Gideros Forum

Gideros 2019.12 released

2

Comments

  • 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.
    my growING GIDEROS github repositories: https://github.com/mokalux?tab=repositories
  • hgy29hgy29 Maintainer
    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!

    Likes: MoKaLux

    +1 -1 (+1 / -0 ) Share on Facebook
  • 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..."
    my growING GIDEROS github repositories: https://github.com/mokalux?tab=repositories
  • SinisterSoftSinisterSoft Maintainer
    You need to add the plugins to the project. Right click the plugin text on the project file tree.


    2020-01-07_08-14-20.png
    910 x 515 - 66K
    Coder, video game industry veteran (since the '80s, ❤'s assembler), arrested - never convicted hacker (in the '90s), dad of five, he/him (if that even matters!).
    https://deluxepixel.com
  • @SinisterSoft I did that but for me I can't export to html5. It seems to be broken.
    my growING GIDEROS github repositories: https://github.com/mokalux?tab=repositories
  • @SinisterSoft I did that but for me I can't export to html5. It seems to be broken.
    my growING GIDEROS github repositories: https://github.com/mokalux?tab=repositories
  • hgy29hgy29 Maintainer
    FYI there is a 2019.12.1 version of Gideros available, with a few fixes, in particular for HTML5.
    +1 -1 (+3 / -0 ) Share on Facebook
  • hgy29hgy29 Maintainer
    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.

  • 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). :'(
    my growING GIDEROS github repositories: https://github.com/mokalux?tab=repositories
  • hgy29hgy29 Maintainer
    @MoKaLux do you use compression with html5 ? if not can you try ?

    Likes: MoKaLux

    +1 -1 (+1 / -0 ) Share on Facebook
  • MoKaLuxMoKaLux Member
    edited January 7
    :) good news that worked @hgy29 I am so happy, thank you very much <3.
    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.
    my growING GIDEROS github repositories: https://github.com/mokalux?tab=repositories
  • hgy29hgy29 Maintainer
    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 :)
  • MoKaLuxMoKaLux Member
    edited January 7
    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?
    my growING GIDEROS github repositories: https://github.com/mokalux?tab=repositories
  • olegoleg Member
    edited January 7
    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"
    my games:
    https://play.google.com/store/apps/developer?id=razorback456
    мій блог по гідерос https://simartinfo.blogspot.com
    Слава Україні!
  • hgy29hgy29 Maintainer
    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 ????
  • hgy29hgy29 Maintainer
    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

    Likes: MoKaLux

    +1 -1 (+1 / -0 ) Share on Facebook
  • SinisterSoftSinisterSoft Maintainer
    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.

    Likes: MoKaLux, plicatibu

    Coder, video game industry veteran (since the '80s, ❤'s assembler), arrested - never convicted hacker (in the '90s), dad of five, he/him (if that even matters!).
    https://deluxepixel.com
    +1 -1 (+2 / -0 ) Share on Facebook
  • the new gideros update looks awesome, thank you for your hard work @hgy29 <3

    Viva Gideros!
    my growING GIDEROS github repositories: https://github.com/mokalux?tab=repositories
  • olegoleg Member
    edited January 7
    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

    Likes: antix, MoKaLux

    my games:
    https://play.google.com/store/apps/developer?id=razorback456
    мій блог по гідерос https://simartinfo.blogspot.com
    Слава Україні!
    +1 -1 (+2 / -0 ) Share on Facebook
  • olegoleg Member

    image.png
    481 x 340 - 183K
    my games:
    https://play.google.com/store/apps/developer?id=razorback456
    мій блог по гідерос https://simartinfo.blogspot.com
    Слава Україні!
  • SinisterSoftSinisterSoft Maintainer
    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
    Coder, video game industry veteran (since the '80s, ❤'s assembler), arrested - never convicted hacker (in the '90s), dad of five, he/him (if that even matters!).
    https://deluxepixel.com
  • hgy29hgy29 Maintainer
    edited January 8
    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.

    Likes: SinisterSoft

    +1 -1 (+1 / -0 ) Share on Facebook
  • olegoleg Member
    edited January 8
    "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.
    image
    111.PNG
    347 x 149 - 10K
    my games:
    https://play.google.com/store/apps/developer?id=razorback456
    мій блог по гідерос https://simartinfo.blogspot.com
    Слава Україні!
  • hgy29hgy29 Maintainer
    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!

  • olegoleg Member
    edited January 8
    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



    my games:
    https://play.google.com/store/apps/developer?id=razorback456
    мій блог по гідерос https://simartinfo.blogspot.com
    Слава Україні!
  • hgy29hgy29 Maintainer
    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);
  • olegoleg Member
    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);

    image

    https://dustinpfister.github.io/2019/03/19/js-math-atan2/
    my games:
    https://play.google.com/store/apps/developer?id=razorback456
    мій блог по гідерос https://simartinfo.blogspot.com
    Слава Україні!
  • hgy29hgy29 Maintainer
    oleg said:
    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.
  • olegoleg Member
    edited January 8
    hgy29 said:

    oleg said:
    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);
    image

    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
    333.PNG
    311 x 465 - 28K
    333.PNG 27.7K
    my games:
    https://play.google.com/store/apps/developer?id=razorback456
    мій блог по гідерос https://simartinfo.blogspot.com
    Слава Україні!
  • hgy29hgy29 Maintainer
    edited January 8
    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.

    Dislikes: oleg

    +1 -1 (+0 / -1 ) Share on Facebook
Sign In or Register to comment.