Author Topic: New Version - Android Support  (Read 373 times)

Offline Kitty Hello

  • code monkey
  • Administrator
  • Prof. Inline
  • *******
  • Posts: 10697
  • here on my island the sea says 'hello'
    • View Profile
    • http://www.glbasic.com
New Version - Android Support
« on: 2019-Jun-29 »
Live on Steam as an update now :)

Offline MrPlow

  • Prof. Inline
  • *****
  • Posts: 1456
    • View Profile
Re: New Version - Android Support
« Reply #1 on: 2019-Jun-29 »
Excellent! Are there docs on how this works with Android Studio etc?
Comp:
Speccy-48k, Speccy-128k, Amigas, PCs

Offline bigsofty

  • Community Developer
  • Prof. Inline
  • ******
  • Posts: 2616
    • View Profile
Re: New Version - Android Support
« Reply #2 on: 2019-Jul-01 »
Live on Steam as an update now :)
Well done everyone involved with this, I know Google made it more of a pain than it needed to be.  :happy:
Cheers,

Ian.

“It is practically impossible to teach good programming style to students that have had prior exposure to BASIC.  As potential programmers, they are mentally mutilated beyond hope of regeneration.”
(E. W. Dijkstra)

Offline erico

  • Community Developer
  • Prof. Inline
  • ******
  • Posts: 4187
    • View Profile
    • Portfolio
Re: New Version - Android Support
« Reply #3 on: 2019-Jul-01 »
Great! will soon check it out, I have to make a review too, will do so on this version! :booze:

Offline bigsofty

  • Community Developer
  • Prof. Inline
  • ******
  • Posts: 2616
    • View Profile
Re: New Version - Android Support
« Reply #4 on: 2019-Jul-01 »
Small bug introduced...   :(

KEY() now returns a real (DGint), before this new version is always returned a, integer (DGNat). The manual states that it returns an integer but it now returns a float instead. This kinda messes up my code that uses bit manipulation with the KEY() function TBH.

I could cast it temporarily but KEY() really should return only integers IMHO.
Cheers,

Ian.

“It is practically impossible to teach good programming style to students that have had prior exposure to BASIC.  As potential programmers, they are mentally mutilated beyond hope of regeneration.”
(E. W. Dijkstra)

Offline kirkdev

  • Mc. Print
  • *
  • Posts: 16
    • View Profile
Re: New Version - Android Support
« Reply #5 on: 2019-Jul-06 »
Hi guys,

Just done a fresh install from Steam. I am getting an issue "Fatal Error: HomePath.dll not found" any ideas?

Kirk

Offline Qedo

  • Mr. Polyvector
  • ***
  • Posts: 165
  • UNUS SED LEO
    • View Profile
Re: New Version - Android Support
« Reply #6 on: 2019-Jul-06 »
does the file exist?
look in C:\Program Files (x86)\Steam\steamapps\common\GLBasic_SDK

Offline kirkdev

  • Mc. Print
  • *
  • Posts: 16
    • View Profile
Re: New Version - Android Support
« Reply #7 on: 2019-Jul-06 »
Yes that file does exist in the directory.
Kirk

Offline MrPlow

  • Prof. Inline
  • *****
  • Posts: 1456
    • View Profile
Re: New Version - Android Support
« Reply #8 on: 2019-Jul-06 »
Maybe an environment variable is not properly setup?
Comp:
Speccy-48k, Speccy-128k, Amigas, PCs

Offline Qedo

  • Mr. Polyvector
  • ***
  • Posts: 165
  • UNUS SED LEO
    • View Profile
Re: New Version - Android Support
« Reply #9 on: 2019-Jul-07 »
i have tried to compile Android but don't work with GLBasic Version: 16.215
to you too?
Qedo

*** Configuration: ANDROID ***
precompiling:
GPC - GLBasic Precompiler V.15.394 SN:8e14b964 - 3D, NET
Wordcount:35 commands
compile+link:
*** create process failed
success
_______________________________________
*** Finished ***
Elapsed: 14.1 sec. Time: 19:49
Build: 1 succeeded.

Offline spacefractal

  • Community Developer
  • Prof. Inline
  • ******
  • Posts: 3611
    • View Profile
    • Space Fractal
Re: New Version - Android Support
« Reply #10 on: 2019-Jul-08 »
Small bug introduced...   :(

KEY() now returns a real (DGint), before this new version is always returned a, integer (DGNat). The manual states that it returns an integer but it now returns a float instead. This kinda messes up my code that uses bit manipulation with the KEY() function TBH.

I could cast it temporarily but KEY() really should return only integers IMHO.

Its on purpose, not a bug. Gamecontrollers is the issue. We do shall update the document.

The reason is the game controllers which some buttons returns a float, so you can support a game pad controller using KEY(). Game controllers is a hell to get right on Android and even the included joy() might mess up on some gamepads as they diddent propert support remapping. Even tilt is routed to KEY() as well.

So if you uses a one player that support gamepad, you should uses KEY() and do a remapping feature to make its would works in thier gamepad. Triggers and Right stick is often the issue which dont follow a standard and sometimes swapped.

But im do have in strings.xml make sure its does not return a float between 0-1, if you dont want that, but here you do require to set a deadzone throught.

But so if you want to support game controllers, dont do bit manipulation at all, if you want analoge support! But if you dont use the analoge feature, just disable it and its return either 0 or 1 as before, but just a float.
« Last Edit: 2019-Jul-08 by spacefractal »
Greedy Mouse - Karma Miwa - Spot Race - CatchOut - Android Extras - is on a vacation trip, home before end of few days in jan.

Offline bigsofty

  • Community Developer
  • Prof. Inline
  • ******
  • Posts: 2616
    • View Profile
Re: New Version - Android Support
« Reply #11 on: 2019-Jul-08 »
Small bug introduced...   :(

KEY() now returns a real (DGint), before this new version is always returned a, integer (DGNat). The manual states that it returns an integer but it now returns a float instead. This kinda messes up my code that uses bit manipulation with the KEY() function TBH.

I could cast it temporarily but KEY() really should return only integers IMHO.

Its on purpose, not a bug. Gamecontrollers is the issue. We do shall update the document.

The reason is the game controllers which some buttons returns a float, so you can support a game pad controller using KEY(). Game controllers is a hell to get right on Android and even the included joy() might mess up on some gamepads as they diddent propert support remapping. Even tilt is routed to KEY() as well.

So if you uses a one player that support gamepad, you should uses KEY() and do a remapping feature to make its would works in thier gamepad. Triggers and Right stick is often the issue which dont follow a standard and sometimes swapped.

But im do have in strings.xml make sure its does not return a float between 0-1, if you dont want that, but here you do require to set a deadzone throught.

But so if you want to support game controllers, dont do bit manipulation at all, if you want analoge support! But if you dont use the analoge feature, just disable it and its return either 0 or 1 as before, but just a float.

TBH this is not great news to me personally.

The KEY() integer problem was really for this bit of code...

Code: GLBasic [Select]
                INLINE
                        self.keys = KEY(200)|KEY(208)<<1)|(KEY(203)<<2)|(KEY(205)<<3)|(KEY(42)<<4)|(KEY(54)<<5)|(KEY(29)<<6)|(KEY(157)<<7);
                ENDINLINE

Not a biggie, I just cast those but I mentioned it cause it looked like a bug.

But I do have a large and extensive library for GamePads using the traditional GETJOYBUTTON, GETJOYX, GETJOYRX, GETDIGIX, GETJOYZ etc. to name but a few. It already handles, multiple GamePads, types(XBox 1, PS4 ect.), deadzones, remapping of game pads, analogue + digital input and gampad emulation via a keyboard/mouse.

I am feeling that to go down a different input route for Android input should not be the way to go. The GLB input API should be universal and not platform dependant, as it is already now. If there are back-end differences, then they should be emulated under the current API or extended via new commands that complement the current API.

Maybe I have the wrong end of the stick? I hope so.  TBH it probably wouldn't kill me at the end of the day I could rewrite my input code for Android. :S
Cheers,

Ian.

“It is practically impossible to teach good programming style to students that have had prior exposure to BASIC.  As potential programmers, they are mentally mutilated beyond hope of regeneration.”
(E. W. Dijkstra)

Offline spacefractal

  • Community Developer
  • Prof. Inline
  • ******
  • Posts: 3611
    • View Profile
    • Space Fractal
Re: New Version - Android Support
« Reply #12 on: 2019-Jul-09 »
The joy commands should works with Android. But sadly joypad on Android and windows is totally different. It's easy on windows, but annoying as hell on Android as they are more treated as keyboard and they does not follow a standard.

You can do still use integer througt, but then you can't use any analoge buttons with througt with using key.


« Last Edit: 2019-Jul-09 by spacefractal »
Greedy Mouse - Karma Miwa - Spot Race - CatchOut - Android Extras - is on a vacation trip, home before end of few days in jan.

Offline MrPlow

  • Prof. Inline
  • *****
  • Posts: 1456
    • View Profile
Re: New Version - Android Support
« Reply #13 on: 2019-Jul-09 »
Hey, this might sound silly but why didn't you create a *new* GLB command called KEYF() (Float)?



Comp:
Speccy-48k, Speccy-128k, Amigas, PCs

Offline spacefractal

  • Community Developer
  • Prof. Inline
  • ******
  • Posts: 3611
    • View Profile
    • Space Fractal
Re: New Version - Android Support
« Reply #14 on: 2019-Jul-09 »
Sorry for multply edits.

No reason. You can disable and enable the analoge, but instead using deadzone in strings.xml, and its disabled by default and eventuelly using deadzone by the analoge buttons/sticks.

Also dont forget to add a remapping feautere to your Android game using KEY() as well! Its important. You cannot support all controllers using JOY(), as far from all controller follow the Google Layout standard (this is the way SDL joystick code works). So if a controller does not working or working correctly by using a JOY command, they might required to been remapped using KEY() instead. Also some buttons might return two values, here use the highest one.

Only Ouya controllers has been auto remapped to follow the standard google layout from controllers that doesent follow it. PS4 example does follow it and no remapping is required. Im can add more and only require one line of code to auto remapping a controller to the JOY() commands.

If you have game controller and you want me to auto remap it. Let me know which values the various button returns.

PS. The description im have set in strings.xml is also wrong. Im update in one of the next update, but as im wrote, its disabled by default.

« Last Edit: 2019-Jul-09 by spacefractal »
Greedy Mouse - Karma Miwa - Spot Race - CatchOut - Android Extras - is on a vacation trip, home before end of few days in jan.