I am looking at creating a 2D birdseye view of a map where the user is basically working their way through it.
Is there a way that I can create the whole map in 1 go and store it somewhere, then simply only display a certain section of that map during game play?
e.g map size =100 x 100 but user can only ever see 5x5 (which is zoomed-in to use up 70% of the screen).
It might use too much memory if you store the whole 100x100 map as a bitmap/texture in memory and only display a certain part. I think you'll be more happy if you divide it into chunks of e.g. 5x5 and cache these chunks (only those that are visible and drawn right now). When the user moves and gets to a new chunk, you just draw the 5x5 tiles on a bitmap/texture and cache it for as long as it's visible (and unchanged).
I want to be able to dynamically place image(s) over another image in my app.
Consider the first image as background and the other images to be on top level, I will also need to move those top level images (change their x and y on the screen) by code too.
Imagine, for example, a sea in which the user places fish and sea animals, then those sea animals start to move here and there on the screen: it will be like that.
How can I do this? If you don't know but remember any simple program or demo that does that, it will be also very welcome!
Thank you!
There is, of course, more than one way to do this, but I would say that the best way to do it would be to create a custom View (class that derives from View) and have this handle your bitmap drawing and all of your touch events.
There's a lot of code to write for loading the Bitmaps and keeping track of all of their positions (and then drawing them to the canvas in onDraw), but if you start really small by just allowing one image to be drawn and dragged around the screen, you can build on that and keep your code organized.
You would need to override onDraw(Canvas) and onTouchEvent(MotionEvent) in your custom View. You'll load your bitmaps with BitmapFactory (decodeResource method if you're including your images as resources in your project) and you'll need to remember to call recycle on your bitmaps when you're no longer using them.
In onDraw, you draw your bitmaps to the canvas at a specific location using Canvas.drawBitmap. There are two overloads of this method you can choose from, one that takes the top and left coordinates of the bitmap as floats (and therefore performs no scaling or stretching) and one that takes a destination and source rectangle to perform scaling, stretching and placement.
I always use the latter as it gives me finer tuned control. If you choose this route, you'll want to keep two Rect instances and a Bitmap instance for each image being drawn, update them in the touch events and draw them to the canvas in the draw event.
When something changes inside your view (as in the case of a touch event), call invalidate() method and the framework will know to redraw everything which triggers your onDraw method.
I need some help with this simple animation on my Android phone. I'm a newbie with animation and graphics.
I'm graphing accelerometer data as a sliding time series window. As new accelerometer data is read, its data is plotted on the right, pushing previous data to the left, as shown below:
My program is running pretty smoothly, but I would like some help optimizing the animation. Here are my main concerns:
My current implementation reads all the accelerometer data in one thread and keeps the data in a fixed-size FIFO queue to capture the width of the time series window. I then use Timer.scheduleAtFixedRate() to plot out the entire contents of the queue so that the whole graph is re-drawn every 50 milliseconds. Can I improve upon this? Do I really need to re-draw the graph so often like this? In another similar program I've seen, each pixel column is copied to one pixel to the left, rippling down the graph; the newest data's column is drawn on the far-right pixel column. Is this better?
I redraw the legend (in the upper left) in the drawing thread that runs the draw function every 50 milliseconds. Is there any way to "keep" that legend in place instead of having to constantly re-draw it?
Any other help would be appreciated. I have heard of optimizations like double-buffering but am clueless if that would help me.
If the legend and the cross hairs only need to be drawn once, then you should place it into a buffer bitmap. For your graph line maybe try using the Path object to plot the lines. When it gets time to draw the lines just drawLine to the appropriate point and then translate the canvas left appropriately.If
I have a scrollable and zoomable map which has a low res copy of the map which is drawn when the zoom scale is small and a tile system when the user zooms in past a certain point. The problem im having is that the very first time the tiles are drawn there is a short, but noticable lag. After that initial lag everything is smooth. The GC isnt running, and all the bitmaps are loaded at launch time. Any idea what exactly is going on so i can take care of the lag? Or any way for a work around? Thanks. Heres the code below:
canvas.drawBitmap(map, null, bgRect,paint);
if(matrix[0]>.9){
mapPicture = makeMyMap(xScale,yScale); //make/update our map.
mapPicture.draw(canvas);
}
Try switching on tracing with DDMS to establish which methods take a long time on the first draw and see how they compare with the subsequent draws.
It's possible that drawBitmap is triggering the platform level up-scale / down-scale of the images on first draw rather than load - but that's speculation on my part.
I'm tried to determine the "best" way to scroll a background comprised of tiled Bitmaps on an Android SurfaceView. I've actually been successful in doing so, but wanted to determine if there is a more efficient technique, or if my technique might not work on all Android phones.
Basically, I create a new, mutable Bitmap to be slightly larger than the dimensions of my SurfaceView. Specifically, my Bitmap accomodates an extra line of tiles on the top, bottom, left, and right. I create a canvas around my new bitmap, and draw my bitmap tiles to it. Then, I can scroll up to a tile in any direction simply by drawing a "Surfaceview-sized" subset of my background Bitmap to the SurfaceHolder's canvas.
My questions are:
Is there a better bit blit technique than drawing a background bitmap to the canvas of my SurfaceHolder?
What is the best course of action when I scroll to the edge of my background bitmap, and wish to shift the map one tile length?
As I see it, my options are to:
a. Redraw all the tiles in my background individually, shifted a tile length in one direction. (This strikes me as being inefficient, as it would entail many small Bitmap draws).
b. Simply make the background bitmap so large that it will encompass the entire scrolling world. (This could require an extremely large bitmap, yet it would only need to be created once.)
c. Copy the background bitmap, draw it onto itself but shifted a tile length in the direction we are scrolling, and draw the newly revealed row or column of tiles with a few individual bitmap draws. (Here I am making the assumption that one large bitmap draw is more efficient than multiple small ones covering the same expanse.)
Thank you for reading all this, and I would be most grateful for any advice.
I originally used a similar technique to you in my 'Box Fox' platformer game and RTS, but found it caused quite noticeable delays if you scroll enough that the bitmap needs to be redrawn.
My current method these games is similar to your Option C. I draw my tiled map layers onto a grid of big bitmaps (about 7x7) taking up an area larger than the screen. When the user scrolls onto the edge of this grid, I shift all the bitmaps in the grid over (moving the end bitmaps to the front), change the offset of grid, and then just redraw the new edge.
I'm not quite sure which is faster with software rendering (your Option C or my current method). I think my method maybe faster if you ever change to OpenGL rendering as you wouldn't have to upload as much texture data to the graphics card as the user scrolls.
I wouldn't recommend Option A because, as you suggest, the hundreds small bitmap draws for a tiled map kills performance, and it gets pretty bad with larger screens. Option B may not even be possible with many devices, as it's quite easy to get a 'bitmap size exceeds VM budget' error as the heap space limit is set quite low on many phones.
Also if you don't need transparency on your map/background try to use RGB_565 bitmaps, as it's quite a lot faster to draw in software, and uses up less memory.
By the way, I get capped at 60fps on both my phone and 10" tablet in my RTS with the method above, rendered in software, and can scroll across the map smoothly. So you can definitely get some decent speed out of the android software renderer. I have a 2D OpenGL wrapper built for my game but haven't yet needed to switch to it.
My solution in a mapping app relies on a 2 level cache, first tile objects are created with a bitmap and a position, these are either stored on disk or in a Vector (synching is important for me, multithreaded HTTP comms all over the place).
When I need to draw the background I detect the visible area and get a list of all the tiles I need (this is heavily optimised as it gets called so often) then either pull the tiles from memory or load from disk. I get very reasonable performance even on slightly older phones and nice smooth scrolling with no hiccups.
As a caveat, I allow tiles not to be ready and swap them with a loading image, I don't know if this would work for you, but if you have all the tiles loaded in the APK you should be fine.
I think one efficent way to do this would be to use canvas.translate.
On the first drawing the entire canvas would have to be filled with tiles. New android phones can do this easily and quickly.
When the backround is scrolled I would use canvas.translate(scrollX, scrollY), then I would draw individualy one by one tile to fill the gaps, BUT, I would use
canvas.drawBitmap(tileImage[i], fromRect, toRect, null) which would only draw the parts of the tiles that are needed to be shown, by setting fromRect and toRect to correspond to scrollX and scrollY.
So all would be done by mathematics and no new bitmaps would be created for the background - save some memory.
EDIT:
However there is a problem using canvas.translate with surfaceView, because it is double buffered and canvas.translate will translate only one buffer but not the second one at the same time, so this alternating of buffers would have to be taken into account when depending on surfaceView to preserve the drawn image.
I am using your original method to draw a perspective scrolling background. I came up with this idea entirely by accident a few days ago while messing around with an easy technique to do a perspective scrolling star field simulation. The app can be found here: Aurora2D.apk
Just tilt your device or shake it to make the background scroll (excuse the 2 bouncing sprites - they are there to help me with an efficient method to display trails). Please let me know if you find a better way to do it, since I have coded several different methods over the years and this one seems to be superior. Simply mail me if you want to compare code.