[FIXED] object.fill does not use content scaling for image fills

Currently working on a new game and rather that use loads of tiles, I am trying to use fills on rectangles to save memory etc.

However, the texture fill always uses the x1 image size, thus on a device that would use @2x or @4x images the fill looks terrible. 

Using texture fills just isn’t viable if using content scaling.

I’m using a 32x32 base image size with @2x (64x64) and @4x (128x128)

Content scaling: letterbox, width =320, height = 480

[lua]

display.setDefault( “textureWrapX”, “repeat” )

display.setDefault( “textureWrapY”, “repeat” )

local block = display.newRect(display.contentCenterX,display.contentCenterY,320,32)
block.fill = {type = “image”, filename = “images/platform32x32.png”}
local scaleFactorX = block.height / block.width
local scaleFactorY = 1
block.fill.scaleX = scaleFactorX
block.fill.scaleY = scaleFactorY

[/lua]

Bug Submission: 28513

Does anyone have any suggestions as to how to load in the @2x and @4x images into the object.fill?

I’m trying to make a platformer.  Each platform will be repeat filled with the texture.

It should just work if dynamic content scaling is used.

This is really important, not just for me but for others too I’m sure.

Or can anyone from Corona reply if this will be fixed soon?

Just as an FYI you submitted the bug on Thanksgiving.  I doubt engineering will look at it until Monday at the earliest because of the holiday weekend.

Most likely, based on your description, we are likely using the equivalent of display.newImage() not display.newImageRect(), the former does not do dynamic content scaling (i.e. @2x, @4x, etc.) where the later does.  I suspect they load the image, compute the scale needed to make it stretch/squeeze to fit the parent rectangle (or honor any repeating fill rules).

So what I would do in the mean time as a total hack is to calculate the scale factor for the device:  display.pixelWidth / display.contentHeight and based on your rules in your config.lua (since you know what they are) is if you are under your @2x size, load the normal file.  If you’re scalefactor is in between your @2x and @4x setting in config.lua then load the @2x version by name, and if you’re bigger than  your @4x scale factor load the @4x version of the file.

Rob

Hi @IcySpark,

Your scenario may be more complicated than mine, but I solved this in an app by just using “display.imageSuffix” to optionally append the current suffix to the “base” image file name. Something like this:

[lua]

local fimg = “myFillImage”

if ( display.imageSuffix ) then fimg = fimg…display.imageSuffix end

obj.fill = { type=“image”, filename=fimg…".png" }

[/lua]

This solution worked nicely for me, and it’s a very minimal amount of code.

Brent

Brent, thank you for your demo.  Works great.  I have changed is slightly to allow using it for any fill:

[lua]

local is = “”
if display.imageSuffix then
    is = display.imageSuffix
end

obj.fill = {type = “image”, filename = “images/platform32x32”…is…".png"}

obj2.fill = {type = “image”, filename = “images/platform64x64”…is…".png"}

[/lua]

Just a note however.  Typically content scaling just works in Corona, so it seems odd that it isn’t incorporated for image fills.

Might I suggest what you do with newImage and newImageRect are also incorporated into the obj.fill ie:

Use the current system as is for non content scaling images:

[lua]

obj.fill = {type = “image”, filename = “images/platform32x32.png”}

[/lua]

Use this or similar for content scaling images that need @2x @4x etc:

[lua]

obj.fill = {type = “imageRect”, filename = “images/platform32x32.png”}

[/lua]

Hi @IcySpark,

I believe this fix (acknowledgement of the proper image selection in object fills) will be implemented in an upcoming daily build.

Thanks,

Brent

This is fixed in the current daily build 2013.2097

Does anyone have any suggestions as to how to load in the @2x and @4x images into the object.fill?

I’m trying to make a platformer.  Each platform will be repeat filled with the texture.

It should just work if dynamic content scaling is used.

This is really important, not just for me but for others too I’m sure.

Or can anyone from Corona reply if this will be fixed soon?

Just as an FYI you submitted the bug on Thanksgiving.  I doubt engineering will look at it until Monday at the earliest because of the holiday weekend.

Most likely, based on your description, we are likely using the equivalent of display.newImage() not display.newImageRect(), the former does not do dynamic content scaling (i.e. @2x, @4x, etc.) where the later does.  I suspect they load the image, compute the scale needed to make it stretch/squeeze to fit the parent rectangle (or honor any repeating fill rules).

So what I would do in the mean time as a total hack is to calculate the scale factor for the device:  display.pixelWidth / display.contentHeight and based on your rules in your config.lua (since you know what they are) is if you are under your @2x size, load the normal file.  If you’re scalefactor is in between your @2x and @4x setting in config.lua then load the @2x version by name, and if you’re bigger than  your @4x scale factor load the @4x version of the file.

Rob

Hi @IcySpark,

Your scenario may be more complicated than mine, but I solved this in an app by just using “display.imageSuffix” to optionally append the current suffix to the “base” image file name. Something like this:

[lua]

local fimg = “myFillImage”

if ( display.imageSuffix ) then fimg = fimg…display.imageSuffix end

obj.fill = { type=“image”, filename=fimg…".png" }

[/lua]

This solution worked nicely for me, and it’s a very minimal amount of code.

Brent

Brent, thank you for your demo.  Works great.  I have changed is slightly to allow using it for any fill:

[lua]

local is = “”
if display.imageSuffix then
    is = display.imageSuffix
end

obj.fill = {type = “image”, filename = “images/platform32x32”…is…".png"}

obj2.fill = {type = “image”, filename = “images/platform64x64”…is…".png"}

[/lua]

Just a note however.  Typically content scaling just works in Corona, so it seems odd that it isn’t incorporated for image fills.

Might I suggest what you do with newImage and newImageRect are also incorporated into the obj.fill ie:

Use the current system as is for non content scaling images:

[lua]

obj.fill = {type = “image”, filename = “images/platform32x32.png”}

[/lua]

Use this or similar for content scaling images that need @2x @4x etc:

[lua]

obj.fill = {type = “imageRect”, filename = “images/platform32x32.png”}

[/lua]

Hi @IcySpark,

I believe this fix (acknowledgement of the proper image selection in object fills) will be implemented in an upcoming daily build.

Thanks,

Brent

This is fixed in the current daily build 2013.2097