GameView parenting

[sterlingy]

I'm going to try and make this easy to understand. Hope this works:

I'm working on a game. My background is a street, and it scrolls up and down, depending on the direction the main character moves. This seems to be working just fine, but there are also cars that move up and down the street, and in addition to their independent moving, they need to move relative to the scrolling background (street).

For lack of a better term, how do I parent the cars to the street? I could recalculate their relative position everytime the background scrolls, but his seems like a lot of overhead.

Cheers,

Sterling

 

[basil99]

You have a "world" full of different entities, like cars, buldings, enemies, player(s), items etc. Each entity has it own absolute world coordinates, say EntityX( indexOfEntity ) and EntityY( indexOfEntity ).

On other hand you have a "camera" with width = ScreenWidth and height=ScreenHeight, like a window that display a part of the world. Top-left corner of camera has coordinates Xoffset/Yoffset.

You need to manage only world ( absolute ) positions of entities, like car moving, then clip like

if entityOnScreen( entityIndex ) = True

       drawEntity( entityIndex )

end if

and entityOnScreen( entityIndex ) checks does EntityX/EntityY rectangle overlap "camera" rectangle

and a simple code for 2 rectangles S and D overlap is:

sub RectanglesOverlap(sx1 as Int,sy1 as Int,sx2 as Int,sy2 as Int,dx1 as Int,dy1 as Int,dx2 as Int,dy2 as Int ) as boolean

   dim result as Boolean
   result=false

   if sx1 <  dx2 then
   if sx2 >= dx1 then
   if sy1 <  dy2 then
   if sy2 >= dy1 then

      result = true
   
   end if
   end if
   end if   
   end if

   return result

End Sub

may be this helps

 

[Informatix]

For lack of a better term, how do I parent the cars to the street? I could recalculate their relative position everytime the background scrolls, but his seems like a lot of overhead.

On big maps (larger than the screen), a game like yours uses two coordinates system for the sprites. One system for the world (where is the car in the world?), and one system for the screen (where is the car on screen?). You have only to store the coordinates in the world. And when you recalculate the car position, you modify only these coordinates. The coordinates for the screen can be easily computed when needed.

Example:
My car A: Xworld = 100, Yworld = 100
My car B: Xworld = 500, Yworld = 450
My car C: Xworld = 460, Yworld = 150
The screen displays currently the map tile located between Xworld=400 (Xscreen=0) and Xworld=880 (Xscreen=480), and between Yworld=50 (Yscreen=0) and Yworld=370 (Yscreen=320).
Quick computation:
Car A: XScreen = XWorld of the car - XWorld for XScreen0 = 100 - 400 = -300 (off the screen, do not draw)
Car B: XScreen = 500 - 400 = 100 (on screen)
YScreen = 450 - 50 = 400 (more than 320, so off the screen, do not draw)
Car C: XScreen = 460 - 400 = 60 (on screen)
YScreen = 150 - 50 = 100 (on screen -> draw at left=60, top=100)

 

[sterlingy]

I understand the philosophy that you both mentioned. What about taking into account different screen sizes and resolutions. Since my project uses dip exclusively, the actual world coordinates may not work out, or Am I wrong?

-Sterling

 

[basil99]

I understand the philosophy that you both mentioned. What about taking into account different screen sizes and resolutions. Since my project uses dip exclusively, the actual world coordinates may not work out, or Am I wrong?

-Sterling

1) yes, 100% wrong with DIP. Use %x and %y measure units always

2) Think, all your grafix assets are made for some "base" resolution, say, 1024x768 ( or 480x320 ), no matter. Device has DeviceWidth/DeviceHeight dimensions.

So, you need is to scale ALL with:

ScaleX = DeviceWidth/BaseWidth
ScaleY = DeviceHeight/BaseHeight

ALL - means bitmaps and entities coordinates

also, aspect ration may be a problem ...

 

[Informatix]

1) yes, 100% wrong with DIP. Use %x and %y measure units always

Could you explain? I don't understand your answer.

My own answer would be: the coordinates in the world may be in pixels, in dip or anything else. Choose the most useful units for you. The coordinates on screen can use different units. The problem is not the units, but the conversion between them.

 

[basil99]

Could you explain? I don't understand your answer.

My own answer would be: the coordinates in the world may be in pixels, in dip or anything else. Choose the most useful units for you. The coordinates on screen can use different units. The problem is not the units, but the conversion between them.

My own ( but short for sure ) experience. Found DIP useless.
I use %x/%y units for views and pixels for grafics with proper scale

And we're talking about 2D games, where all is based on pixel grafics, so pixels, IMHO, is a native unit

Or may be I don't understand DIP at all

 

[Erel]

Dips are not useless at all. In fact writing pixels without either 'dip' or %x / %y is a bug in 99% of the cases.

For games you will usually want to use percentage instead of dips.

 

[Informatix]

My own ( but short for sure ) experience. Found DIP useless.
I use %x/%y units for views and pixels for grafics with proper scale

And we're talking about 2D games, where all is based on pixel grafics, so pixels, IMHO, is a native unit

Or may be I don't understand DIP at all

Could you explain me why you and Erel see percentages as the best unit to use? I looked at the code of open source games and didn't find percentages. I read a few books on the subject and didn't see percentages either.

Let's have an example: a map of 1200 pixels x 1200 pixels.
The coordinates in the world could range from:
1) 0, 0 to 1200, 1200 (unit = pixel)
2) 0, 0 to 1200/Density, 1200/Density (unit = dip)
3) 0, 0 to 100, 100 (unit = percentage)
4) 0, 0 to 200, 200 (unit = meters, with 6 pixels=1 meter)

If I decide that all screens will display exactly the same map area, regardless of the screen resolution, DIP is a convenient unit (the conversion to screen coordinates is much easier). If I decide that all screens will display as many pixels as possible, pixel is a natural and convenient unit (bigger screens will display a bigger map area). At first glance, I don't really see the usefulness of the percentage unit. It involves more computation and needs float computation (costly for CPU). Exactly like the meters unit, but the meters unit is justified by the use of a physics engine.

Is not there a confusion between the coordinates in the world and the screen coordinates? The relationship between them can be a ratio, indeed.

 

[basil99]

I don't argue, think i probably don't understand the benefits of DIP, especially for 2D games, where pixels are native units. % % with 2D games are more hard to calc, so here I agree with you, Informarix


For applications using views, like buttons, labels etc, %% is the best for me. And once again, this is my opinion only. One of the first version of app i'm making had mix of DIPs and %%, so it looks Ok on one device and ugly on another. Later I move to %% only and get the same look everywhere.

 

[Erel]

As I wrote above you should (almost) never use pixels without one of the scaling units.

The physical screen size of Galaxy Nexus and Galaxy Ace are similar. However the Galaxy Nexus resolution is about 720x1200 (scale=2) and the resolution of Galaxy Ace is about 320x480 (scale=1). Theoretically you can show a huge map on Galaxy Nexus. However the result will be a "compressed" and unusable map.

This is exactly the purpose of 'dip' units. A 100dip button will have (more or less) the same physical size on ALL devices.

On non-games applications percentage units are less useful. As the result, on tablets, will be a stretched UI. In such applications it is best to use 'dip' units together with AutoScaleAll.

 

[Informatix]

For applications using views, like buttons, labels etc, %% is the best for me. And once again, this is my opinion only. One of the first version of app i'm making had mix of DIPs and %%, so it looks Ok on one device and ugly on another. Later I move to %% only and get the same look everywhere.

Yes, for views, I use also %x and %y most of the time. But that's something different, there are no "world coordinates", only "screen coordinates".

 

[Informatix]

As I wrote above you should (almost) never use pixels without one of the scaling units.

The physical screen size of Galaxy Nexus and Galaxy Ace are similar. However the Galaxy Nexus resolution is about 720x1200 (scale=2) and the resolution of Galaxy Ace is about 320x480 (scale=1). Theoretically you can show a huge map on Galaxy Nexus. However the result will be a "compressed" and unusable map.

This is exactly the purpose of 'dip' units. A 100dip button will have (more or less) the same physical size on ALL devices.

On non-games applications percentage units are less useful. As the result, on tablets, will be a stretched UI. In such applications it is best to use 'dip' units together with AutoScaleAll.

Ok, we're not talking of the same thing. I was discussing about the unit to use for world coordinates (and it seems that the original question is about that), not for screen coordinates. For screen coordinates, we don't have many choices. And in this matter, I disagree with your advices about AutoScale (we do not look at tablets farther than at phones, so I don't see why the displayed things should be sized bigger on them), but that's another discussion, not related to games.

 

[basil99]

Yes, for views, I use also %x and %y most of the time. But that's something different, there are no "world coordinates", only "screen coordinates".

In 2D games I scale bitmaps, objects coordinates, velocities and accelerations, so it look the same. And all of this data is in pixel units

 

[basil99]

As I wrote above you should (almost) never use pixels without one of the scaling units.

The physical screen size of Galaxy Nexus and Galaxy Ace are similar. However the Galaxy Nexus resolution is about 720x1200 (scale=2) and the resolution of Galaxy Ace is about 320x480 (scale=1). Theoretically you can show a huge map on Galaxy Nexus. However the result will be a "compressed" and unusable map.

This is exactly the purpose of 'dip' units. A 100dip button will have (more or less) the same physical size on ALL devices.

On non-games applications percentage units are less useful. As the result, on tablets, will be a stretched UI. In such applications it is best to use 'dip' units together with AutoScaleAll.

Lets say I have two 19'monitors. First display an old game in 800x600, another smth advanced in 1920x1080. Physical size is the same, but pretty different pixels density. You mean this ?

 

[Erel]

(we do not look at tablets farther than at phones, so I don't see why the displayed things should be sized bigger on them)

This was my first thought as well. Which means that DIP units are enough in this case.

However based on many discussions in the forum and my personal experience I realized that it is more appropriate (aka looks better) to slightly increase the font size and the views size on larger devices. Note that the default scale rate is pretty small (0.3).

I'm also not sure that we hold the devices in the same distance.

 

[Informatix]

This was my first thought as well. Which means that DIP units are enough in this case.

However based on many discussions in the forum and my personal experience I realized that it is more appropriate (aka looks better) to slightly increase the font size and the views size on larger devices. Note that the default scale rate is pretty small (0.3).

I'm also not sure that we hold the devices in the same distance.

Whatever one thinks about it, it's more a matter of taste than anything else. I will not lead a battle against AutoScale

I'm creating a lot of mini-games in an app for kids and I don't follow the same rule regarding the scaling of objects on screen according to the size of devices. It's all driven by factors like : the object can't be less than n dips wide, the object must have the same size on all screens, the object must scale proportionally because it fills the top part of the screen, etc.
I don't use world coordinates in these games because nothing can go off screen, but for my screen coordinates, I only use percentages when I have to scale something proportionally. So, I find a bit strange to define a general rule for units, even for screen coordinates.