GLBasic forum

Main forum => Announcements => Topic started by: Kitty Hello on 2019-Jun-29

Title: New Version - Android Support
Post by: Kitty Hello on 2019-Jun-29
Live on Steam as an update now :)
Title: Re: New Version - Android Support
Post by: MrPlow on 2019-Jun-29
Excellent! Are there docs on how this works with Android Studio etc?
Title: Re: New Version - Android Support
Post by: bigsofty on 2019-Jul-01
Quote from: Kitty Hello on 2019-Jun-29
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:
Title: Re: New Version - Android Support
Post by: erico on 2019-Jul-01
Great! will soon check it out, I have to make a review too, will do so on this version! :booze:
Title: Re: New Version - Android Support
Post by: bigsofty 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.
Title: Re: New Version - Android Support
Post by: kirkdev 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?

Title: Re: New Version - Android Support
Post by: Qedo on 2019-Jul-06
does the file exist?
look in C:\Program Files (x86)\Steam\steamapps\common\GLBasic_SDK
Title: Re: New Version - Android Support
Post by: kirkdev on 2019-Jul-06
Yes that file does exist in the directory.
Title: Re: New Version - Android Support
Post by: MrPlow on 2019-Jul-06
Maybe an environment variable is not properly setup?
Title: Re: New Version - Android Support
Post by: Qedo 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.
Title: Re: New Version - Android Support
Post by: spacefractal on 2019-Jul-08
Quote from: bigsofty 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.

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.
Title: Re: New Version - Android Support
Post by: bigsofty on 2019-Jul-08
Quote from: spacefractal on 2019-Jul-08
Quote from: bigsofty 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.

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
Title: Re: New Version - Android Support
Post by: spacefractal 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.


Title: Re: New Version - Android Support
Post by: MrPlow on 2019-Jul-09
Hey, this might sound silly but why didn't you create a *new* GLB command called KEYF() (Float)?



Title: Re: New Version - Android Support
Post by: spacefractal 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.

Title: Re: New Version - Android Support
Post by: bigsofty on 2019-Jul-17
Just a word to the wise, the Steam "Updates History" and the "Recent Updates" for Godot need updating. I think Android support could be an important addition for possible buyers. Also keeping "Updates History" updated should be a priority as it's the first place buyers look when buying software to see if the app is dead or not.

I don't mind lending a hand if need be.

BTW there are a few English grammar mistakes in the current Steam ad too.
Title: Re: New Version - Android Support
Post by: spacefractal on 2019-Oct-12
please note:

Android 5.X and below is not supported for Android Studio version of glbasic. The app can run, but you can run into issues. Etc PNG, JPG and SOUND is not working for those platforms. This is property due change of a newer compiler. Im have not seen issues with Android 6 throught, but if you see glbasic bugs in those Android versions, submit them :-).

API 23 is required.