Hello everyone!

For my game, a 2D platformer, I decided to add parallaxing backgrounds to create more depth. For this approach, I created an object for each pane in the background and foreground, having the following traits:

• Movement factor (scale): The proportion to the Camera's position that it moves at (ie: 3/4 of the Camera's speed)
• Position (x,y): Pretty obvious. For example, x = scale * Camera.x;
• Layer Image (img): The image used for the plane object.

As far as rendering the image at the correct location, I have that taken care of. What I struggle with is how to determine the exact image size needed to line up with the room correctly. By that, I mean: given a room's dimensions, a camera's dimensions, and a movement factor, how can I calculate the dimensions of the image, so that when the Camera moves to the edge of a room, all the layers line up?

Currently, the best formula I could come up with for the image size is (|scale| * room_dimension) - (scale * camera_dimension), but it only works on a few cases (mostly with foreground layers)

As a side note, the scale variable is a float data type with the domain of (-Infinity,1]. Any layer with a value from 1.0 to 0.0 inclusive is considered a background layer. Any layer with a negative scale value is considered foreground.

Any help is greatly appreciated :)

Let's define the amount of the layer of interest seen by the camera at once as L, given in some length units. If you use an orthogonal camera, then L will be identical to the size of the camera's view. If you use a perspective camera, then the depth of the layer plays a role.

Let's define the distance the camera can be moved as d, given in the same units as L. E.g. if p1 is the position of the camera at the beginning of the room, and p2 is it at the end of the room, assuming p2 >= p1, then d := p2 - p1 is the distance of possible movement.

Let's define the parallax factor s. I neglect any fancy stuff done to the sign here.

Then the amount of possible movement of the layer would be

s * d

and the total amount of the layer that can possibly be seen in serial is

s * d + L

When it comes to an image, you need to define the mapping factor of how many pixels per length unit are shown. With a resolution of p pixels per length unit, you need to provide

( s * d + L ) * p

many pixels in the image.

All of the above variables, with the exceptions of s and p, are 2 dimensional vectors.

I think you are making the problem out to be more difficult than it is. Textures are measured in pixels, your screen is also measured in pixels. If you are using textures in the fragment shader, which incidentally also acts on pixels, then I would say that it is a safe bet that you should make the texture size whatever size the model takes up on the screen. Match your pixels to your pixels. Go more low res if you want to save on memory and transfer speeds.

For instance, if the model is a tile that takes up 512x512 pixels on your screen then use 512x512 textures maps. Unless I'm missing something here, the physical screen cannot take advantage of any texture density that is greater than it's physical pixel density. If you go for a lower resolution texture than it will be up-sized and you will see blocky artifacts creeping in.

Did you unintentionally post to the thread?

..snip...

Excellent! This was a question I was going to ask at a future point, but it is good to have an answer now.

Another option that hasn't been discussed is adding the ability for tile layers to "wrap around". Basically, if the view rect goes past an edge of the tile layer, you fill in the gap with tiles from the opposite side. This has the added benefit of allowing for different size tile layers. If your background is a 512x512 pixel image, simply make the background layer a single tile and have it wrap.