Background Images Size

Getting Started Newbie Questions
#1

Hi all,

i read those articles:

https://coronalabs.com/blog/2012/12/04/the-ultimate-config-lua-file/

http://coronalabs.com/blog/2013/09/10/modernizing-the-config-lua/

And now i’m using the modernizing config lua in my project. But, i still don’t understand wich size of background images should i use.

I’m developing a game to run in vertical mode and i want to run in all devices (android, ios).

Wich size of background should i set?

A default like 320x480 and let the (display.newImageRect) manage for bigger devices? i’m a bit confuse, sorry.

#2

http://coronalabs.com/blog/2013/09/10/modernizing-the-config-lua/

Comments :

Rob Miracle - September 16th

T.

#3

Sooo resuming:

If i’m using this modernizing config i have to create 2 bgs:

900 x 1425

and 1800 x 2850 for @2x

Is that right?

I’m sorry if i mist something (english is not my first language)

But, i read in somewhere if i do images as large as they can for support bigger devices, when corona scale for minor devices wouldn’t have memory issues?

#4

I don’t use that config but the one before it 1x, 2x , 4x

But based on what the tutorial and comments said 

900 x 1425

and then @2x 1800 x 2850

Should work for you.

As a test 

    local BackGroundMain = display.newRoundedRect( 0, 0, X, Y, 0)

    BackGroundMain:setFillColor(1, 1, 1)

    BackGroundMain.x = display.contentWidth/ 2 

    BackGroundMain.y = display.contentHeight/ 2

Play with the X & Y in a small project main/ config etc… Go small X =200 Y = 400 and then increase this will give you a good insight and understanding of how the config works.

Don’t use images - the newRoundedRect will show you how different size can work as you switch the Simulator views between phone/ pad/ galaxy S3/ kindle

T.

#5

Ok, Thank you!

I’ll try that as soon as i get home… but first, can you tell me what’s the background images size you use with your configuration?

For 1x, 2x and 4x.

#6

FWIW: those sizes will waste a lot of texture memory, suggest you rescale them (non-linearly) to fit power-of-two, then resize them back up with newImageRect (you probably won’t notice the difference for “background” images, and it’ll save lots of memory)

  1. create your actual-sized images:
    original_900x1425.png – would consume 8M
    original_900x1425@2x.png – 1800x2850 would consume 32M

  2. nonlinear scale:
    scaled_512x1024.png – will only consume 2M texture memory
    scaled_512x1024@2x.png – 1024x2048 will only consume 8M texture memory

  3. bring it into your game restoring original size
    local img = display.newImageRect(“scaled_512x1024.png”, 900, 1425)

#7

Yeaah @davebollinger. That was my concern, about the memory.  I’ll try your way…

Have you used that in your projects? I mean have you tested in different devices besides the simulator using that configuration?

#8

first rule is: you can use any content size you want, and don’t let anyone tell you different. :smiley:

fe, there’s no dif between someone who runs 320x480 content size and provides @1 and @2 images, versus someone who runs 640x960 content size with @half and @1 images - the scaling math works out identically. extend that analogy fractionally to other dimensions and you’ll see it’s really just a matter of setting the right scale factors for your images, the actual RANGE of the content coordinate system is arbitrary.

i like to define my content width = 480 (assuming portrait) then set content height by aspect ratio (similar to what the “modernizing” article does, except that it’ll (potentially) expand width also, where I hold width constant so only have to size for letterboxing on the long axis), so anywhere from 480x640 to 480x854 (given current device aspect ratios ranging approx from 4:3 to 16:9). this let’s my @1 images fit nearly perfectly within 512x1024, and @2’s in 1024x2048. (a 320x? device would downsize the @1 images, which would look fine, but i honestly don’t care about such devices anyway)

but that’s just me, personal preference.

you could work at 960, and do @half/@1 and it’d be the same as mine. or you could work at 640 width, and just use the above newImageRect() trick to stretch 512x images into it. or work at 800 width, stretching 1024x images into them so you have more downsample than upsample through your range (which generally looks “better”)

hth

#9

heey @davebollinger,

got it! i’ll find my way to work.

Thank you for the explanation!

#10

http://coronalabs.com/blog/2013/09/10/modernizing-the-config-lua/

Comments :

Rob Miracle - September 16th

T.

#11

Sooo resuming:

If i’m using this modernizing config i have to create 2 bgs:

900 x 1425

and 1800 x 2850 for @2x

Is that right?

I’m sorry if i mist something (english is not my first language)

But, i read in somewhere if i do images as large as they can for support bigger devices, when corona scale for minor devices wouldn’t have memory issues?

#12

I don’t use that config but the one before it 1x, 2x , 4x

But based on what the tutorial and comments said 

900 x 1425

and then @2x 1800 x 2850

Should work for you.

As a test 

    local BackGroundMain = display.newRoundedRect( 0, 0, X, Y, 0)

    BackGroundMain:setFillColor(1, 1, 1)

    BackGroundMain.x = display.contentWidth/ 2 

    BackGroundMain.y = display.contentHeight/ 2

Play with the X & Y in a small project main/ config etc… Go small X =200 Y = 400 and then increase this will give you a good insight and understanding of how the config works.

Don’t use images - the newRoundedRect will show you how different size can work as you switch the Simulator views between phone/ pad/ galaxy S3/ kindle

T.

#13

Ok, Thank you!

I’ll try that as soon as i get home… but first, can you tell me what’s the background images size you use with your configuration?

For 1x, 2x and 4x.

#14

FWIW: those sizes will waste a lot of texture memory, suggest you rescale them (non-linearly) to fit power-of-two, then resize them back up with newImageRect (you probably won’t notice the difference for “background” images, and it’ll save lots of memory)

  1. create your actual-sized images:
    original_900x1425.png – would consume 8M
    original_900x1425@2x.png – 1800x2850 would consume 32M

  2. nonlinear scale:
    scaled_512x1024.png – will only consume 2M texture memory
    scaled_512x1024@2x.png – 1024x2048 will only consume 8M texture memory

  3. bring it into your game restoring original size
    local img = display.newImageRect(“scaled_512x1024.png”, 900, 1425)

#15

Yeaah @davebollinger. That was my concern, about the memory.  I’ll try your way…

Have you used that in your projects? I mean have you tested in different devices besides the simulator using that configuration?

#16

first rule is: you can use any content size you want, and don’t let anyone tell you different. :smiley:

fe, there’s no dif between someone who runs 320x480 content size and provides @1 and @2 images, versus someone who runs 640x960 content size with @half and @1 images - the scaling math works out identically. extend that analogy fractionally to other dimensions and you’ll see it’s really just a matter of setting the right scale factors for your images, the actual RANGE of the content coordinate system is arbitrary.

i like to define my content width = 480 (assuming portrait) then set content height by aspect ratio (similar to what the “modernizing” article does, except that it’ll (potentially) expand width also, where I hold width constant so only have to size for letterboxing on the long axis), so anywhere from 480x640 to 480x854 (given current device aspect ratios ranging approx from 4:3 to 16:9). this let’s my @1 images fit nearly perfectly within 512x1024, and @2’s in 1024x2048. (a 320x? device would downsize the @1 images, which would look fine, but i honestly don’t care about such devices anyway)

but that’s just me, personal preference.

you could work at 960, and do @half/@1 and it’d be the same as mine. or you could work at 640 width, and just use the above newImageRect() trick to stretch 512x images into it. or work at 800 width, stretching 1024x images into them so you have more downsample than upsample through your range (which generally looks “better”)

hth

#17

heey @davebollinger,

got it! i’ll find my way to work.

Thank you for the explanation!