Large newRect Best Practices

[hdtruelson]

Hello,

I have a newRect that has a nice gradient that is about 5 times as high as the height of the screen.  As the screen scrolls down, you can see more of it etc.  Pretty standard.  But I was wondering if that will take up too much system memory, and had an idea.  What if I had a gradient just the height of the screen and just recalculated it on every frame?  Would that be a good solution or would it take too much processing power?  And is the 5x height of the newRect significant for memory usage or not?

To restate: Which would have a lower performance impact on a lower quality phone - creating a newRect 5x the size of the screen, or recalculating a gradient the size of the screen every frame.

Thanks!

[Prathap_Murthy]

Is it just a scrollView that displays something like credits or is it a vertical scrolling game?

[hdtruelson]

It is a vertically scrolling game

[Prathap_Murthy]

Recalculating and repainting the gradient every frame will be intensive. Scrolling might end up becoming choppy. I wouldn’t recommend it.

Also, loading a rectangular background that spans the width of the device and 5 times the height can cause texture memory problems on lower-end Android phones (I’ve experienced similar situations myself). Bear in mind that the background is not the only thing to consider… I’m sure you’ll have other UI elements loaded along with the background. So conserving texture memory as much as possible will certainly help in avoiding crashes on older phones.

If you’re really keen on a background with a specific gradient, I would recommend this approach of “stitching” 2 different rectangular backgrounds (each with its own gradient) together –

I’m assuming you’ve a particular gradient in mind. To avoid runtime calculations and facilitate faster execution of your time-critical code path, you can find out the colors needed for the entire gradient beforehand. Using an image editor, create a large enough rectangle and apply your desired gradient. Divide it equally into 5 parts. Note the color values at the top, bottom and divisions. Something like this –

Color at the top of the big rectangle = color 1
Color at the first division = color 2
Color at the second division = color 3
Color at the third division = color 4

Color at the fourth division = color 5
Color at the bottom of the big rectangle = color 6

When you load each rectangle in your game as a background, ensure that the height of the rectangle is slightly longer than contentHeight. The reasoning behind this is, we don’t want to load all 5 rectangles in one go. We will only load 2 rectangles at a time, “stitch” them snugly to each other and scroll them together. This concept is a little hard to explain concisely. Refer to the ground scrolling code of “Flappy Bird clone” created by Mark Falkland – http://code.coronalabs.com/code/flappy-bird-clone

At the start of the scene, load 2 rectangles (you won’t need more) each of height slightly longer than contentHeight (let’s call their height _ rectHeight _) –

1. Rectangle 1 with gradient from color 1 to color 2. You will position this at contentCenterX, contentCenterY.

2. Rectangle 2 with gradient from color 2 to color 3. You will position this at contentCenterX, ( contentCenterY + _ rectHeight _ ).

So rectangle 1 will be onscreen and rectangle 2 right beneath it (and offscreen).

Since this is a vertical scroller, your player object will be stationary. The rectangular backgrounds and other game objects will have to be scrolled upward to create the illusion of the player object descending.

You will obviously have a runtime event listener (enterFrame) to perform your game logic and update your scene accordingly. For every frame, you will scroll the backgrounds and game objects upwards (decrease Y position) at a constant speed. Here, check if the first rectangle has scrolled above the top of the screen. In other words, rectangle 1 will be completely offscreen and rectangle 2 will be in complete view. At this point, repaint the first rectangle with a gradient from color 3 to color 4 and position it again at contentCenterX, ( contentCenterY + _ rectHeight _ ). You will need to add a slight offset to the rectangles’ positions to make the “stitching” appear seamless.

When rectangle 2 is out of sight, repaint it with gradient from color 4 to color 5 and position it at the bottom of rectangle 1 and so on. When you run out of colors i.e. the previous rectangle was already painted with a gradient from color 5 to color 6, start the subsequent repaints in the opposite direction. So the background gradient will gradually go from color 1 to color 6 and then back from color 6 to color 1 and so on.

I probably gave you too much information to start with. Just go through the Flappy Bird Clone code and you will understand how to make an endless scroller. Mark Falkland has even created a video tutorial to explain his code. Although that example is a horizontal scroller, the concept is the same for a vertical scroller. In that example, only the ground and other obstacles are being scrolled horizontally. In your case, you will scroll the background, side walls (if any) and other obstacles vertically.

Once you perfect background scrolling, you can add parallax scrolling to further enhance the look of your game.

Keep in mind that endless scrollers created using Corona SDK require a good amount of optimization to run smoothly at 60 fps across all devices. So your time-critical enterFrame listener code must be lean and mean. Good luck!

[hdtruelson]

Genius!  That’s exactly the solution I think.  Thank you very much!

[Prathap_Murthy]

Is it just a scrollView that displays something like credits or is it a vertical scrolling game?

[hdtruelson]

It is a vertically scrolling game

[Prathap_Murthy]

Recalculating and repainting the gradient every frame will be intensive. Scrolling might end up becoming choppy. I wouldn’t recommend it.

Also, loading a rectangular background that spans the width of the device and 5 times the height can cause texture memory problems on lower-end Android phones (I’ve experienced similar situations myself). Bear in mind that the background is not the only thing to consider… I’m sure you’ll have other UI elements loaded along with the background. So conserving texture memory as much as possible will certainly help in avoiding crashes on older phones.

If you’re really keen on a background with a specific gradient, I would recommend this approach of “stitching” 2 different rectangular backgrounds (each with its own gradient) together –

I’m assuming you’ve a particular gradient in mind. To avoid runtime calculations and facilitate faster execution of your time-critical code path, you can find out the colors needed for the entire gradient beforehand. Using an image editor, create a large enough rectangle and apply your desired gradient. Divide it equally into 5 parts. Note the color values at the top, bottom and divisions. Something like this –

Color at the top of the big rectangle = color 1
Color at the first division = color 2
Color at the second division = color 3
Color at the third division = color 4

Color at the fourth division = color 5
Color at the bottom of the big rectangle = color 6

When you load each rectangle in your game as a background, ensure that the height of the rectangle is slightly longer than contentHeight. The reasoning behind this is, we don’t want to load all 5 rectangles in one go. We will only load 2 rectangles at a time, “stitch” them snugly to each other and scroll them together. This concept is a little hard to explain concisely. Refer to the ground scrolling code of “Flappy Bird clone” created by Mark Falkland – http://code.coronalabs.com/code/flappy-bird-clone

At the start of the scene, load 2 rectangles (you won’t need more) each of height slightly longer than contentHeight (let’s call their height _ rectHeight _) –

1. Rectangle 1 with gradient from color 1 to color 2. You will position this at contentCenterX, contentCenterY.

2. Rectangle 2 with gradient from color 2 to color 3. You will position this at contentCenterX, ( contentCenterY + _ rectHeight _ ).

So rectangle 1 will be onscreen and rectangle 2 right beneath it (and offscreen).

Since this is a vertical scroller, your player object will be stationary. The rectangular backgrounds and other game objects will have to be scrolled upward to create the illusion of the player object descending.

You will obviously have a runtime event listener (enterFrame) to perform your game logic and update your scene accordingly. For every frame, you will scroll the backgrounds and game objects upwards (decrease Y position) at a constant speed. Here, check if the first rectangle has scrolled above the top of the screen. In other words, rectangle 1 will be completely offscreen and rectangle 2 will be in complete view. At this point, repaint the first rectangle with a gradient from color 3 to color 4 and position it again at contentCenterX, ( contentCenterY + _ rectHeight _ ). You will need to add a slight offset to the rectangles’ positions to make the “stitching” appear seamless.

When rectangle 2 is out of sight, repaint it with gradient from color 4 to color 5 and position it at the bottom of rectangle 1 and so on. When you run out of colors i.e. the previous rectangle was already painted with a gradient from color 5 to color 6, start the subsequent repaints in the opposite direction. So the background gradient will gradually go from color 1 to color 6 and then back from color 6 to color 1 and so on.

I probably gave you too much information to start with. Just go through the Flappy Bird Clone code and you will understand how to make an endless scroller. Mark Falkland has even created a video tutorial to explain his code. Although that example is a horizontal scroller, the concept is the same for a vertical scroller. In that example, only the ground and other obstacles are being scrolled horizontally. In your case, you will scroll the background, side walls (if any) and other obstacles vertically.

Once you perfect background scrolling, you can add parallax scrolling to further enhance the look of your game.

Keep in mind that endless scrollers created using Corona SDK require a good amount of optimization to run smoothly at 60 fps across all devices. So your time-critical enterFrame listener code must be lean and mean. Good luck!

[hdtruelson]

Genius!  That’s exactly the solution I think.  Thank you very much!