Need help for programming screen tilting for Android and other things

fiskefyren

Hello,

I'm not sure if I'm posting this at the right place, so please forgive if I put it up wrongly. Anyway, I made a small dumb game where you move a bar from side to side to catch a little ball and a score board counts each time you catch it. Which I want to run on my Android SmartPhone (Samsung Galaxy S2).

My questions regarding this: - I've programmed the bar to move with the arrowkeys (RIGHT, LIFT) but how do I make them touched based so you can play the game with a touch screen? I'm thinking that I probably have to use the mouse function, but I'm fairly lost at this point (please note that I'm very new to programming). - I would also like to know who you program the part where you turn the screen (screen tilting?) on your SmartPhone and your app/game turns with it... I'm guessing that I've to do some scaling that makes sure that when the screen is turn everything will match it, plus I can't know what resolution other people runs on their SmartPhones. But how do you do the turn thing? - I could also use some help on the scaling bit... all I know is that I probably need to use dist() or something? Or make a int/float for size_x,size_y, but I'm not really sure how to tell that they can change with a display size / resolution...

I've more questions regarding this but I think they may become more clear to me as I go along (hopefully).

PS. Does it matter that I've programmed the game in Processing? Because I haven't added the Android mode yet and I haven't added the SDK tools and stuff like that... I got rather confused by the guide on Processing.org, maybe because I use Windows and the example was based on OSX.

PSS. I might not reply right away, I'm a little pressed for time at my university for the next 2 weeks or such.

Thank you.

calsign

Moved to Android Mode category, since this seems to be your main focus.

If you want to use Android mode, I suggest that you get started with installing the SDK and connecting your phone because the process can be potentially rocky and / or frustrating.

In general, Processing tries to maintain compatibility between modes (with exceptions for more advanced sketches), so detecting touch in Android mode is as simple as using the mouseX and mouseY variables. However, there are a couple of differences that are inherent to the touch screen: there is no concept of hovering, for example. You might need to redesign your sketch slightly to accommodate for a touch screen.

If you know how to use mouse input in Java mode, then Android touch should come fairly easily.

Of course, you also have the option of using two graphical buttons (left and right) to emulate your keyboard for taking input in Android mode. This presents a different challenge, which may be a bit easier. There are numerous examples for buttons out there...

As for screen size scaling, you might not necessarily have to worry about this at this point in time... but it is definitely a good practice and recommended. It will largely depend on what you have already. In general, you need to define absolute coordinates as a fraction of the screen (e.g. half-way across the screen, or 10% of the screen's height). You will then need to change all of your drawing coordinates to use fractions.

For example, the following code:

size(400, 400):
//...
text("Hello, World!", 200, 40);

...will become:

//We don't need to use size() in Android mode - the sketch will automatically fill the entire screen!
//...
text("Hello, World!", width / 2.0, height / 10.0); //Half-way over, 10% down

Given the same screen dimensions, the above two examples draw text at coordinates that are mathematically equivalent, but the second will scale automatically to the screen dimensions.

Note: With this approach, you must specify float fractional components (with the decimal point) because width and height are ints, so you can lose precision!

Finally, screen rotation: Processing's default behavior upon a screen orientation change is to restart the sketch with new screen dimensions (so the old width becomes the new height, and vice versa - also, "down" (positive y) will remain down from the user's perspective). If you want to disable this, you can lock the screen orientation to a pre-specified orientation here.

GoToLoop

Note: With this approach, you must specify float fractional components (with the decimal point) because width and height are ints, so you can lose precision!

Most of the time, fractional precision isn't important for width & height!
Internally, graphics functions gotta use round() on coordinates b/c pixel coords. are whole! ;))

calsign

@GoToLoop: I recommend to use a float because I have run into issues in the past.

Say, for example, the height of your display in 1080 pixels (height of an HD device in landscape mode). The height variable is an int. Say that I want to draw something 3/32nds of the way down the screen (I have done this before...). One might write this as follows:

text("Something!", width / 2, height / 32 * 3);

However, in this case, the height (1080) divided by 32 isn't a whole number - it's 33.75. With integer math, we drop the decimal, and this becomes 33. Now, when we multiply this by 3, we are off by a whopping 2.25 pixels (it's supposed to be 101.25, but integer math gives us 99).

This might not look like much, and it's not - especially on a display that is 1080 pixels tall. However, when we take into account that the sketch must be run on many different-sized displays, this discrepancy becomes more important.

Let's use the same code, but this time, we'll run it on a display that is 240 pixels tall (landscape in one of the smallest displays on the market, but still fairly common).

240 divided by 32 is 7.5. 7.5 multiplied by 3 is 22.5, but with integer math, we get 21. That's only 1.5 pixels - but this is a much larger portion of the screen difference than we had with the HD screen.

These errors are further amplified when using fractions such as 29/32 (admittedly, not the best idea), which would be off by 21.75 and 14.5 pixels on the large and small devices, respectively.

The bottom line is that using floats will solve all of these problems because float division is exact (at least, more exact than integer division).

Now, there is another potential solution if you don't like using floats (well, it still uses floats, but...). I often will create two global variables that correspond to the width and height variables - except they are floats! You then use these variables in all of your fractions. This approach also has the added benefit of making your code more concise (and also a bit more cryptic...):

float SW, SH; //stands for Screen Width / Height - I created these names back when we still had screen.width and screen.height...

//...
size(400, 400): //Don't need this for Android, but this approach can be used in Java mode as well

//Assign the variables...
//If your display size changes for some reason, then you'll need to update them (but this isn't a problem on Android)
SW = width;
SH = height;

//...
text("Properly positioned text!", SW / 2, SH / 32 * 29); //  29/32!!!

GoToLoop

Well, I remember I said "most of the time" at the very start! ;)

calsign

My fear is that someone will get accustomed to using integers and then get themselves in too deep... resulting in their sketch looking a great deal different on different displays (sometimes bloated and / or unusable). Perhaps this much care is not necessary for many sketches, but I think the warning is still important!

fiskefyren

First off, thanks for replying! Secondly, sorry that it took me so long to get back to this, I didn't know that I would be hung up on my last project for this long :(

@calsign Well... I've already programmed the game in the normal Java-mode in Processing with keyboard keys for movement... so looking at your example I guess that I might have to rework the whole thing? but I don't really know the difference about programming for Android compared to just programming in Java-mode :/ I thought it would be the same thing, with maybe a few alterations like touchscreen and stuff like that. Or maybe I just misunderstood what you tried to tell me, it happens, curse my dyslexia!

I would like to pass on the button (at least for this) because I want to learn how to do the other thing. but right now I pretty much have no clue as how to get started on this...

Also I'm a little confused about the SDK tool, I can't really figure out what to install... and the http://processing.org/tutorials/android/ doesn't look like the version I got of SDK even though I just downloaded it like a week ago.

You also mention something about hooking up my SmartPhone to my PC/laptop, do I need to do something "special" beside just putting an USB into it? like updating some software or something?

calsign

My advice above was a bit nit-picky... but using fractions (or other methods) is important if you want to distribute your sketch to many different devices. In general, it shouldn't be too much of a change from your Java code (it depends on how many hard-coded numbers you have).

The SDK tools used in the Android Processing tutorial look really out of date (Android 2.2!!). You want to install everything under API level 10. If you're more adventurous, you can also install the latest version, which is API level 19.

The SDK tools come with an emulator, which can be used to test sketches. I recommend that you use an actual device (if you have access to one) because the emulator is really slow (I can't emphasize this enough) and doesn't necessarily best represent a user's experience with a real device. Indeed, getting a phone set up can be challenging (it varies from case to case) - but that is another whole set of problems for later, when you have the SDK installed.