love-android: discussion

[SiENcE]

I don't think the development is at a state where you can report bugs and ask feature requests. Wait until it's beta.

[ghoulsblade]

@SiENcE: let me be the judge of that please, i uploaded the apk so people can test it on different hardware,
and getting feedback about what works and what doesn't for different android phones is already important.

.ogg only once : i have an idea, but won't get round to it just yet. (MediaPlayer vs SoundPool, might need reset call to restart from beginning)

multitasking : known, that is the same as the white+black screenshot posted earlier, will be fixed eventually but low prio for now.

screen rotating + home key : afaik those are enforced by operating system, at least by default.
Will probably involve quite a bit of api digging and experimenting to find a way around that, if it is possible at all, not time for that atm, sorry.

[ghoulsblade]

devnews: http://ghoulsblade.schattenkind.net/lov ... ndroid.apk love-android.apk
* first experimental multi touch and generic sensor access available (untested), see readme at the bottom of https://github.com/hagish/love-android
* hagish: audio available when playing from .love, sdcard write permission needed (audio files need to be unzipped to get the android api to play them)

[thelinx]

Small issue, if you select an item in the load list, then deselect it, its background turns black.

(Put finger on item, move finger out of item area)

[Reenen]

I just have to say, that for my initial purposes, it already works perfectly (in fact, I'm going to deliver the tablet tonight). The difference between .ogg and .wav is about 30kb so it's not a huge issue at all. (6kb vs 36kb).

And another feature request would be totally fullscreen (dunno if yours still has the status bar with battery life etc. at the top), so the notification "drag" bar is still able to interrupt the program.

[T-Bone]

I just have to say, that for my initial purposes, it already works perfectly (in fact, I'm going to deliver the tablet tonight). The difference between .ogg and .wav is about 30kb so it's not a huge issue at all. (6kb vs 36kb).

And another feature request would be totally fullscreen (dunno if yours still has the status bar with battery life etc. at the top), so the notification "drag" bar is still able to interrupt the program.

Preferably, it should be up to the game itself to decide if the notification bar should be visible or not. Some games should use full screen, but others shouldn't.

Do not overwrite the functionality of the home button! It should be consistent with all other apps. As for screen orientation, I think it's really important that the game itself can

1. detect what orientation is used
2. force a specific orientation if the game needs it

Let's face it, few games are designed to work both in portrait and landscape. And it's very much possible to force an app to use a specific orientation. I've also seen apps that have different orientation settings for different activities, so it should be possible for each game to have it's own settings regarding this.

[Reenen]

Oh, yes, absolutely, I didn't for one moment intend fullscreen to be the "default" way. Just an optional way.

I've been thinking about the home button, and I tend to agree... We'll see how often she touches it, and if it happens too often we may just put a fair bit of sticky tape over that button.

[T-Bone]

Oh, yes, absolutely, I didn't for one moment intend fullscreen to be the "default" way. Just an optional way.

I've been thinking about the home button, and I tend to agree... We'll see how often she touches it, and if it happens too often we may just put a fair bit of sticky tape over that button.

I know it's possible for apps to overwrite the functionality of the physical buttons on Android devices. The optimal solution to this would be that love.keyboard (and of coure love.keypressed and so on) would register the keys "home", "menu", "search" and so on, and, if they're used in a game, the standard functionality of those buttons would be overwritten (but not otherwise). This is probably a pain to implement as you'd have to look through the source of the lua files in order to know if the buttons are used or not. A simpler soultion would perhaps be to have a function or a table that let's the user specify what physical buttons he or she wants love.keyboard to recognize. For example, if a table was used, it could be something like this

Code: Select all

table.insert(love.buttons,"menu") --menu key is used

function love.keypressed(k)
    if k == "menu"
        --happens if menu is pressed
   elseif k=="home"
        -- can never happen, since the "home" key takes the user out of the app
   end
end

Or maybe it would be better to put this in love.conf?

[miko]

This is a great project, keep it going!
I have installed it on my HTC Desire / Android 2.2, and it works. One issue I have is that I can not get any fonts printed out to the screen, so debugging on the device is not that nice.

For usual love.graphics.print() I get no output at all. Could anyone provide me with a working example?

Also, the image font does not for me - I get only white boxes instead of letters. Would it be PO2 syndrome?

I am attaching a mouse(touch)-enabled version of iyfct, which works on my phone (except for fonts).
Mouse pressed are mapped as follows:
- top left corner: "r" (i.e., restart the game)
- bottom left corner: "escape"
- right side: "return" (i.e., JUMP or SELECT menu item)

I wish there was also some kind of network support, so I could debug applications remotely.

[hagish]

If you use eclispe + adt you can debug your application in the emulator on a read device via usb connector.