Display.newImageRect bug

Audio and Graphics
#1

Hi,

I am displaying an image (.png with transparent background) and I noticed an annoying bug: it seems that the right edge is sometimes displayed at the left of my image.

Here is a screenshot of what happens:

2ergQjj.png

I thought at first it was a bug in the scaling of the image, but even when I don’t scale it still happens.

Here is the code I use to display the image:

[lua]myPlat.blockleft = display.newImageRect( myPlat.group, “platformleft.png”, 85, 87)[/lua]

The image is indeed 85 * 87px so no scaling is supposed to occur.

Thanks

endy

#2

Your best best to getting this looked at is to file a bug report at the below link:

http://developer.coronalabs.com/content/bug-submission

FWIW I have used/am using newImageRect in my projects and am not seeing this problem.

#3

Thanks Alex for the suggestion, I’d like to know first if anyone is facing the same issue. There might just be a simple workaround.

#4

Hi @endygwa,

Please don’t file a bug report (yet). Let me see some more of your code first, because very likely it’s an honest mistake or something else.

Brent

#5

Hi Brent,

 

After a long time, I finally found the culprit.

It was very hard to find, but the issue is easy to reproduce.

 

The issue occurs if texture wrapping display.setDefault( “textureWrapX”, “repeat” ) is enabled AND the display object is assigned a non-integer value of X. (or Y if your texture is repeating on the Y axis).

 

My platform class has a method to generate the platform’s position randomly and I was not rounding it to the closest integer (Lua and its non-existant datatyping…)

I guess that a non-integer value of x/y forces texture re-sampling even though the display object has a declared size exactly the same as the actual image (85 * 87 px). Documentation http://docs.coronalabs.com/api/library/display/newImageRect.html#texture-sampling says texture re-sampling only occurs when the newImageRect is using an image sheet (not the case here) and need to be resized (not the case here). Clearly here,  display.setDefault( “textureWrapX”, “repeat” ) should not have any impact on a newImageRect from an image (not image sheet) that is not resized, so I still consider it a minor bug.

Maybe a “Gotcha” section should be added to http://docs.coronalabs.com/api/type/DisplayObject/x.html to mention that x/y must be integers or else glitches may appear. I know when you think about it, it does not make much sense to assign non-integer values for something supposed to be pixels, but I can see a lot of people setting x or y values calculated from a height/width ratio or something, thus assigning non-integer values without even noticing.

Anyway, you were right that there was something wrong with my code, so thank you for that. 

endy

EDIT: I’m getting closer, but the above only works if the device has exactly the same resolution defined in config.lua, if I try it on devices with a different resolution and scaling occurs the issue is still there.

#6

I thought I had fixed the issue, but it was only because I was testing with the simulator or a physical device that had the same resolution as defined in config.lua.

My config.lua is using the following settings for scaling

application =

{

    content =

    {

    fps = 60,

        width = 1080,

        height = 1080 * display.pixelHeight/display.pixelWidth,

        scale = “zoomEven”,

    }

}

In short for any device/simulator with a width lower than 1080 (hence scaling occurs), if **display.setDefault( “textureWrapX”, “repeat” ) **is used then transparent png images are affected with the issue.

I will post a short code to let you reproduce the issue very soon.

#7

Hi @endygwa,

Yes, please post some example code when possible. However, I do not understand your config settings. The width should always signify the “short” side of the display, even if you’re designing a landscape-oriented app. The height value should always be greater than the width, because there are not (currently) any “square” devices to contend with.

Essentially, I recommend that you specify a basic config setup with, for example, a width/height of 320/480 respectively.

Now, the texture wrapping thing may be totally separate from that, but at least begin with a more simple config setup. :slight_smile:

Take care,

Brent

#8

Hi Brent,

 

For the config file, this is something I think I found in a tutorial posted here. I am not sure of what you mean, the height is indeed greater that the width in my config file, I have:        

width = 1080,

height = 1080 * display.pixelHeight/display.pixelWidth

Because pixelHeight > pixelWidth , height > 1080.

 

I have not worked much on display scaling for all types of devices so maybe I should do that first and see if the issue still occurs. It’s still a bit frustrating because it only appears when **display.setDefault( “textureWrapX”, “repeat” ) **is used yet the images affected by the issue are not even using .fill, they’re just simple newImageRect.

 

Thanks

endy

#9

Hi @endy,

Do you revert the textureWrapX (and Y to be safe) to the default (“clampToEdge”) when you’re finished using that feature?

Can you reproduce what is happening with the newImageRect()s in a very basic project which doesn’t use texture wrapping at all?

In your case for the width/height thing, I suggest you use a “static” content size (set integers), at least for testing/debug on this issue.

Thanks,

Brent

#10

Your best best to getting this looked at is to file a bug report at the below link:

http://developer.coronalabs.com/content/bug-submission

FWIW I have used/am using newImageRect in my projects and am not seeing this problem.

#11

Thanks Alex for the suggestion, I’d like to know first if anyone is facing the same issue. There might just be a simple workaround.

#12

Hi @endygwa,

Please don’t file a bug report (yet). Let me see some more of your code first, because very likely it’s an honest mistake or something else.

Brent

#13

Hi Brent,

 

After a long time, I finally found the culprit.

It was very hard to find, but the issue is easy to reproduce.

 

The issue occurs if texture wrapping display.setDefault( “textureWrapX”, “repeat” ) is enabled AND the display object is assigned a non-integer value of X. (or Y if your texture is repeating on the Y axis).

 

My platform class has a method to generate the platform’s position randomly and I was not rounding it to the closest integer (Lua and its non-existant datatyping…)

I guess that a non-integer value of x/y forces texture re-sampling even though the display object has a declared size exactly the same as the actual image (85 * 87 px). Documentation http://docs.coronalabs.com/api/library/display/newImageRect.html#texture-sampling says texture re-sampling only occurs when the newImageRect is using an image sheet (not the case here) and need to be resized (not the case here). Clearly here,  display.setDefault( “textureWrapX”, “repeat” ) should not have any impact on a newImageRect from an image (not image sheet) that is not resized, so I still consider it a minor bug.

Maybe a “Gotcha” section should be added to http://docs.coronalabs.com/api/type/DisplayObject/x.html to mention that x/y must be integers or else glitches may appear. I know when you think about it, it does not make much sense to assign non-integer values for something supposed to be pixels, but I can see a lot of people setting x or y values calculated from a height/width ratio or something, thus assigning non-integer values without even noticing.

Anyway, you were right that there was something wrong with my code, so thank you for that. 

endy

EDIT: I’m getting closer, but the above only works if the device has exactly the same resolution defined in config.lua, if I try it on devices with a different resolution and scaling occurs the issue is still there.

#14

I thought I had fixed the issue, but it was only because I was testing with the simulator or a physical device that had the same resolution as defined in config.lua.

My config.lua is using the following settings for scaling

application =

{

    content =

    {

    fps = 60,

        width = 1080,

        height = 1080 * display.pixelHeight/display.pixelWidth,

        scale = “zoomEven”,

    }

}

In short for any device/simulator with a width lower than 1080 (hence scaling occurs), if **display.setDefault( “textureWrapX”, “repeat” ) **is used then transparent png images are affected with the issue.

I will post a short code to let you reproduce the issue very soon.

#15

Hi @endygwa,

Yes, please post some example code when possible. However, I do not understand your config settings. The width should always signify the “short” side of the display, even if you’re designing a landscape-oriented app. The height value should always be greater than the width, because there are not (currently) any “square” devices to contend with.

Essentially, I recommend that you specify a basic config setup with, for example, a width/height of 320/480 respectively.

Now, the texture wrapping thing may be totally separate from that, but at least begin with a more simple config setup. :slight_smile:

Take care,

Brent

#16

Hi Brent,

 

For the config file, this is something I think I found in a tutorial posted here. I am not sure of what you mean, the height is indeed greater that the width in my config file, I have:        

width = 1080,

height = 1080 * display.pixelHeight/display.pixelWidth

Because pixelHeight > pixelWidth , height > 1080.

 

I have not worked much on display scaling for all types of devices so maybe I should do that first and see if the issue still occurs. It’s still a bit frustrating because it only appears when **display.setDefault( “textureWrapX”, “repeat” ) **is used yet the images affected by the issue are not even using .fill, they’re just simple newImageRect.

 

Thanks

endy

#17

Hi @endy,

Do you revert the textureWrapX (and Y to be safe) to the default (“clampToEdge”) when you’re finished using that feature?

Can you reproduce what is happening with the newImageRect()s in a very basic project which doesn’t use texture wrapping at all?

In your case for the width/height thing, I suggest you use a “static” content size (set integers), at least for testing/debug on this issue.

Thanks,

Brent