I've been writing a 2D Surfaceview game for what seems an eternity now and I simply cannot get my head around screen independence for Android.
Basically, my sprite jumps like so: Y value is decreased by an amount (I call it the 'step amount'), then the step amount is reduced by say, 1 and that goes on until the step amount is a negative number which then in effect gets added to the sprite's Y value and it 'falls' back down - works perfectly (This is the way I've always made sprites 'jump').
The problem comes when I run this on a different DPI screen - it still works, but the sprite jumps to a completely different height relative to the screen size.
I understand why this is happening, but I just can't work out a way to fix it!
How do I get it 'jumping' to the correct height on all screen res? (I'm working mainly with 160 and 240 DPI at the moment)
Thanks, would really appreciate any comments.
Regards
Related
I want to recognize shapes like a circle,triangle and rectangle which is drawn on screen.My main aim is a user draws a shape on screen and I need a code to recognize this shape.How should i approach this problem?
What you are trying to achieve can be quite tricky, but I happened to implement something similar a while ago, and here is the approach that I used:
stick to black & white drawings
have a smallish database of (black & white) drawings (50 or so) with a fixed resolution, let's say 256x256 (you can store them in sqlite as binary blobs if you wish). Make sure that you use decently thick lines for these drawings (10 px should be OK, or something about twice as thick as the user's input drawing). Also, the drawings should be normalized, meaning that they must have at least one of their dimensions as large as the image itself.
extract the shape drawn by the user and process it:
a) if it has an aspect ratio close to a square, then simply crop the white space around it and enlarge it such that it has the same size as your database images
b) Otherwise, it will most likely have one dimension about two times larger than the other one, in which case you crop the white space, rotate it to have the height as it's biggest dimension, enlarge it to 256x128 and then add on both sides 64 px of white space.
you'll have to compare your drawing with each of your database images pixel by pixel and determine the amount of black pixels which overlap for each database image. Then you sort these numbers and you'll get the best match. Even if the best match has less than 20% overlapping pixels, the results are usually good.
Because some shapes can be considered the same, even if they are rotated (imagine various ways to place a triangle in an image: one tip pointing up, or down, or towards one side etc), you'll probably want to rotate your input drawing around 12 - 24 times (by 15 - 30 degrees at each step) and compare each rotation to every image in your database. Given that this step will most likely require a lot of processing power, you might consider storing all the rotations of your initial database drawings in the database, as different pictures, thus making the database bigger, but saving you the effort of rotating the input image, which is costly.
Given that the above algorithm is a bit of a resource hog, you might consider having a server somewhere, which can do the actual comparisons, especially if you want to add many images to your database. Since I already implemented this algorithm for a demo application, I can already tell you that you're going to have to do a lot of pixel operations. Also, rotating images with the Android SDK can be annoying, because it changes the image dimensions...
If you are feeling adventurous, here are a couple of papers describing state of the art algorithms for tackling this problem: "Shape contexts enable efficient retrieval of similar shapes" by Greg Mori, Serge Belongie and Jitendra Malik (2001) and "Shape Matching: Similarity Measures and Algorithms" by Remco C. Veltkamp (2001). The maths might be a bit heavy, though.
You should look into GestureOverlayView.
A good tutorial is: http://www.vogella.com/articles/AndroidGestures/article.html
This is my first post, so I apologise in advance if I have done anything wrong here in asking my question. I've looked all over the net for a specific answer, but can't find one, so here goes.....
I'm writing a game based on Surfaceview and so far, all is going well, however, I want to move my main sprite for example by 1 pixel on a 160DPI screen as a baseline (so basically 1 DIP as 1 pixel = 1 DIP on a 160DPI screen correct?)
I'm using the using the following forumla:
private static final float spritemovestep = 1f;
final float scale = getResources().getDisplayMetrics().density;
MoveX = (int) (spritemovestep * scale + 0.5f);
And then... something like
SpriteX=SpriteX+MoveX
First question - is this correct?
If it is, can someone explain what the +.05f is actually for, I've read that it's to 'round up to the nearest number' but....
if spritemovestep = 1, then on a 120DPI screen (which returns .75 as the scale I think) it would work out as: 1 x .75 + .5? which would be 1.25? So what is the .5 for?
Also what is the result when it's cast to an int value?
On some, the final result seems to be '0' on a low density screen so the sprite isn't moving at all.
Also some sprites which are supposed to be moving at different speed are moving at the same speed at certain densities.
I'm sure I'm being silly and missing something here but I just can't understand how this is supposed to work. If I want to move my sprite by 1 DIP/physical pixel on a MDPI screen how can it move less than 1 pixel on a LDPI screen?
Also, what is this formula I keep seeing:
px = dp * (dpi / 160) - When is this used?
Would really appreciate if someone could answer my questions.
Thanks all
The +0.5f is to round up to the nearest nukber, as you said. Ideally, when the number is scaled down for ldpi, a value of 1 becomes 0.75, which, when cast to an int is expressed as less than 1 or ~=0. By adding the rounding figure, this number is raised to 1.25 which, when cast as an int yields <2 or ~=1. This way, your sprite should be drawn with a minimum movement of 1. The only reason sprites that move at different speeds would move the same speeds is if they are so close that, when rounded, they wind up being the same size using the scale you gave. Altogether, your equation is very similar to others ive seen. Im making a game that uses surfaceview for the company i work for as well, and while i cant go into details on the code, your issue is one that i struggled with for sone time. Im not sure how your physics updates, but perhaps thats something you should check into, specifically, how it counts ticks for your game timer. It may be that your application is reading its ticks as being too close together to reach the point where it would hit the point of moving the 1.25 or 1 after casting to int, and therefore your sprite appears not to move. I briefly experienced that problem and at first was looking at my velocity until i found that the error was in the timer. One other thing i noticed is that your algorithm collects the density. On a mdpi device, does this return 1 or 160? That could make a big difference, but im not sure, as the equation i used was different. The other equation you found is a paraphrase of the equation listed in the development guide at android.developer.com to describe how the os converts pixels into dip. The reson people tend to quote that is to provide a reference to help others build their own algorithm for scaling appropriate for the jeeds of their app. Hopefully that helps, as its really the best answer i can give at this time. Sorry for any typing errors, im sending this from my phone
I'm looking for an Algorithm or Pattern to calculate where objects can be placed on multiple resolutions. So far, I have got the X and Y screen size, but im not sure how to turn it into a calculation that would place something such as a drawText() at a location on the screen no matter the screen size.
I was thinking perhaps using percentages might be easier to work with. I have a program that draws text to the screen at the top left corner indicating what position the screen has been touched.
when i run this on the emulator, with the
drawText(info, 10,10, paint);
it displays great, but when i run it on my phone (Droid 2 Global) the top of the text is cut off.
In short:
Is there any way to draw something to the screen (using SurfaceView) that will remain in the same spot over multiple screen dimensions / dpi?
Thanks for your time.
It's no perfect solution that i've seen so far.
I came across this issue by specifying the position for the particular item for the specific screen ratio(native screen resolution in an emulator), then recalculate its position and scale it up/down when running it in the different screen size.
displayXpos = constDevelopmentScreenXpos (targetDeviceScreenHeight/constDevelopmentScreenHeight) etc..
displayXScale = similarAlgorithm
This is not the best, but it give you some idea.
Also, i fill some 'limbo' area with a background and choose to not care it when the target device X:Y screen ratio is different from development device.
HTH
ya, it is better to use calculation in percentage
first get the total size avail of the screen, then calculate percentage on it and the place the control based on calculation
to get avail size
Display mDisplay= activity.getWindowManager().getDefaultDisplay();
int width= mDisplay.getWidth();
int height= mDisplay.getHeight();
I've got an image that is 800 by 300, which I know is the width of my test platform's resolution (HTC Desire at 800x480). When I try to draw this image to the screen it scales oddly. It spills over the left hand side of the screen and fills almost all the vertical.
I'm using code like this:
canvas.drawBitmap( screen[1], new Rect(0,0,800,300), new Rect(0,0,800,300), null);
For some reason
width_x = canvas.getWidth();
width_y = canvas.getHeight();
reports my resolution as 533 by 320. Now I assume this is for the expletive-deleted fascinating scaling system Android uses so apps appear the same size on all phones but I want to ignore this. I'm writing a game, so want to handle scaling and positioning myself - for instance using more screen estate if it becomes available. Best Android practice may be suitable for an icon based application, but I would like to draw to absolute pixel positions, and get absolute resolution information for the screen.
Therefore my question is this - is this absolutely impossible? If it is completely contraindicated because Android has a simple and effective system in place to do this then I would be interested to know what it is. Dpi is not relevant to my game design (just like if this was a pc game, it would be irrelevant)
Perhaps my screen actually 533 by 320 unless I specify a resolution somehow? I tried using the scaling values from width and height and the image was the correct size on screen, roughly, but had jagged edges because some sort of scaling had occurred. I therefore did not have access to all the pixels my screen is capable of displaying.
To scale it I used something like
canvas.drawBitmap( screen[1], new Rect(0,0,800,300), new Rect((int)(0.0f),(int)(0.0f),(int)(533.0f),(int)(187.5f)), null); // numbers
Just whacked in for testing - ratio equivalent to reported screen resolution. Looks horrid.
Android is not doing anything to mess with your perceived resolution - you are working with 800x480 pixels on that Desire.
Are you working in a fullscreen, custom View and overriding onDraw? Are you working with a SurfaceView? We need to know these things before we can help you with your problem.
Assuming you are doing the above, you should be able to draw your bitmap to the screen without any scaling using Canvas.drawBitmap(Bitmap bitmap, float left, float top, Paint paint). In your case, that would look something like canvas.drawBitmap( screen[1], 0.0f, 0.0f, null); to put it in the upper left corner of your canvas.
In performance-sensitive apps (like games), you don't want to use the source/destination Rect version of drawBitmap() during your draw loop, since it will do the scaling during every iteration of the loop. Instead, draw a scaled/cropped version of your original bitmap to another member bitmap, and draw that one in the loop, using the x/y offset version of drawBitmap linked above.
If you want to know the amount of screen real estate you're working with (and you definitely should, if you're doing any custom drawing), you'll want to override either onSizeChanged() or surfaceChanged(), depending on implementation.
You should really check out the API demos, there are some great examples of how to do exactly what you're trying to do in there.
Good luck!
I fixed one of my problems - in the manifest file the OS I was targeting was set up incorrectly - switching it to 4 (i.e. 1.6) seemed to fix the values I was getting for height and width, at least for the HTC. Emulator is more problematic, but at least its a major step in the right direction. For your info, I'm working in full screen, landscape mode (fixed), with overridden functions for pretty much everything. (Including onDraw, surfaceChanged, and so forth)
If I can get the absolute width and height I can write my own code for loading the correct assets and using the correct scaling for screen positioning - DPI isn't an issue so hopefully that won't stray too far from suggested guidelines.
How to draw, say, a rectangle on the screen with it being proportional to the current device?
e.g. a rectangle, centered on the viewport, one pixel smaller than the screen on each border.
I can live with Orthogonal, but would like perspective (basically everything at Z=something should be proportional to the screen, and the upper parts of the elements being distorted by perspective)
I can calculate everything on my own if i know the relation... but i don't have a starting point.
I could experiment and get to a relation myself... i even resorted to that while coding for the Wii, but that's a really bad decision on Android and all the screen ratios/sizes out there...
seems that at z=1 you can fit in the screen all -1,-1-1,1 quads.