DIV ARENA FORUMS

export apk file

josepgames - 14-2-2019 at 05:57 PM

Hi,

Is it possible with current build to export div games to .apk format? How can we play games at andorid otherwise? I've been looking through the menues but found no option.

Thanks!

CicTec - 14-2-2019 at 08:00 PM

Hi josepgames,

Mike has published some APK of example games, however I do not see options to generate APK inside the IDE, maybe he can give you more details.

MikeDX - 15-2-2019 at 10:43 AM

One of my versions had a batch file to export to APK but needed to be signed. I ditched it in favour of having a "div store" with peoples published games, but it never took off due to resources issues.

I can see if i can find the original batch files too. It builds each platform individually, but again, that was started to be transfered to docker for easy platform stuff but resources ran out.

If anyone wants to help me get these finished, please feel free to let me know!

MikeDX - 15-2-2019 at 10:55 AM

There is a work in progress batch script in tools called makedroid.bat which uses the android sdk and the DIV compiler to make an apk.

You may need an original APK to begin with though, which i usually compile with c4droid

The whole process needs to be documented, but it does work!

CicTec - 15-2-2019 at 11:30 AM

Quote: Originally posted by MikeDX  
There is a work in progress batch script in tools called makedroid.bat which uses the android sdk and the DIV compiler to make an apk.

You may need an original APK to begin with though, which i usually compile with c4droid

The whole process needs to be documented, but it does work!

Mike, DIV supports the classic touch system for systems like Android / iOS ?, because I do not see any of this in the code, and without this input system, porting does not have much use.

MikeDX - 15-2-2019 at 11:36 AM

The porting is for the games, but yes it does support touch and the apks have on screen joypad and keyboard.

I've written, built and exported div games directly from my phone and tablet before and it works well. There are a lot of example apk files that work great.

CicTec - 15-2-2019 at 02:55 PM

Well, could you tell me where is the code of the touch support and the input system in general for Android/iOS? I can not find.

MikeDX - 15-2-2019 at 06:05 PM

div android compiles as C/SDL on native android. It uses the same SDL_* drivers

CicTec - 15-2-2019 at 06:28 PM

Yes ok, but in the version of SDL2 there is a specific API for the management of fingers and touch of the touch screen:
https://wiki.libsdl.org/SDL_TouchFingerEvent?highlight=%28%5...
https://wiki.libsdl.org/SDL_Finger?highlight=%28%5CbCategory...

I can not see any code that uses this for system management, maybe you've used another API or a version of SDL lower than 2.0?

MikeDX - 15-2-2019 at 07:12 PM

We use SDL 1.3 which is API compatible to SDL 1.2 but a more free license.

Since we dont support multiple input gestures and want to stay platform agnostic, we stick to mouse inputs which are emulated as touch inputs on phones/tablets

Actually the android build was a long time ago!

CicTec - 15-2-2019 at 07:27 PM

ah ok, this explains the non-presence of the code, is managed in emulation by the keyboard and mouse APIs.

Yes, the porting is ancient, however the new API offers for what I see a better support, to solve even problems such as keeping separate the keyboard and mouse support, which today may be physical hardware attached to the device, if for example this it's a tablet.

[Edited on 15-2-2019 by CicTec]

MikeDX - 15-2-2019 at 07:41 PM

the android driver has on screen keyboard and joystick

it supports USB keyboard over OTG.

I doubt the new SDL 2.X will be better for what we do, although DIV happily compiles under both

CicTec - 15-2-2019 at 07:51 PM

Yes, in the emulation in the touch screen are supported, in fact the first build of SDL 2.0 supported only this, but later was introduced this new API that I have indicated, because the one in emulation caused some problems and limitations, even if it is still supported for backward compatibility.

I could try the new API and I can say that actually is an improvement compared to using the one in emulation and also it is necessary.

Think for example to a strategy game performed on a tablet (Age Of Empire style) is much more convenient to support physical keyboard and mouse instead of emulated on the screen, this is one of the reasons why they have added this new API and it would be optimal for us to add this support in DIVDX in the future.

MikeDX - 15-2-2019 at 09:47 PM

I dont think you understand


The current android build supports physical and on screen keyboards

supports real gamepads as well as on screen touch


CicTec - 15-2-2019 at 10:52 PM

Yes, I understand it, but the new API has features that the old does not contain and allows better separation of hardware, etc ..., so it would be a good idea to add this support in the future.

MikeDX - 16-2-2019 at 02:55 PM

Sorry, that came across wrong.

I mean i dont think you understand the way the android build works (or more importantly the way the SDL 1.3 core works for android).

Feel free to take a look though. I'm going to be revisiting the div code soon to support 100+ network players via a nodejs server



CicTec - 16-2-2019 at 05:41 PM

Quote: Originally posted by MikeDX  
Sorry, that came across wrong.

I mean i dont think you understand the way the android build works (or more importantly the way the SDL 1.3 core works for android).

Feel free to take a look though.

Yes, I understand it, I've done build and test with the SDL 2.0 and earlier version for android, so I suggest that it's a good idea to use the new API, features and improvements are significant compared to previous versions, I do not say that the current version used is not good, simply the new one is better and offers more things.

Quote: Originally posted by MikeDX  

I'm going to be revisiting the div code soon to support 100+ network players via a nodejs server

Good news, I do not know if you already have some idea or what changes or additions of code will involve adding this support and if it is not the case before inserting this to carry out the planning for rewriting the codebase.