Hi all

First post here, so sorry if this isn't in the correct forum

I'm having problems finding the answer to my question. I'm using surfaceview and pretty much designing everything in code (no XML) - I'm OK with displaying graphics for multiple screens etc.... but just wondered, when moving a sprite, say for example from, left to right across the screen should the value you move the sprite by each time be an explicit value? Or some kind of density independant value?

Example, psuedo code may be something like:

spriteX++;
or spriteX=spriteX+1

I'm just thinking, doing this, would make the sprite move quicker on a lower (120dpi) density screen and slower on a higher (say, 240 dpi screen), when what I really want is for it to appear to take roughly the same amount of time to cross the screen on all density's - how would I get around this?

Thanks all!! Hope someone can help me out.

It's not the screen size you should be worried about, but rather the frame rate.

Hi Jonbonazza

Many thanks for the reply, could you possibly elaborate? I've already got the frame-rate limited to 30FPS and am using frame-skipping for when the previous draw doesn't complete in time (think I've explained that correctly!)

The issue I have is simply that, lets say, when my character jumps and lets say I've got the initially value to move by 10 pixels up, then 9 etc.... until 0, then to reverse, on a lower density screen will he not appear to have jumped higher (in relation to the rest of the things on the screen as there are less pixels per inch) and take a much smaller jump on a higher density screen?

This is really what I'm worried about, maybe I've got it all wrong, but what I'm looking for is speed and distances to be fairly consistent across all screen densitys.

Maybe I've got it all wrong and it's OK to specify explicit values to move objects?

I hope I'm explaining this correctly

Would appreciate any thoughts you have on this.

Regards

This is a bit of a pain, but the first thing you have to do is drop pixels as the unit of measurement in your game. Don't think that you have to move 10 pixels, think more you have to move 10 units. So, regardless of resolution, you know that a jump is a 10 unit vertical movement.

Now, right before you actually draw your elements, you have to decide how many pixels one unit is. To do this, you must establish a baseline. The baseline is what resolution your art assets are (this is ignoring mdpi,hdpi,xdpi asset folders and assuming all assets are in no-dpi). So, lets say you have all your assets are mdpi (160 dpi). Now you need to draw your images onto a hdpi (240 dpi) screen. To do this, you simply apply a fixed scaling factor which is always

target dpi / baseline dpi

Do we have 240 / 160 = 1.5. So that means, every unit in your game is 1.5 pixels on the target resolution. So to draw, you first scale your target image by 1.5x, and then you scale your position data by the same amount. Draw the scaled image at the scaled coordinates.

Hi Mark,

Thanks very much for the reply, it's helped a lot!

I have some questions if you don't mind. if I do the 240/160 calc - then, as you say, my 'dp unit' is going to be equal to 1.5 physical pixels, when I specify a dp unit from that point on as a measure of how much to move a graphic/sprite by, how does the system move the sprite by 1.5 physical pixes?

Or, put another way, a 160 DPI screen 1 dp would be equal to 1 pixel (160/160), so lets say I want to move a sprite by 1 dp on 160dpi screen as a baseline, then on a 120 dpi screen it would be .75 of 1 pixel, how does it move it by .75 of a pixel? Surely 1 pixel is the lowest value that it can move by?! Again, I'm probably not understanding this properly. this problem has had me stumped for weeks so any further assistance you could provide really would be appreciated - thanks again!!

Good question. For movement, I've always stored my position data using a floating point type. This allows me to "accumulate" my motion. So for instance, lets say our character moves 1 unit / frame, which we're saying is .75 pixels. So we get

frame 1 - .75 pixels
frame 2 - 1.5 pixels
frame 3 - 2.25 pixels
frame 4 - 3 pixels

I usually just cast to int, so frame 1 would be 0 pixels of motion, frame 2 would be 1, etc. The key here is to save the delta (how many pixels or sub-pixels we moved) from every frame.

Cool OK I see where you're going,

I don't suppose you would mind just giving me a simple example in psuedo-code would you? I'm still having trouble getting my head around it properly..... would this still produce fluid motion?

Do you mean something (very basic) like this:

// get DP unit value
float moveby = 1 * (DPI/160); //set moveby
int toAdd; //used to store acumulative data as below

// Update physics
int movebyInt = (int)moveby; //cast moveby to int and store in movebyInt
toAdd = toAdd + movebyInt; //Acumulate value from last update
spriteX=spriteX+toAdd //add the toAdd value to sprite's X co-ords

Would this not make the sprite keep accelerating or should I reset the 'toAdd' variable back to zero at some point?

Or have I completely mis-understood your method!!?

Thanks again, much appreciated