What is more expensive, 500 nested if statements being constantly check in the game loop, or pi being constantly calculated in the game loop?
At least the JVM will only check the first condition of the if-statement and ignore the rest if it is false.
So what’s more expensive?
Random branches are always expensive. Pi is a constant. I think you need to provide more details about what you think you want to do.
Well, I want to make an on screen controller, kind of like a joystick, but one that doesn’t return to the center and that doesn’t stay pressed. Basically a half circle, the top radius would be for full speed forward, and the position would be for turning left or right(not turn would be in the center). One that can be touched anywhere and not moved from the center to a point.
I know I could make a lot(like 500) if statements for each little square area within the half circle controller area, and then set the movements based on that. I could also just use pi to calculate exactly where and how far from the radius the player is touching. Which ever is chosen, it’ll be constantly looped if the area of the controller is touched.
The answer is quite obvious… Some little math calculation is far cheaper than 500 if statement.
you will probably find it easiest to get your controller working well if you calculate a distance from the center and an angle. then you can tweak the values until it feels right.
I was thinking that I could split the if statements up.
if x < 50 then…
if x > 50 then…
So every if statement wouldn’t actually be ran through. I could nest it nicely.
Still more expensive?
its probably best to do it in a way which used 5 lines of code rather than 500
You could just calculate the rotation between the center point and the point that is pressed on the controller and also the distance. The distance would be the power the stick is bent, and the rotation would be by how much the stick is rotated.
In this drawing, black circle is the rotation stick pad. Red dot inside of black dot is the center of the pad. Green line going up is the line from which rotation is calculated. Red dot is a point where user is tapping. Purple thingy is the rotation from the green line to the tap point. Yellow line is the distance from center to tap point.
Wait, you just want to know distance and angle of the joystick from the center point?
double dx = x - center.x;
double dy = y - center.y;
double angle = Math.atan2(dy, dx);
double dist = Math.sqrt(dx * dx + dy * dy);
I use that exact code in this color picker UI to calculate the color being selected by the wheel widget:
Seems applicable to your problem description.
I don’t see why you would ever use anything but some simple math for this kind of stuff.
The reason I’m asking is because this is for mobile devices.
I’ve heard the pi is expensive and should be avoided. So, if I split up some if statements, after maybe 9 or 10, I would have a result. Over and over again.
So, in other words, when it comes to using a mobile phones CPU, is checking through 9 to 10 basic <> if-statements, more expensive than using pi once?
Although, I’m pretty sure you all are saying that it is.
What do you mean PI is expensive? Its like any other constant o-o In fact, constant are probably one of the cheaper things…
Both options are computationally inconsequential, when performed at the (relatively low) frequency you are talking about.
Don’t worry about it, and go with the sane route. It’s also the one that isn’t a horrible approximation.
EDIT: also, to attempt to clear up any misconception, “pi is expensive” argument is non-existent as PI is stored as a constant value as Math.PI. It’s not calculated every time you use it, in fact it’s never calculated, it’s hardcoded in the source of Math.java
π is expensive if you where to calculate it to the 10256th decimal place every single frame, but you’d be fine if you just had
final float PI = 3.141593;
Doing calculations with a float like that is going to be fine on any device, and you’ll find that if you want to optimize you will want to be looking in other places for now.
However doing some 500 nested if statements will certainly cause noticeable lag on some devices.
EDIT:
The stuff I’ve heard against using π is in relation to Math.PI which uses an extremely precise number (16 decimal places), but I think even then it’d just pedantic.
Oops, I’ve been meaning to say SquareRoot instead of pi. I don’t know why I’ve been saying pi, lol.
Is Math.sqrt more expensive than a bunch of if statements?
No direct answer, but if you only do it so few times per frame, I would not really think about it, because even saying it is more expensive, it is still less expensive than a millisecond.
Use what is easier to use, so probably sqrt.
Worrying about performance now when nothing works is like seeing how quick you can get nowhere.
500 nested ifs…most things will be able to handle much much more than this.
A constant…about as fast as you can get.
Sqr()…actually very fast in java. You could have 50k calculations a frame and still be fine even on mobile.
The better answer is what is easiest to write and understand.
To put numbers on it a square root is roughly 34 cycles (arch dependent). Move 32-bits from L1 cache into a register is 5 cycles (again arch dependent). Sqrt is fast (relatively).
Alright, got it up and running on my phone and I can’t see a performance slow down at all. I don’t know if I really like the joystick idea. I’m using a half circle rather than a full one and it seems weird on a cell phone. It’s faster than the push buttons I had, but it’s a bit awkward.
This is about the little mobile 3D game you are working on, correct?
Why don’t you try to use a “go to” based movement system instead of a “go into key direction” one?
It would be a lot more user friendly and only a little bit work for you.
Be super careful with touch controls… they make or break an entire game concept. Anything relying on on-screen controls is doomed to fail for starters.
Cas 