State of the attempt to natively port love to android

[T-Bone]

I don't mind about double posts
Anyway, I checked the code and we actually do only create events for "finger touches screen" (ACTION_DOWN) and "finger leaves screen" (ACTION_UP). Everything between those two events is totally random at the moment.

What do you mean by "totally random"? What happens is that mousepressed and mousereleased are called at those, and only those, times. And in between, love.mouse.isDown('l') returns true, just like it should. In my game however, something that should happen when you hold the "mouse" down doesn't happen, but it is not because of this. I am currently trying to identify the specific issue.

Also, I noticed that framebuffers don't work. No biggie but good to know.

And another thing. Somebody seriously have to do something about stability. On my phone, love-native-android starts properly maybe once every 20 starts. It's getting annoying.

EDIT: I can now confirm that both love.mousepressed and love.mousereleased work excactly as they should, the error lies elsewhere. Prior to this I had only tested mousepressed properly.

[Moe]

I don't mind about double posts
Anyway, I checked the code and we actually do only create events for "finger touches screen" (ACTION_DOWN) and "finger leaves screen" (ACTION_UP). Everything between those two events is totally random at the moment.

What do you mean by "totally random"? What happens is that mousepressed and mousereleased are called at those, and only those, times. And in between, love.mouse.isDown('l') returns true, just like it should. In my game however, something that should happen when you hold the "mouse" down doesn't happen, but it is not because of this. I am currently trying to identify the specific issue.

The current implementation only updates when the fingure starts to touch the screen or when it is removed. Between those two steps, no position updates are actually done, but there might be some internal in Android, that gives an update event. Since we do not yet update at pure move events, there might be some random updates by timeouts, but actually I do not expect that those events are somehow reported to love.

Also, I noticed that framebuffers don't work. No biggie but good to know.

I have to check and fix it.

And another thing. Somebody seriously have to do something about stability. On my phone, love-native-android starts properly maybe once every 20 starts. It's getting annoying.

Our main focus lies on this point at the moment.

EDIT: I can now confirm that both love.mousepressed and love.mousereleased work excactly as they should, the error lies elsewhere. Prior to this I had only tested mousepressed properly.

The event is not reported to love, that is the problem.

[T-Bone]

Ah, yes of course. love.mouse.getPosition() keeps giving the same coordinates even if you move your finger.

I'm pretty sure the luaj-version of love-android has proper support for this, so you can look at it's source code if you're not sure on how to implement that.

EDIT: Can confirm that the luaj-version does this correctly.
EDIT: Also randomly noted that love.event.push('q') doesn't work.

[kalle2990]

Some application tweaks

While trying LÖVE for Android out the other day I quickly noticed that it was very inconvenient having to re-compile the Love.cpp every time I had to switch source. I decided to get rid of this hassle and modified the code a little (as well as adding some Java and xml) to create some basic functions making development on the go a piece of cake!

Feature #1
It is now possible to click on a .love file in a file explorer or in the download manager - The file will open directly.

Feature #2
Instead of launching the standard no-game screen on launch, the application now gives a handfull of launch options.

• Start the no-game screen (Some people might still want this.. )
• Launch a recent launched file with just one click.
• Browse the sdcard (or "external" storage) for files. These files can be opened directly by clicking one. Long-clicking a folder will open a dialog asking if you want to launch it, so you won't have to re-package everything when testing.

Main screen

Screenshot_2012-03-13-14-30-23.png (48.71 KiB) Viewed 7942 times

I guess that's it.
If requested, I could package the changes in a zip and upload it here

[thelinx]

Make a fork on github and upload your changes.

[Moe]

I'd love to integrate it, it allows us to concentrate on bugfixing. Can you upload it somewhere, mail it to me, or make a pull request on github?

[miko]

If requested, I could package the changes in a zip and upload it here

Please do! BTW, I wonder how love for android should be distributed like. I think that it would be wasteful to have every love2d binary with each new game written for android. It would be more efficient if there was only one binary, and the *.love files could be "bought in-app", yet still available as a games in Android Market (errr.... Google Play).

Anyways, adding some networking support for this launcher could help keep only one copy of love and download different games from the internet (be it Google Play or other "official" love-android server).

[T-Bone]

If requested, I could package the changes in a zip and upload it here

Please do! BTW, I wonder how love for android should be distributed like. I think that it would be wasteful to have every love2d binary with each new game written for android. It would be more efficient if there was only one binary, and the *.love files could be "bought in-app", yet still available as a games in Android Market (errr.... Google Play).

Anyways, adding some networking support for this launcher could help keep only one copy of love and download different games from the internet (be it Google Play or other "official" love-android server).

I could not disagree more. The only positive side of this is that it would take less space on the user's phone. However, this is not an issue really, with App2SD, a love-native-android app takes about 12 kB on the phone's main memory, the rest is on the SD card partition where even old phones have plenty of space.

Any efficiency benefits also assume that an end user has more than one löve game installed. This is unlikely to be the case for most users.

Love-android should be as transparent to the end user as possible. Normal people who just want to play a fun game on their cell phone do not want to know how it was built, and they certainly don't want to download a separate app.

Having a single LÖVE binary that can run multiple .love-files from the SD card should be for developers only, to make testing easier. Nothing else.

Of course, having a server with LÖVE games that you can browse, download and play could be a fun side project, but PLEASE do not focus development on this. Android really needs good, easy to learn frameworks for making stand-alone games, and love-native-android is the best one I've seen, and the performance seems good too.


Also, I want to confirm that all crashes disappear in my game if love.modules.audio is disabled. The game starts every single time.

[kalle2990]

I'd love to integrate it, it allows us to concentrate on bugfixing. Can you upload it somewhere, mail it to me, or make a pull request on github?

After some trouble getting used to how git works, I managed to send a pull request. It should be available on github as I'm speaking

[TechnoCat]

BTW, I wonder how love for android should be distributed like. I think that it would be wasteful to have every love2d binary with each new game written for android. It would be more efficient if there was only one binary, and the *.love files could be "bought in-app", yet still available as a games in Android Market (errr.... Google Play).

Every game should come with a LOVE binary of its own. No user is going to memorize which games he downloads are for which version of LOVE.