love-android: discussion

[kraftman]

As above, I can't seem to get printing to work, it instead outputs white squares. should I set a font first?

Is there a list of which parts of the love API are currently working?

Thanks for this guys, its excellent!

[ghoulsblade]

font bug on devices is known, works in emu, we're working on it.
list of supported api : no function-by-function list, but see "done" and "not yet working " sections on
http://ghoulsblade.schattenkind.net/wik ... 2d-android

print : yeah, hard without setting up the android sdk and debugging via one of the commandline things + usb cable.
maybe this thread is interesting ? didn't try it yet, but seems it shows console output stuff onscreen :
"Debug - A whole new way of debugging your game" http://love2d.org/forums/viewtopic.php?f=5&t=2473

[miko]

font bug on devices is known, works in emu, we're working on it.

OK, thanks for the update.

print : yeah, hard without setting up the android sdk and debugging via one of the commandline things + usb cable.
maybe this thread is interesting ? didn't try it yet, but seems it shows console output stuff onscreen :
"Debug - A whole new way of debugging your game" http://love2d.org/forums/viewtopic.php?f=5&t=2473

I tried exactly this idea, but without working love.graphics.print() it will not work. Besides, print() is important for communication with a user - you cannot usually create an image for every message...

What about network support? Is it even considered?

[ghoulsblade]

debug/love.graphics.print : yeah, i hope i can fix it this weekend. you couuuuuuld make 26+10 small images a-z0-9 and override love.graphics.print to draw sprites if you're impatient XD

network : from what i hear internet connections on smartphones are rather unstable,
so don't count on it for "realtime" gameplay too much (turnbased/delay stuff might work),
wlan might be better tho.

it's on the todo, so considered yes, but i haven't looked at the api yet.
first some sensor stuff then the font fix i guess

[TechnoCat]

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

Why not invent new callbacks for each system button?

[T-Bone]

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

Why not invent new callbacks for each system button?

That's a possibility. There are a few issues that might have solutions:
1. Inconsistent with other physical buttons
2. lots of functions (keypressed, keyreleased, and isDown for every button)
3. not trivial to check if a function has been overwritten or not in order to know if it should overwrite the standard key functionality

[ghoulsblade]

when lua code in the .love wants to override default behavior of a button it could just do "return true" in the keypressed callback i suppose =)
e.g.

Code: Select all

function love.keypressed(key)
  if (key == "phone_home") then 
    print("home pressed, overriding...")
    return true
  end 
end

i'll check this weekend if it's technically possible via android api to override / disable their default behavior.

[T-Bone]

when lua code in the .love wants to override default behavior of a button it could just do "return true" in the keypressed callback i suppose =)
e.g.

Code: Select all

function love.keypressed(key)
  if (key == "phone_home") then 
    print("home pressed, overriding...")
    return true
  end 
end

i'll check this weekend if it's technically possible via android api to override / disable their default behavior.

I know that it is possible, at the very least for the menu button. I'm not sure how you do it though.

[ghoulsblade]

devnews: http://ghoulsblade.schattenkind.net/lov ... ndroid.apk
fontfix 1, still doesn't work in "in your face city trains", but at least i get a text now when using a mini main.lua :

Code: Select all

function love.load () end
function love.draw () 
	love.graphics.print(" abcdefghijklmnopqrstuvwxyz0123456789.!'-:·",10,10)
end
function love.update () end

[ghoulsblade]

devnews: http://ghoulsblade.schattenkind.net/lov ... ndroid.apk
changed geometry generation for font a bit to avoid reallocating the buffer and give a different size in case of spaces,
also made the default font white rather than black and power of two.
It seems to work for power-of-2 texture sizes now. see attached .love file :

fonttest.love

(2.14 KiB) Downloaded 96 times

should display 3 lines with different font,
1) default font in white (works correctly on my milestone)
2) non-power-of-2 image font in black (316x6) (i only get white boxes on my milestone)
3) power-of-2 (512x8) image font in red (works correctly on my milestone)
4) non-power-of-2 image used for the font (316x6) (i only get a big white box on my milestone)