I have looked at the Animation class and am having difficulty understanding how exactly you do things.
In my case, you have a deck of cards in the middle of the screen and I want to animate the deal by showing cards sliding across the screen to the users (who are located on the four edges of the screen).
In some cases, I need to animate the card face-up and then show it face-down in the player hand.
I really am totally lost.
You may take a look at the SurfaceView class, which has a Canvas to draw things. Creating games and animations in general is much easier with Canvas. Good luck!
Related
I am using LibGdx to develop a game. For Now I am not using scene2D. I am struck up in increasing the levels of the game as I do not have the scrolling screen.
I like to design a a scrolling screen as it is in many games which are level based (for ref, lets say Candy crush). Could you please point me a example on how to have such a scrolling screen to show a bigger area where I can show many levels.
Thanks is Advance !
Using the Scene2D function is not necessary for this and is more for GUI implementation and different screens. The Scroll pane really shines when creating reading content that does not fit your phone. I do advice to start learning Scene2D to create MenuScreens and UI though.
What Candy Crush "simply" does is having multiple backgrounds that are placed next to each other and tile seamlessly. They use buttons in the correct place for levels. By dragging a finger across the screen the camera will move in that direction. For the movement from one level to the next there is probably something like a spline in play.
It is important only to draw the background tiles and buttons that are actually visible on the screen if you have many. Since these have fixed positions and you know your camera area and position you can calculate what to draw and what not. Just drawing everything each frame is likely to slow down your fps.
You can do a search on:
Tilemaps, for you backgrounds but you probably want them in just one direction so a simple 1D array would suffice.
Dragging, to move your camera. Here I gave a basic explanations on how I do it.
Splines, are a bit tougher and you do not really need them. They could be used to animate or move something along a curve.
Thats all, expecting you know how to create something like a button (click a sprite).
I have recently completed a simple drag and drop shapes game. It had the user drag a shape (ImageView) to another "empty place holder" ImageView.
I now want to make this a little more advanced, instead of dragging a simple shape, I want to make a puzzle of various non-orthogonal shapes, for example breaking a circle into 5 different pieces. What I'm having a problem with right now is how to design the layout. I do not know how to make a truly "custom" shaped ImageView, as far as I can find from my research it's not possible. So my idea for now is to overlap a number of square ImageViews, each of which will have only a subset of an image and the rest transparent. Thus the final output will look like it's a number of custom shaped ImageViews.
Example:
+ + +
Because only the internal sections are "visible" and the rest of the circle is transparent, when all of these pieces are placed in the same spot on the screen, the final image will look like:
I haven't tried this yet... but I foresee at least one problem. When I go to drag the pieces over to this puzzle, they will all "snap" into place when dragged to the same place. Because in reality all I really have here is a picture of a circle inside a ImageView which has some invisible rectangular boundary around it.
Hopefully this situation is clear. Now my questions:
Is it possible to have truly custom shaped ImageViews instead of my idea of overlapping images?
If what I'm thinking is the best way to handle this puzzle idea, then what property can be changed such that the "drop" action does not happen at the same place for all of these puzzle pieces? If I wanted to "drop" the pizza shaped piece, I'd like it to only snap into place when it go close to the top left of the circle.
Note: I am new to Android programming, and somewhat new to Java/XML as well, it’s very likely I’m overlooking something, so please feel free to suggest other approaches as you see fit.
Not really. Overlapping views is generally the way it's done. You could also use one View and override the drawing action yourself (multiple bitmaps drawn at relative locations within the View), but that would make the drag-drop aspect significantly harder.
If the Views are all the same size, with the visible portions in the correct relative placement in each, they should snap together correctly. This is because the snap is (I believe) based on the position of the upper-left corner of the View. If the pizza-shaped piece's visible portion is correct with regards to that, it should snap in at exactly the right spot.
So you have certain places you want to accept the drops, and I'm assuming you know their coordinates, say (d_x,d_y).
Then why not simply monitor the coordinate of the center (p_x,p_y) of image view of the piece you are dragging, say the "pizza" piece, and when the distance between the the piece and drop point is within an acceptable amount accept the drop.
But if you are asking if there is some way to make non-rectangular image views I don't believe that is possible.
However I don't think it is necessary in your case, because I believe even if you want them to drag the piece precisely into place you can calculate the coordinates where the draggable rectangle needs to go with knowledge of the shape of the piece and the assumption that the rectangle wraps the piece.
Currently I am doing app allowing user to draw. Simple think, just extend Canvas class and most of the thing is done.
That was my initial thinking and idea. But as the canvas is rather small because this is only what user see on the screen there is not much possible space to draw. Going through documentation I found translate() method allowing me to move canvas. What I did find out is when I move it, there is some kind of blank space just as you would move piece of paper. I understand that this is totally normal, as I've said before - canvas is only "the screen".
My question is - is there a possibility to make something like infinite canvas so you can make a huge painting and move everything around?
Before this question I was thinking about two things how something like this can be done:
Move all objects on canvas simultaneously - bad idea, because if you have a lot of them then the speed of moving is very bad.
Do something similar as it is done in ListView when you move it (or better see on the screen) only views that are on the screen together with one before and one after are loaded to memory and rest is uploaded dynamically when needed. I think this is the best option to achieve this goal.
EDIT:
Question/answer given by Kai showed me that it is worth to edit my question to clarify some of the things.
Basic assumptions about what can be done by user:
User is given opportunity to draw only circles and rectangles with some (around 80%) having drawable (bitmap) on them on canvas.
I assume that on all screens there will be maximum 500-800 rectangles or circles.
First of all thinking about infinity I was thinking about quite big number of screens - at least 30 on zoom 1x in each side. I just need to give my users bigger freedom in what they are doing.
On this screen everything can be done as on normal - draw, scale (TouchListener, ScaleListener, DoubleTapListener). When talking about scaling, there is another thing that has to be concerned and connected with "infinity" of canvas. When user is zooming out then screens, or more precise objects on the invisible "neighbours" should appear with proper scaling as you would zoom out camera in real life.
The other thing that I've just realised is possibility of drawing at small zoom level - that is on two or three screens and then zooming in - I suppose it should cut and recalculate it as a smaller part.
I would like to support devices at least from API 10 and not only high-end.
The question about time is the most crucial. I want everything to be as smooth as possible, so user wouldn't know that new canvas is being created each time.
I think it really depends on a number of things:
The complexity of this "infinite canvas": how "infinite" would it really be, what operations can be done on it, etc
The devices that you want to support
The amount of time/resource you wish to spend on it
If there are really not that many objects/commands to be drawn and you don't plan to support older/lower end phones, then you can get away with just draw everything. The gfx system would do the checking and only draws what would actually be shown, so you only waste some time to send commands pass JNI boundary to the gfx system and the associated rect check.
If you decided that you needs a more efficient method, you can store all the gfx objects' positions in 4 tree structures, so when you search the upper-left/upper-right/lower-left/lower-right "window" that the screen should show, it'll fast to find the gfx objects that intersects this window and then only draw those.
[Edit]
First of all thinking about infinity I was thinking about quite big
number of screens - at least 30 on zoom 1x in each side. I just need
to give my users bigger freedom in what they are doing.
If you just story the relative position of canvas objects, there's practically no limit on the size of your canvas, but may have to provide a button to take users to some point on canvas that they are familiar lest they got themselves lost.
When talking about scaling, there is another thing that has to be
concerned and connected with "infinity" of canvas. When user is
zooming out then screens, or more precise objects on the invisible
"neighbours" should appear with proper scaling as you would zoom out
camera in real life.
If you store canvas objects in a "virtual space", and using a "translation factor" to translate objects from virtual space to screen space then things like zoom-in/out would be quite trivial, something like
screenObj.left=obj.left*transFactor-offsetX;
screenObj.right=obj.right*transFactor-offsetX;
screenObj.top=obj.top*transFactor-offsetY;
screenObj.bottom=obj.bottom*transFactor-offsetY;
//draw screenObj
As an example here's a screenshot of my movie-booking app:
The lower window shows all the seats of a movie theater, and the upper window is a zoomed-in view of the same theater. They are implemented as two instances of the same SurfaceView class, besides user input handling, the only difference is that the upper one applies the above-mentioned "translation factor".
I assume that on all screens there will be maximum 500-800 rectangles
or circles.
It is actually not too bad. Reading your edit, I think a potentially bigger issue would be if an user adds a large number of objects to the same portion of your canvas. Then it wouldn't matter if you only draw the objects that are actually shown and nothing else - you'd still get bad FPS since the GPU's fill-rate is saturated.
So there are actually two potential sources of issues:
Too many draw commands (if drawing everything on canvas instead of just drawing visible ones)
Too many large objects in the same part of the screen (eats up GPU fill-rate)
The two issues requires very different strategy (1st one using tree structures to sort objects, 2nd one using dynamically generated Bitmap cache). Since how users use your app are likely to different than how you envisioned it to be, I would strongly recommend implementing the functions without the above optimizations, try to get as many people as possible to do testing, and then apply optimizations to each of the bottlenecks you encounter until the satisfactory performance is achieved.
[Edit 2]
Actually with just 500~800 objects, you can just calculate the position of all the objects, and then check to see if they are visible on screen, you don't even really need to use some fancy data structures like a tree with its own overheads.
Say I'd like to make a memory/pairs game. I have currently made a draft that works on a Canvas, and cards are drawn into a grid.
This works for my current basic version, but I'd like show do an animation (when the card is turned, it will flip around and scale to higher size; or when the match is found, the cards would rotate around and then go back.
I can't imagine doing this on Canvas, I'd have to make a lot of timers and do the animation by hand, it seems overly complex for this simple task.
I think I could could subclass View for a control that would display a card, and then react to touch events for that control. It would also make drawing scaling of the images done by Android itself, and, most importantly, I could use Tween Animation for some effects.
My question is - would it be OK to use a View for each card in the game (I could have 5x6 or 4x5 cards), and arrange them in a GridView? Are there some pitfalls with this approach? Or should I continue with completely custom-drawn Canvas?
For such a simple game you should be fine using a collection of Views. As you mention using Views rather than trying to do it manually you get access to a lot of nice Animation functionality for free.
It also makes implement the user interface a lot simpler as you can just add onClickListeners to each view to capture user touches. If you're drawing it all manually to a Canvas then you'd have to interpret the touches yourself and decide which card was touched etc. While this isn't too hard, then I think subclassing View is a better model and will most likely result in cleaner code.
As you are only going to have 30 cards, then I can't imagine you having performance issues either - if you were thinking 100+, then maybe you'd have an issue, but I think you're fine. Also, if I understand your game correctly, the majority of your cards won't be animating most of the time so that's yet another reason not to worry - if you ever run into performance issues with the animations you can easily save off all the unanimated Views onto a Bitmap (Canvas) for the duration of the animation.
I'm working on a game that in some ways is similar to Tetris (imagine a 2D array of colored squares that sometimes move around)
I am trying to animate the individual squares so they will smoothly slide down from coordinate to the next. Since I wanted to use Android's built-in tweening feature, the animation has to apply to the whole View (rather than parts of it). This doesn't work well for me because I only want some of the colored squares to slide down, and the rest of them to stay still.
The (theoretical) solution I came up with to resolve this is to make 2 Views, layered directly on top of each other. The top view is for animating squares when they need to move, and the bottom layer is for the static squares. The animation-layer is transparent until I am ready to animate something. I then simply turn on the colored square in the animation-layer, tween it to the new location, and turn it back off when done. In the same time span, the static-layer just turns squares on and off at the right time to make the whole thing look seamless to the end user.
The proposed solution is just a theory, since I haven't been able to make it work correctly yet. Since I have been having trouble, I was wondering if this is even the best way to solve the problem? Perhaps there is a more elegant solution that I am over looking? Anyone know of a better way?
If you just want to animate a single element check out the namespace android.view.animation.Animation. You can also use Drawable shapes and draw them directly. Finally, if you want a simulation then you will have to look into threading. Basically you will create a timer to update the canvas for you based on an interval. There are some other view canvases you can use as well like the GLView canvas.