I have recently been trying to implement my first Android game using a similar approach to the infamous LunarLander. I am rendering the graphics myself without the aid of a game engine, and that seems to be the most complicated part of the endeavor so far.
The Problem
I am determining the width of the screen, and forwarding that information into an algorithm that determines the maximum number of images that can be rendered horizontally given the width and some other margin values (see calculateMaxBeadsInWidth() below). However, the mathematics seem to not be matching up to the values computed by the algorithm. Basically, it is determining that only X amount of images can be displayed, when in actuality X + 2 images can easily be displayed on the screen.
The Calculations
I have parsed many debug outputs that show that the actual width of the screen is 800 pixels, and the image width is 44 pixels. So, given that the margin is 100 pixels (50 pixels on the far left and 50 pixels on the far right), that leaves 700 pixels to work with. Now, floor(700 / 44) = 15, so only 15 images are shown. But there is clearly space for more (see pictures)!!
The Code
My algorithm:
private int calculateMaxBeadsInWidth() {
float eff_width = screenWidth - (BOARD_MARGIN_HORIZONTAL * 2);
return (int) (eff_width / bead_width);
}
Note that the value of BOARD_MARGIN_HORIZONTAL is 50.0f.
Some Pictures
This is what is being produced by my algorithm:
However, as you can see it is obvious that you could easily fit at least 2 more beads towards the end of the lines (on the right). For instance, this picture shows what happens when I hard code the number of beads in one row to two more than the algorithm is producing:
Here is the image with the margins detailed with red lines. As you can see there is still plenty of space:
Supplemental Information
I am testing this application on the Google Nexus 7.
I am using getResources().getDisplayMetrics().widthPixels; to obtain the width of the screen. Perhaps the issue is here?
My Question
Are there some resolution values that I am not taking into consideration here that are affecting the results? Why is this being computed so inaccurately?
If you need any more information I will gladly provide it, any help would be appreciated greatly!
Your margins are the wrong value. You uploaded full-size images, but if you draw vertical lines # 50px and 750px, they intersect the drawing area. So, you are either using the wrong value in your calculations, or somewhere else you are drawing in what is supposed to be margin.
Related
I am very beginner to game programming and Libgdx. I am really confused what camera viewport size should I use. In some articles i found that they used 480x800 which is same as target device size. In some articles I found the use meters as 5x5 meter.
So which method is better and how (if you can give some benefits).
If I use meter unites for camera viewport then which is first mapped, width or height.
If i use 5x5 meter for 480x800 pixels device then visible area of world
height = 5 meter = 480px and
width = 800/480 * 5 = 8.33 meter
or
width = 5 meter = 800px and
height = 480/800 * 5 = 3 meter
Is it correct calculation of visible world size and which is used first or second.
I am confused when they start using meter for size everywhere instead of pixels. like actor size is 1x1 meter even it is only 64x64 px. It is really difficult to estimate position and size for me.
Please link any good article about camera and camera units.
Whatever dimensions you specify, they'll be mapped to the entire screen by default. If the aspect ratios don't match, the displayed graphics will be stretched. So if you set your camera to a 5x5 coordinate system on a non-square screen without changing the drawing area, it'll be heavily distorted. If you render it in a square desktop window, it'll be fine.
The advantage of using smaller coordinate systems is that it's easier to calculate with, and possibly more meaningful in the context of a game - e.g. you can think of them as meters, as you said. It's useful in cases where the content matters more than the exact positions on the screen - like drawing the game world.
Using larger coordinates which match the resolution of some devices can be more useful when you're drawing UI. You can see how large you should make each image, for example, if you target that resolution. (Scaling can cause distortions.)
But ultimately, it's a matter of preference. Personally, I like smaller coordinate systems more, so I recently coded my level select menu in a 20*12 system. (I did run into problems when rendering a BitmapFont though - they were not very well made for scaling like this.) Others might prefer to work with resolution-sized coordinates for gameplay rendering as well. What matters is that you should make sure you're not distorting the graphics too much by badly matching aspect ratios.
try 136 for Width and 204 for Height
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 am trying to make an app whereby a picture will be shown, there're a few objects that user needs to identify (i.e. a cup), by touching the cup in the picture on the screen, a circle will be drawn if it's valid.
So far, I have a surfaceview with a bitmap as drawable to be displayed full screen, and upon touching the screen, a circle will be drawn to the view.
I could only think of getting the coordinate of the cup manually in the picture(hardcoded), and check it against the coordinate from touch event.getX() and event.getY(). But this would not work as screen resolution changes.
What is a better way in doing so? It's like I'm trying to find a way to precisely allow touch on certain areas which I've defined in my app.
You can store the coords as you were suggesting but adjust them based on the size of the SurfaceView vs. the size of the BitmapDrawable. For example, if you know a given area is 100px from the left, you could take your scale as surfaceView.getWidth() / bitmapDrawable.getIntrinsicWidth(). Multiply your scale times your value (100px) to get the final position. If you're keeping the same aspect ratio on the image, you need to get your scale from the larger of the two (width vs. height) and use that same scale for height and width.
In a given resolution, is the location of cup fixed or it varies there as well.
Also, what about the orientation (landscape, portrait)? does the location change accordingly as well?
There are standard resolutions, so you can always think of mapping the location with resolution.
Also, you can get X, Y coordinate and check if it falls within a range based on height and width of cup image.
First of all find out the size of screen (screen dimensions).
Now place objects relatively corresponding to your screen area.
eg. keep cup on SCREENWIDTH - 60 and check coordinates of touch similarly.
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.