LÖVE

A flag in setMode ("portrait", "landscape", "default", "auto") would be quite nice and handy

I~=Spam wrote:

Frohman wrote:Edit:
Hadn't occurred to me that you'd likely do this in the packaging step, so for basic testing with .love's and main.lua's, should I rebuild the apk myself with the orientation specified?

Yeah I think that is how you have to do it... Seems silly to have to rebuild the entire apk for just that but I think that is the only way unless something hackish can be done instead... :\

Well, I can't rightly think of a reason why you'd need to force-change orientation settings mid execution, especially for a game etc, which leaves just inconveniencing testing. I suppose one could compile a couple of apk's to run in different modes, so you're not locked in while testing.

Letting the user decide the desired orientation seems like a good reason to me

Quick question, is the love.thread module supported? Haven't found any specific mention of it so I'd assume it is.
EDIT: Had the time to run a quick test. It's supported.

Nixola wrote:Letting the user decide the desired orientation seems like a good reason to me

Use a camera library, like gamera, then just turn your screen 90 degrees, also I have made some test and you can use the accelerometer to detect orientation

Positive07 wrote:

Nixola wrote:Letting the user decide the desired orientation seems like a good reason to me

Use a camera library, like gamera, then just turn your screen 90 degrees, also I have made some test and you can use the accelerometer to detect orientation

I suppose that works too. Although, I am pretty sure that there is a speed penalty for that though...

I~=Spam wrote:I am pretty sure that there is a speed penalty for that though...

Actually it is two love.graphics.translate and one love.graphics.rotate... so really no impact!
Of course if you use a full fledged camera library you may have more of an impact, but I recommended that because you can use it for the game AND the screen, if you just need the screen, maybe something simpler will do (also take into account that then you have to also adapt the x,y coordinates of the mouth to be correct, gamera already handles this I think, not sure)

slime wrote:It shouldn't translate the game window if you give setTextInput x/y/w/h arguments that would be completely visible on-screen even with the keyboard visible as well.

Sorry for the late reply on this, but I've tried it just now and it still translates the window.

Code:

https://love2d.org/imgmirrur/G5o3E5R.png

In-Game:

https://love2d.org/imgmirrur/ynF3ubG.png

TurtleP wrote:-snip-

There it says 242*scale in the y argument, so it is translating your game screen 242*scale pixels up...

Positive07 wrote:

TurtleP wrote:-snip-

There it says 242*scale in the y argument, so it is translating your game screen 242*scale pixels up...

Thanks, I must have read the documentation wrong or something.