Android Rotating a set of bitmaps around a common pivot point - android

I am trying to create a game like Jigsaw Puzzle. I am using a class that extends View and in its draw method, I am drawing different bitmap pieces. When user tap a bitmap, I rotates that bitmap by 90 degree angle. Its working perfectly. But user combines some bitmap pieces and then rotate the group, the bitmaps rotate around their center point destroying the group structure.
My question is how to rotate a set of bitmaps around a common pivot point so that when a group of bitmaps rotate, it retains its shape structure?

I am assuming that you have each of the pieces center-weighted which is causing your problem.
On possibility is to have the background be a center weighted object or to look at background and declare the center as the point of rotation.
Then, calculate the approximate box size of each jigsaw piece (this could be dynamic based on if you are using Zoom). to figure out its placement on the screen as bitmap objects in Draw().
Now, imagine a line being draw from the center to the edge of the screen being rotated to get your angle.
So, based on this new information, you would need to calculate your new angle for each center weighted object (jigsaw piece) based off of the angle set by the center of the screen rotation. Each piece would have a different angle of rotation on its axis because of the new line or angle of rotation set by the center of the screen.
This is more of an algorithm/calculation than programming, more specifics on your issue would help.

Related

Calculate pixel offset with Projection and View matrices

I am developing an app where the user can draw onto a Bitmap (with MotionEvents and Canvas), which then gets projected onto an OpenGL Surface as a texture. The issue is, I'm having some trouble to correctly offset the pixel where the user touched (Position [x,y] from the top-left corner of the screen, given by MotionEvent), onto the correct place that the Bitmap should be drawn, considering both the position and scaling of the View Matrix (maybe the projection as well). I'm unsure if there's a simple way to mathematically relate screen pixels with GL's Normalized Device Coordinates, which would make things easier.
Example:
Let's say the user touched the top-left corner of the screen (0,0). From view transformations (scaling and translating), however, such corner happens to be exactly at the center of the projected Bitmap. How can I offset this (0,0) position so that it draws in the center of it?
(Also, if what I'm trying to do is extremely impractical, and there's a much easier way, it would be welcome to know).

How to determine in which direction a bitmap has to be rotated?

How can I determine in which direction and how far I have to rotate the image? I use Android Canvas to draw the line and the arrow image.
canvas.drawBitmap(arrow_direction, leftpos,rightpos,null);
The image is always shown as it is. The image shows clearly that I have to rotate it 90 degree to the left.
I know I can rotate the image with
Matrix rotator = new Matrix();
rotator.reset();
rotator.postRotate(degree);
But I don't know how to calculate the value for degree to rotate the arrow? I know only the coordinates of the two red points. So I think it might be possible to calculate it with this two points, but I don't know how.
In another way how can determine on which side of the image is the end point of the line? In the example it is on the right side, therefore I know that I have to rotate the image -90 degree.

Viewport boundaries on any resolution with OpenGL ES

I'm having difficulties understanding about the OpenGL perspective view. I've read tons of information however it didn't help me trying to achieve what I'm after. Which is making sure my 3d scene is filling the entire screen on every Android device.
To test this, I will be drawing a quad in 3d space which in the end should touch every corner, filling up the whole device's screen. I could then use this quad, or actually its coordinates to specify a bounding box at a certain Z distance which I could use to put my geometry and making sure those fill up my screen. When the screen resizes, or I am to run it on another screen resolution, I would recalculate this bounding box and geometry. I'm not talking about static geometry, but for instance say I want to fill the screen with balls and it doesn't matter how big or how many balls there are, the only important thing is the screen is filled and there are no redundant balls outside the visible frustum.
As far as I understand when specifying the viewport you actually bind pixel values to the frustum's boundaries. I know that you can actually set an orthographic view in a way your window pixels match 3d geometry position but I'm not sure how this works in perspective view.
Here I'm assuming the viewport width and height to be mapped to the nearZ. So when a ball is at Z=1f it has it's original size
When moving the ball into the screen so into the direction of farZ, the ball would be scaled down in order for the perspective to work. So a ball at Z=51f for instance, would appear smaller on my screen and I would need more balls to fill up the entire screen.
Now in order to do so, I'm looking for the purple boundaries
Actually I need these boundaries to fill the entire screen on different frustum sizes (width x height) while the frustum angle and Z distance for the balls is always the same
I guess I could use trig to calculate these purple boundaries (see blue triangle note)
Am I correctly marking the frustum angle, it being the vertical angle of the frustum?
Could someone elaborate on the green 1f and -1f values as I seem to have read something about it? Seems like some scalar that is used to resize the geometry within the frustum?
I actually want to be able to programmaticaly position geometry against the viewport borders within 3d space at any resolution/window for any arbitrary Android device.
Note: I have a flash background which uses a stage (visual area) with a known width x height at any resolution which makes it easy to position/scale assets either using absolute measurements or percentual measurements. I guess I'm trying to figure out how this system applies to OpenGL's perspective view.
I guess this post using gluUnproject answers the question.

2d Graphics - sprite click detection

I'm working on a small app that uses sprites which are rendered using a canvas and simple drawBitmap.
Once the user touch the screen I need to know which sprite was clicked on.
I'm able to achieve this goal when I treat each sprite as a rectangular which has the width and height of the image.
However, some of the sprites takes only small portion of the entire rectangular and I would like to ignore when user clicked inside the rectangular but not on the internal shape.
Any ideas what could be a good method to do that?
Edit: Just to be more clear, lets say I have a sprite with size of 200x200, the sprite is an image of an airplane from above and the airplane has long long wings. Since the wings are long there will lots of "dead" areas in the sprite.
I would like to detect when user clicks the airplane itself only and not the "dead" area.
Thanks.
You will need to create a 2d array of all the pixels in the bitmap. Mask the pixels to either a 0(transparent) or a 1(has color). Then when you click inside of a rectangle you will just need to get the width offset and the height offset within the rectangle. This gives you your indices for mapping to the pixel array. Then check and see if the index in the pixel array contains a 1 for a value. If so then you clicked on the actual image. Does that make sense?
You have to check for the area where your Bitmap gets drawn, not another rectangular shape. Just treat every sprite (which may have different sizes) as a single rectangle, whose width and height equals to the width and height of the sprites.
Since you elaborated your question I'll give another suggestion.
When you have detected a click on the sprite, simply check (in the Bitmap's area) the current pixel via the Bitmap.getPixel() function. You can then easily check if the color at the specified position is something you're interested in, otherwise you can just skip detecting the touch.

Animating with rotation

I'm writing a game and now I'm starting to realize that the performance has to be improved (link to game (market)).
If you can't check it out: It's a snake-like game with birds. You control the first bird (by drawing a path for it to follow / using dpad), and a swarm of smaller birds follows it in line. The birds are animated, and can be rotated by 180° and mirrored (depending where they're flying through).
At the moment I animate the first bird only, then scale it down and save it in an invisible element which is shown 4 frames later (fluid animation purposes), instead of animating each bird individually. So for each bird you see on screen, there are 4 objects with a bitmap each. Now my question is, should I make a spritesheet and reduce the number of possible rotations (say, 1 set of sprites every 10°) or calculate the animation for each bird, or keep it my way?
There is no point making your rotated sprite sheets by hand, I'd just load in a single sprite sheet. Then make an array of Bitmaps, for each angle, and rotate and copy the base sprite sheets over each. (you may need an array of arrays to handle the animations, or do separate rotates for each frame of the sprite sheet) This also lets you change your art later with ease.
something like:
Bitmap baseFrame;
Bitmap rotatedFrame[]=new Bitmap[360/10];
...
Matrix rotationMatrix=new Matrix();
rotationMatrix.setRotate(n*10);
rotatedFrame[n]=Bitmap.createBitmap(baseFrame,0,0,
baseFrame.getWidth(), baseFrame.getHeight(),
rotationMatrix, false);
The width, and height of the rotated images may need to be larger then to base image, and you may want you set it up to rotate around the centre but you get the idea
By the way,
Having a look at your screenshots of your game I suspect that drawing your background may have a bigger effect then rotating the birds. You may want to profile your code to see how long it's taking to draw each image. ( http://developer.android.com/guide/developing/debugging/debugging-tracing.html ). I'd make sure your background is being loaded in a RGB_565 format, it can be quite a lot faster when rendering in software.
I have found rotating images in android to be surprisingly fast, being able to rotate hundreds of small bitmaps at a good frame rate.
Here is the simple explanation of the Rotation Animation:
http://androidtutorials60.blogspot.in/2013/09/simple-rotate-animation-in-android.html

Categories

Resources