I am developing a 2d android strategy game, it runs on SurfaceView, so I can't(or can I?) use LibGdx's particle system. And I would like to make a raining effect, I am aiming for something like this( http://ridingwiththeriver.files.wordpress.com/2010/09/rain-fall-animation.gif ), I don't need the splash effect in the end (although that would be superb, but probably would take up a lot of system resources). How could I achieve that raining effect? Any ideas?
There's one similar code from JakeWharton called DroidFlake. It seem like snowfall effect but worthy to check DroidFlake
The easiest would be to put the rain drops in a PNG with alpha and display that at the end. You would only need a few frames to make it smooth, but it would eat up a bit of resources if this were a full screen image.
If you cannot afford this, you could put each distinct raindrop in a smaller PNG file with alpha, then display this (these) single PNG(s) multiple times. This would reduce the memory used a lot, although your rendering code will get a bit more complex, and depending on how many drops you have, it might affect performance.
A trade-off between the two would be to have a PNG file that contains more drops, but not for the full screen, and display that a few times.
You could have another frame (or frames) where the raindrop splashed, which you could display before ending the animation of each drop, or you could have the final frame in the large PNG contain the splashes.
There are many ways of doing this. You could create a sprite sheet like:
In that spritesheet, you could simply have a drop of water advance in each frame until it reaches the bottom and you create the splash effect. You then need to be able to animate it (very easy). You can then create multiple instances of the image, or draw the one image multiple times to create the rain storm.
Related
I writing a image compositing app where it should be possible to arrange images on different layers. So what I currently do is to merge (draw one bitmap after another) on a canvas.
The user should be able to remove any of the layers at any time (also undo).
My problem is related to memory management: I fear OutOfMemoryExceptions when keeping every layer as bitmap object in memory. But merging is a problem: As soon as I merge all bitmaps, there is no way to separate them again (obviously).
I was wondering about saveLayer, it seems you can save and restore data, but I don't really understand whether it could be helpful for me.
I thought about reducing the resolution of the images on the layers, but then the question "which resolution is the right one?" pops up. After all the resolution would depend on the (dynamic) amount of layers and the available system memory.
Anyone has a proposal on how to handle this requirement?
For the merging problem, what if you instead had multiple canvases, perhaps as part of a custom ImageView, which you dynamically add as layers in a FrameLayout? The compositing part would then be simply handled by the layout, and you could your make your draggable images appear/disappear without redrawing the unaffected images simply by adding/removing views from FrameLayout.
For the memory issue, I can't think of many ideas except to a) set the max res of each layer to something sensible given the devices screen size, b) experiment with using compressed bitmaps like Bitmap.Config.RGB_565 (with a perhaps unacceptable compromise in color fidelity), c) query the usable heap size and limit the number of layers accordingly.
I need to put together a complete image, as seen here. Each piece of the segmented tree is an individual image, but I am unsure about how I should put the pieces together efficiently with spacing in between. I've thought about stacking the images on top of each other one at a time within a canvas, but I have my doubts as to whether this is the approach that I should take. Is there a different type of container I should use or a better method of accomplishing the same task?
EDIT: just to clarify, I need to assemble the image programmatically, beginning with the base segment and eventually ending with the top segment.
If you use a program like Gimp, you can added each image as a layer, then move the layers around correctly. I'm not quite sure how you want to represent the space between the segments, transparent?
Any way after you have your image assembled the way you want you can either merge the layers or save it to a format that will flatten out your images.
I'm not sure if you want your image to be able to stretch at all or not. If so, you can save it as a .png file and then use draw9patch or equivalent to add in stretching segments. Also I'm not sure if you have to support multiple drawable sizes, if so I have a free Android app, DP Image Calculator on Google Play that might help. Just remember start with the highest resolution and work you way down to the smallest.
Hope this helps. If you have more question let me know. Have a great day.
I am wondering what would be the best practice for android. To draw or to load an image?
For example I want to have a circle that is green filled with the text 25 in it.
-Should I have it in .PNG image file and just load it to the imageview placeholder when I need it?
OR should I load it in Java (by determining the position in java and load it from my res folder)?
OR Should I draw it (draw a circle, fill color, add text field inside)?
On another note, to have a checkmark, what do advise me to do?I don't even know how to draw that
I really need your help in this
Thank you so much
I'd actually argue that there is a single right answer. You should use a shape with a set color and text view inside it. It is easy to do what you've described in xml, see: Oval Gradient in Android for an example (there are a number if you google for android shapes). This will be less CPU/memory intensive than loading a bitmap, and more importantly, it will work for and look good on every screen size. As an added bonus of the user has changed their default font sizes, a textView/shape can respect that and a static image can not. Just set the background of your TextView to be the shape drawable (either in xml or programatically).
To get a bitmap to look good on multiple devices (a must for android development) , you will need a number of different versions of the same bitmap at different resolutions (XHDPI, HDPI, MDPI... etc).
Check marks are harder because they don't conform to a standard shape. Those you probably will have to make pngs for.
It depends on what you want to do.
Rendering a bitmap will be faster, but you cannot manipulate it after it is drawn.
So, for your case, you have a green circle with 25 written it. Do you also need a green ball with 23 and another with 24 in it? What about other colors?
It really depends on the amount of variation you need. At a certain point the overhead of using dozens of images will not be worth the evert of drawing to a canvas. Or, depending on how complex the images are, it will be.
The question is not "Which is better?", but instead, "Which is better for what I need to do?"
I'm not an expert on Android development but after seeing your question I have done a bit of reading and came across this article on displaying images with android that is relevant and includes some code to possibly help you out. http://www.javacodegeeks.com/2011/07/android-game-development-displaying.html
As for your image of a check mark, why dont you just go into photoshop or paint and use the line tool to draw a checkmark and then fill it in with color and save it as a .png perhaps?
I am developing a 2D game for android using lots of sprites. I am drawing on the screen using OpenGL ES. I separeted the sprites into several pictures (around 7). I read, that loading a picture into memory takes most of the time. Every picture contains a diffrent category of images: for example - background elements, enemy units, etc, etc. I load them in a defined order: background picture first, so background elements are drawn at the bottom, then the enemy units, etc. But what should I do, if I want to draw elements of the background at the top of the canvas. Should I load the picture with background elements twice? Or store that special element in both pictures - the background picture and the picture containg top elements. Or there is a better way? Thanks!
Loading has nothing to do with rendering. As long as you render something after you've loaded it, then you're fine. The order that things get rendered in is not affected by the order you loaded them in.
Now, if it's an issue of memory (ie: you can't load everything at once), then the steps you need to take depend greatly on exactly what you're doing. We can't really give you anything more than general advice, because we don't know everything about what you're doing.
In general, you need to break down your rendered world into chunks that fit in memory. This will put constraints on your design: you can't use stuff (be it backgrounds, enemy units, whatever) from outside of that chunk. Since you're developing on limited platforms, you're just going to have to put up with those constraints.
I'm entirely new to Android development, and I'm interested in making a live wallpaper. I was thinking about looping a set of pictures instead of drawing the animation. Is this a possible approach? If possible is this a suitable or ideal way of doing it, does it eat up memory and would i need images with different resolutions because of the fragmentation?(hundreds of different devices)
Thanks in advance :)
Sure, it should be fairly simple.
The main part of the Wallpaper engine is the Drawing of course. You need to handle the drawing manually, there is no easy way to loop through images... you need to code it. You will have to continuously monitor the time which has passed and adjust the displayed image based on that. You are given a Canvas object to draw to and it is all done during run-time in code.
The Wallpaper engine class has a event called onSurfaceChanged which gives you the width and height of the Surface which you will be drawing to. It will be called everytime the screen dimensions change (like if the phone is put into Landscape mode for instance). You need to have code that will handle any combination of width or height for all the device types out there. You will need to decide if you are going to stretch, center, tile or crop (Or a combination of those) the source images to fit any particular screen size. I would recommend scale to fit so that the image is either taller or wider than the screen and center the image either vertically or horizontally (cropping the extra bits) once that is done. I personally just use one source size and resize it to fit. You can opt to use several source files if you want which is the recommended approach I believe, but it's a little confusing.
I would start by creating a Live Wallpaper which just draws something basic like a shape to the screen. Then work out how to display an custom image and take it from there.
Good luck
You will need to be very careful about memory if taking a frame approach to animation--probably will not be possible to animate full frames--much more practical to move sprites on a background. See, fr'instance: http://davidjhinson.wordpress.com/2010/05/19/scarce-commodities-google-android-memory-and-bitmaps/
what if you have a png frame animation that is set at a certain x and y position that sits in a spot on the background image, both would have to be rescaled