Is my Image suffic logic flawd? Android only.

Solar2D General Questions/Discussion
#1

My confing.lua is this:

application = { content = { width = 320, height = 480, scale = "zoomStretch", imageSuffix = { . ["@1-5"] = 1.5, ["@2x"] = 2, ["@4x"] = 4, }, }, license = { google = { key = "Your key here" }, }, }

I don’t care for iPhone. ONLY Android.

I want my game to cover from 480x320 to 1920x1080 devices.

So, lets say I have a background image called back.png and it is 1920x1080.

I make the following images in photoshop with image sizes according to PoT:

back.png – PoT is 512x512

back@1,5x – PoT is 1024x512

back@2x – PoT is 1024x1024

back@4x – Pot is 2048x2048

That way I save Texture Memory for each device, and decrease loading time. BUT are my numbers correct?

Is my tactic correct?

The problem I encounter is that I use too much physical memory for all those graphics. My game is 150 MB big so far, and it will get bigger.

Anything you could mention here? I repeat I don’t care for iOS, only Android.

#2

anyone?

#3

Hi @fkaktos,

A few comments here:

  1. I don’t recommend the “zoomStretch” scale mode, unless it’s a text-only app (and clearly yours is not). Stretching the content area will usually result in some undesired, uneven scaling of the images. “zoomEven” or “letterbox” are better in most cases.

  2. You can probably combine the “1.5” and “2” suffix sets, since they’re not vastly different (both aim for around 1024 in one direction, or both). If you can do so, you’re instantly saving a huge amount of space by eliminating an entire set of images.

  3. You may want to consider if the “legacy” set (320x480) is worth including. There are fewer and fewer devices with physical screens around that size, so consider how much space that will add to your compiled binary.

  4. You’re correct in using the PoT values to conserve texture memory, but remember that you don’t need to adhere to these sizes for the “canvas size” of your images. You can make a background image 640x960 and it will occupy your @2x set… and yes, it will occupy the 1024x1024 space in texture memory, but you’ll save some space on the actual file by trimming it in Photoshop or whatever image editor you use. In other words, if you’re padding your backgrounds with a ton of empty space to force them up to the next PoT size, that’s not necessary and not recommended.

Hope this helps,

Brent Sorrentino

#4

Thank you for your answer.

What set do you recomment me to use? A 16:9 one? 270x480? What is most popular?

Also for the zoomStretch thing, the guys I’m working with, prefer it from letterbox, cause they don’t want the “black bars” appearance on different aspect ratio devices. They want the full device screen to be active.

#5

In this case, I suggest “zoomEven” instead of “zoomStretch”. This will expand the content area so that it fills the entire screen (in whichever direction necessary), and then some of the content will bleed off the other edges. But you won’t have to deal with letterbox bars, and you won’t have oddly stretched images either.

We have an updated tutorial on this coming tomorrow, so perhaps wait until then and see if that solution works well for you.

Best regards,

Brent

#6

anyone?

#7

Hi @fkaktos,

A few comments here:

  1. I don’t recommend the “zoomStretch” scale mode, unless it’s a text-only app (and clearly yours is not). Stretching the content area will usually result in some undesired, uneven scaling of the images. “zoomEven” or “letterbox” are better in most cases.

  2. You can probably combine the “1.5” and “2” suffix sets, since they’re not vastly different (both aim for around 1024 in one direction, or both). If you can do so, you’re instantly saving a huge amount of space by eliminating an entire set of images.

  3. You may want to consider if the “legacy” set (320x480) is worth including. There are fewer and fewer devices with physical screens around that size, so consider how much space that will add to your compiled binary.

  4. You’re correct in using the PoT values to conserve texture memory, but remember that you don’t need to adhere to these sizes for the “canvas size” of your images. You can make a background image 640x960 and it will occupy your @2x set… and yes, it will occupy the 1024x1024 space in texture memory, but you’ll save some space on the actual file by trimming it in Photoshop or whatever image editor you use. In other words, if you’re padding your backgrounds with a ton of empty space to force them up to the next PoT size, that’s not necessary and not recommended.

Hope this helps,

Brent Sorrentino

#8

Thank you for your answer.

What set do you recomment me to use? A 16:9 one? 270x480? What is most popular?

Also for the zoomStretch thing, the guys I’m working with, prefer it from letterbox, cause they don’t want the “black bars” appearance on different aspect ratio devices. They want the full device screen to be active.

#9

In this case, I suggest “zoomEven” instead of “zoomStretch”. This will expand the content area so that it fills the entire screen (in whichever direction necessary), and then some of the content will bleed off the other edges. But you won’t have to deal with letterbox bars, and you won’t have oddly stretched images either.

We have an updated tutorial on this coming tomorrow, so perhaps wait until then and see if that solution works well for you.

Best regards,

Brent