I have an image (588x449) sprite with a collection of different team logos. In Android I have the corresponding ImageView displaying this:
<ImageView android:id="#+id/image_team_logo"
android:src="#drawable/teamheaderssprite"
android:layout_height="25dp"
android:layout_marginLeft="5dp"
android:layout_marginTop="10dp"
android:layout_width="296dp" android:scaleType="matrix"/>
The above will correctly display the piece of my image in the upper left hand corner. My issue is I want to be able to move the position in the image being displayed so I can jump to another area in the sprite. This is pretty common practice in html/css, I am just not seeing a 'position' type property in android xml.
You can't use sprites in the same way on Android you can with HTML. There is one way I can think of to simulate sprites though: Lay the sprite out entirely horizontally (or vertically), then use a ClipDrawable to define each level as a new part of the sprite. Then define the level of each View as appropriate. (If the images in the sprite aren't all the same size, you may need to use InsetDrawable as well.)
However, I would seriously rethink using sprites in Android. There are reasons why web pages use sprites, and it's not because they're easier - it's because it speeds up webpages because you don't have to make multiple HTTP requests. Since the images will already be in your release APK, you don't gain anything by spriting them.
Not only that, but you're doing some harm by spriting on Android:
Memory constraints on some Android phones are much lower than you might expect. If the entirety of your graphics are in memory at any given time, that lowers the amount of memory you have for everything else.
Sprites will be harder to handle once you start writing for different screen densities (ldpi, mdpi, hdpi).
Related
I need to make a 2d map which lays out levels for a android game. It is low budget and I need to make it with native android components.
The map goes to a finite number of levels so I do not have to generate the map dynamically and using the technology suggested in http://forum.unity3d.com/threads/smart-2d-levels-map.267394/
will be a bit of a over kill.
I also got a heap of motivation from How to create a 2D Map to use in a Android Game? as they said that it is possible to achieve what I need without a engine.
All I am enquiring about is if I should make a scroll view with a relative layout inside and then align the real buttons relative to each other in px (as dp will make that the images will not line up in all cases as the background which is a image is in px) or should I approach this completely differently.
My biggest concern with my initial thought out approach is that the different screens will mess with the locations of the buttons and that if I make everything px that the screen will be to small for high density screens.
I have considered to make different layout files for the different screen sizes but before I start developing I thought that it will be best to get another view point from the community
Thanks in advance for the feedback.
I have played around with using a relative layout and this seems to work on all screen sized after I set the height and width to static dp values. This makes the ratio constant and makes the solution acceptable on any screen size
I still have trouble understanding the possibilities of Scaling my UI in a responsive way in my Air Mobile App. On the web I'm familiar with it and the use of media-queries.
I dont want to scale my whole UI up and down or even stretch it (e.g: I use the camera in one DisplayObjectContainer, so this would be really bad for the performance to scale this.)
I currently go down the road defining all the container sizes by percent, but that is getting pretty ugly pretty fast as it leaves me with 68.95px values. I think this will get me in trouble one day as blocks appear not crisp anymore. If I round the values, I might have 1px gaps between Elements.
Currently I have this Setup. The idea is, to give every main Component a (maybe invisible) empty background-child. These can then deformed by width & height by any desire. The inner Elements of any Element (button, logo, etc) are not affected by the deformation of the bg and can then be arranged accordingly (as I now have position and size of this container - like in css).
But this does not feel like it is the right way.
Is there a magic lib/class I dont use currently and that allowes me to build in hard pixel for a defined setup and behaves appropriate when it comes to different stageWidths, DPI, etc?
What are your approaches for this problem?
I am creating a dress up game, and this involves putting lots of images on top of each other. The application by itself can work fast with no lags, but if a slide animation is added to the item to be dressed when the character is fully dressed (10 images or more on top of each other), a bad lag happens. I believe this happens because the OS invalidates all the ImageViews and draws them all again. The images are of png type and they mostly are around 10 kilobytes.
Would using graphics and drawing on the layout make it faster? Or would it be the same thing as setting images from resources?
I can't actually try it right now because it involves a major re-writing of the code.
If you implement the app using OpenGL, it should be more faster than now. Before doing that, you might want to double check that you have all the image resources scaled correctly for the target devices (mdpi, hdpi, xhdpi, and xxhdpi). Scaling up drawables in runtime can cause a significant performance penalty on some devices, especially for animations.
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