GLBasic & Android?

[MrTAToad]

Unfortunately, until C/C++ support is setup for Windows, I dont see it being feasible.

[monono]

I´ll have the HTC Tattoo from my brother soon. He is going to update on the Legend. I have played around with it for a while. It´s amazing. Even the hardcore-applemaniacs in my peer go for android. There are coming harsh times for apple. Compare the prices for what you get and a thing called 'freedom' (I have to admit the iPhone is an awesome gadget without it). First time for years I am looking into java again. And yes: it sucks! Never liked it.

So we have to wait for a decent android c compiler. In the meantime, I hope that the iPhone is getting cheaper. Good to have a real competition here.

[Darmakwolf]

Interesting find: http://developer.android.com/sdk/ndk/index.html
Gernot, is there any way GLBasic could wrap around the SDK and compile a C program for Android? I am getting an HTC Droid Incredible soon from Verizon. I understand it uses interpreted Java by default, but this SDK permits the use of C in the program. It's likely that it would still require a small java applet to launch the program, but that could be built into the compiler and be generated automatically. Is there even the slightest possibility of this??

[codegit]

I have an HTC Desire (1ghz processor) and it is brilliant. 

http://www.htc.com/www/product/desire/overview.html

[MrTAToad]

Gernot, is there any way GLBasic could wrap around the SDK and compile a C program for Android?

I posted about this before - if you want to use C with Android, you have to use a non-Windows machine, as the library files are in a name format only really suitable for Linux.

See http://www.aton.com/android-software-development-tools-what-do-i-need/

[Kitty Hello]

Thing is - I don't have an Android device. And they are not cheap. And I don't know for sure if it will work in the end. I don't see a big problem with C/C++ and the NDK, though.

Is there an emulator I could use? Or does anyone have a spare unit? Donation fond?

[Slydog]

Android emulator:
http://developer.android.com/guide/developing/tools/emulator.html

As for Androids having difference specs, I don't see that as a big problem.
Screen size / orientation is simple.
Just code your elements to be relative to an anchor (top, top-left, bottom-right, top-center), plus perhaps a pixel offset.
So, no matter what size screen or orientation, you score is always bottom-right, for example.
You just need a 'ConvertAnchorToScreenCoordinates()' function.

Same as game content.  A tile map would be easy, just pre-calculate the number of tiles down and across, etc.

But I see the problem with various input methods: keyboard, single touch, multi-touch, etc.
You would have to create a custom library to account for it all.
Use this in your game initialization:

Code: (glbasic) [Select]

IF Device.HasKeyboard()
  Input.EventAdd_Keyboard("Fire", kAscii_Space)
//ELSEIF Device.IsMultitouch()
ELSEIF Device.IsTouch()
  Input.EventAdd_TouchPoint("Fire", 100, 200)
ELSE
  Input.EventAdd_HWButton("Fire", kHardwareButton_3)
ENDIF
This code (ha, I just made that all up, sure to have logic/bug problems) will setup a 'Fire' event that could be called anywhere in your game logic and would work for any device, iPhone, Computer, etc, such as:

Code: (glbasic) [Select]

IF Input.IsEvent("Fire") THEN . . .
It would be better (faster) to use constants instead of strings for event names, instead of "Fire", use kEvent_Fire, but you get the idea.

The 'Input.IsEvent' code would then handle the device specific checking as initialized earlier.
This keeps your game logic clean and device independent.
But since I've never done this, I'm sure there may be hurdles I can't predict yet.

I'm starting this soon for my own project, using compiler directives.
... If iPhone then rotate means tilting, else rotate means analog stick movement, etc.
(Input.AxisAdd_Tilt("Rotate", "XAxis"), or Input.AxisAdd_Joystick("Analog2.XAxis")    maybe)
view_x = Input.GetAxis("Rotate") (or something)
So testing on the PC versus the iPhone won't require any extra thought/changes.

[Edit]
This could also allow for more than one input method on the SAME device.  Add a touch point AND keyboard key to both trigger a 'Fire' event.

[Darmakwolf]

With the emulator, it would be possible to at least see if it's going to be doable in the least. (GLB for Android, that is.) If you would like, I can try any prototypes/betas you would like on my actual Droid Incredible. I'm sure the many Android people would L O V E for this to happen. In fact, I'd pay for a special version of GLB that only compiled for Android. xD
As for the emulator, you can load custom binaries but they need to be packed into a .APK format, which I do not know how to make myself but the SDK can pack binaries into APKs, then you just send them to the emulator via command prompt in windows. I tested out the Gensoid emulator on the emulator that way.

[MrTAToad]

Unfortunately I dont see it being possible as there is no compiler for Windows

[Darmakwolf]

This guy did it. http://forum.openhandsetdevelopers.com/android-application-in-c-yes-t13.html - not to mention the C bits can be done within Eclipse for windows apparently too. It's looking less and less impossible, MrTAToad

[MrTAToad]

That looks like Linux stuff - if not, how did he get around the header problems ?  Or is he just using standard C routines ?

As far as I know the C bits cant be done in Eclipse on Windows unless you want to rename loads of files - unless the NDK has be radically updated for Windows (which even the Android site doesn't mention).

Also see my previous link about a companies attempt to get it going in Windows, specifically :

We used Ubuntu to obtain the Android source tree, which included the run time libraries and associated headers.  We wanted to run the cross tool chain from Windows, but almost immediately ran into two significant roadblocks:

    * One was that a few dozen of the files whose names differed only in case.  Windows file names, by default, ignore letter case in names, whereas for Linux/Unix file names, case makes a difference.  Copying the files to Windows generates files with duplicate names.
    * The second roadblock is that the header files are organized in a different manner than expected by a GNU tool chain.  Both of these roadblocks could be overcome, but the amount of time and effort to do so was deemed prohibitive.

I wouldn't say its impossible - just incredibly hard and time consuming.

Oh, and apparently using C with Android prevents you from accessing various functions too :

http://www.zdnet.com/blog/burnette/program-for-android-in-cc-with-the-native-development-kit-if-you-dare/1284

Keep in mind that using the NDK will not be relevant for all Android applications. As a developer, you will need to balance its benefits against its drawbacks, which are numerous! Your application will be more complicated, have reduced compatibility, have no access to framework APIs, and be harder to debug. That said, some applications that have self-contained, CPU-intensive operations that don’t allocate much memory may still benefit from increased performance and the ability to reuse existing code. Some examples are signal processing, intensive physics simulations, and some kinds of data processing.

The Google answer on running C/C++ applications on Android from the FAQs is : “No. Android applications are written using the Java programming language”. Very simple answer, but the problem here is for developers and companies having ready to use code and applications for other mobile platform and looking to get their code ported to Android at low cost.