scrolling game - is one large background (e.g. 3 screens wide) ok re performance? what is typically done here?

Solar2D General Questions/Discussion
#1

A few question re building a scrolling game is it ok from a performance point of view. Let’s assume for the sake of the question the overall level area is 3 screens wide, and 2 screens high.

Q1 - Is it ok to have the background image as one large image (3 screens x 2 screens) from a performance point of view? I would assume if you broke it up you would still need multiple images loaded at the same time (e.g. as you get close to moving to the next area) so there wouldn’t be much in the way of performance savings? (plus it would make things simpler setting up)

Q2 - At what point would you recommend having to have multiple images? e.g. when say your background is getting over the size of 3x width and 3x height of screen

Q3 - Let say you wanted 4x4 overall, and you wanted to break up the images into smaller ones. What are people typically using to implement this in their game? e.g. manual (DIY), or perhaps LevelEditor? Any recommendations on approach here? Ideally you would create one large image in Photoshop and have a photoshop script that slices it up for you (so if you touch it up just click the button to regenerate the images).

[import]uid: 140210 topic_id: 30622 reply_id: 330622[/import]

#2

ps

Q4 - In terms of testing the above (say Q1 with one large background image) - is it true to say that as long as the FPS stays up at 60fps then things should be ok? i.e. if there were a performance issue due to memory / texture memory would this ultimately surface as reduced FPS? [import]uid: 140210 topic_id: 30622 reply_id: 122719[/import]

#3

I’d base this off your other Q on texture memory - if it’s getting up there then more smaller images will be better if you’re repeating them. [import]uid: 52491 topic_id: 30622 reply_id: 122773[/import]

#4

Hi Peach - actually Bogdan pointed out to me that “Most devices have a maximum texture size of 2048x2048” - so I guess this a 2nd constraint that would also apply and may force the need to break up a background image… [import]uid: 140210 topic_id: 30622 reply_id: 122779[/import]

#5

@Peach - can I you clarify in terms of memory efficiency for images what the different in memory savings is between:

(a) have an image loaded but not visible at that point in time, as it’s outside the viewing area, versus
(b) removing the image from the parent group (not 100% here, but this was mentioned in the Corona doco per Ref 1 below) - wouldn’t the image potential still be visible or off-screen in this case?
© removing it, e.g. image:removeSelf()

Background - So if I have say 10 screen size background images that will be displayed side-by-side in a horizontal scrolling based game, then what approach would work re managing the images as the player moves along.
Ref 1 - http://developer.coronalabs.com/content/performance-and-optimization#Graphics
Second, they use up a lot of memory; some devices will even force quit your application if too much memory is consumed. Therefore, you should remove them from their parent group when you no longer need them [import]uid: 140210 topic_id: 30622 reply_id: 122931[/import]

#6

Hey Greg-

That’s correct, most devices do have that texture size limit - I imagined you were talking about 3 or 4 images the size of the screen, I must have misread that. (As that would be under that limit.)

RE memory, if you aren’t using an image remove it - to the best of my knowledge simply toggling visibility etc wont free up any memory. I could be mistaken but you can easily test that by experimenting while using the memory check code in the other thread we have going on right now.

As it currently stands you texture memory usage is well below any level you would need to be concerned. [import]uid: 52491 topic_id: 30622 reply_id: 122958[/import]

#7

ok Peach thanks - actually one more question - if you put all your screen size images into an imagesheet, so you have some lua code that define where each one is like a spritesheet, do you think this would this use only the memory of (a) a single screen sized image, or (b) the whole sprite sheet? (I’m guessing the latter but hopefully not)

If this worked then you could develop one long horizontal image (say 5 screens worth), and then just reference each part of this when you need it using the sprite approach. It would just save having to slice the large image file up into multiple images in photoshop… [import]uid: 140210 topic_id: 30622 reply_id: 122965[/import]

#8

I believe the sheet will occupy its entire size in the texture memory pool, because the entire sheet is “loaded” into memory. Sheets are popular and often used in development because they can often use LESS memory compared to a dozen or more individual files. Also, they provide organization, and they are “accessed” easier and faster by the engine.

So basically, in your case, don’t use sheets. In fact, if these are full screen backgrounds, you can’t use sheets because the maximum image size will likely be exceeded, and the app will crash. Those dimensions vary by device and OS… iPad 1 or 2 allows for max of 2048 pixels in either direction, I believe, and older iPhones (3G) might max out at 1024. IPad3 allows for 4096.

You’re “stuck” using separate images and loading/unloading them to conserve texture memory. :wink:

Brent Sorrentino

[import]uid: 9747 topic_id: 30622 reply_id: 122969[/import]

#9

thanks Brent - I haven’t come across any code that handles loading / unloading images like this as a character moves have you? (not that it will be too difficult - just wondering if there was some well know library I haven’t come across yet that solves this) [import]uid: 140210 topic_id: 30622 reply_id: 122974[/import]

#10

Hi Greg,

The closest already-built module I can think of is Lime, but this is really tailored for tile-based games and the use of the 3rd-party “Tiled” tool.

So, I think you’ll have to write your own routine for this. It’s something that I’ve wanted to tackle myself for awhile, but it always gets pushed near the bottom of my priority list. I imagine something similar to Lime that loads/unloads sections of a large background (each section being a separate image). Ideally the user would be able to define the size of these “chunks”. Even more ideal would be some method to “predict” and pre-load certain chunks as they moved closer to on-screen appearance, so that there wouldn’t be any skipping or stutter if the pieces were larger in file size… but that gets really complex.

Brent
[import]uid: 9747 topic_id: 30622 reply_id: 123018[/import]

#11

ps

Q4 - In terms of testing the above (say Q1 with one large background image) - is it true to say that as long as the FPS stays up at 60fps then things should be ok? i.e. if there were a performance issue due to memory / texture memory would this ultimately surface as reduced FPS? [import]uid: 140210 topic_id: 30622 reply_id: 122719[/import]

#12

I’d base this off your other Q on texture memory - if it’s getting up there then more smaller images will be better if you’re repeating them. [import]uid: 52491 topic_id: 30622 reply_id: 122773[/import]

#13

Hi Peach - actually Bogdan pointed out to me that “Most devices have a maximum texture size of 2048x2048” - so I guess this a 2nd constraint that would also apply and may force the need to break up a background image… [import]uid: 140210 topic_id: 30622 reply_id: 122779[/import]

#14

@Peach - can I you clarify in terms of memory efficiency for images what the different in memory savings is between:

(a) have an image loaded but not visible at that point in time, as it’s outside the viewing area, versus
(b) removing the image from the parent group (not 100% here, but this was mentioned in the Corona doco per Ref 1 below) - wouldn’t the image potential still be visible or off-screen in this case?
© removing it, e.g. image:removeSelf()

Background - So if I have say 10 screen size background images that will be displayed side-by-side in a horizontal scrolling based game, then what approach would work re managing the images as the player moves along.
Ref 1 - http://developer.coronalabs.com/content/performance-and-optimization#Graphics
Second, they use up a lot of memory; some devices will even force quit your application if too much memory is consumed. Therefore, you should remove them from their parent group when you no longer need them [import]uid: 140210 topic_id: 30622 reply_id: 122931[/import]

#15

Hey Greg-

That’s correct, most devices do have that texture size limit - I imagined you were talking about 3 or 4 images the size of the screen, I must have misread that. (As that would be under that limit.)

RE memory, if you aren’t using an image remove it - to the best of my knowledge simply toggling visibility etc wont free up any memory. I could be mistaken but you can easily test that by experimenting while using the memory check code in the other thread we have going on right now.

As it currently stands you texture memory usage is well below any level you would need to be concerned. [import]uid: 52491 topic_id: 30622 reply_id: 122958[/import]

#16

ok Peach thanks - actually one more question - if you put all your screen size images into an imagesheet, so you have some lua code that define where each one is like a spritesheet, do you think this would this use only the memory of (a) a single screen sized image, or (b) the whole sprite sheet? (I’m guessing the latter but hopefully not)

If this worked then you could develop one long horizontal image (say 5 screens worth), and then just reference each part of this when you need it using the sprite approach. It would just save having to slice the large image file up into multiple images in photoshop… [import]uid: 140210 topic_id: 30622 reply_id: 122965[/import]

#17

I believe the sheet will occupy its entire size in the texture memory pool, because the entire sheet is “loaded” into memory. Sheets are popular and often used in development because they can often use LESS memory compared to a dozen or more individual files. Also, they provide organization, and they are “accessed” easier and faster by the engine.

So basically, in your case, don’t use sheets. In fact, if these are full screen backgrounds, you can’t use sheets because the maximum image size will likely be exceeded, and the app will crash. Those dimensions vary by device and OS… iPad 1 or 2 allows for max of 2048 pixels in either direction, I believe, and older iPhones (3G) might max out at 1024. IPad3 allows for 4096.

You’re “stuck” using separate images and loading/unloading them to conserve texture memory. :wink:

Brent Sorrentino

[import]uid: 9747 topic_id: 30622 reply_id: 122969[/import]

#18

thanks Brent - I haven’t come across any code that handles loading / unloading images like this as a character moves have you? (not that it will be too difficult - just wondering if there was some well know library I haven’t come across yet that solves this) [import]uid: 140210 topic_id: 30622 reply_id: 122974[/import]

#19

Hi Greg,

The closest already-built module I can think of is Lime, but this is really tailored for tile-based games and the use of the 3rd-party “Tiled” tool.

So, I think you’ll have to write your own routine for this. It’s something that I’ve wanted to tackle myself for awhile, but it always gets pushed near the bottom of my priority list. I imagine something similar to Lime that loads/unloads sections of a large background (each section being a separate image). Ideally the user would be able to define the size of these “chunks”. Even more ideal would be some method to “predict” and pre-load certain chunks as they moved closer to on-screen appearance, so that there wouldn’t be any skipping or stutter if the pieces were larger in file size… but that gets really complex.

Brent
[import]uid: 9747 topic_id: 30622 reply_id: 123018[/import]