Completely unexpected behaviour on resize

I'm stretching a sprite width do match WindowWidth, the resulting width is completely unpredictable and doesn't correspond with reality.

I included a capx(link) and a preview (URL).

Please help me, I don't understand this!

I'm stretching a sprite width do match WindowWidth, the resulting width is completely unpredictable and doesn't correspond with reality.

I included a capx(link) and a preview (URL).

Please help me, I don't understand this!

EDIT: The window size is always correct, is the resized object that do not make sense.

I partly fixed this.

I understand that since the Scale Rate is 100% the width SHOULD be multiplied by two. If you change my capx setting W to WindowWidth/2 and now it almost works, but there is a percentage of error that changes based on the width of the medium and that I don't understand. Help Ashley!

Bump? Please someone! I'm desperate..

Ashley, can you at least tell me the method that handles the scale mode resizing in the exported c2 unobfuscated code so that I can take a look at it?

I'm afraid I'm not quite sure what you're trying to do. Do you want the sprite's width to match the browser's width while keeping the sprite's ratio? And is that regardless of the window aspect ratio and the scale mode zooming or not?

I'm not sure if it will help, but in scale mode, the zoom is dependent on the window height - you can resize the browser to see that the window width doesn't have anything to do with the zoom level.

Arima thanks for trying.

Basically I'm trying to find a way to STRETCH (withouth mantaining proportions) the background of my app, so that even if the aspect ratio is not 1.5 (iPhone) the background covers the whole screen. The element are then repositioned while mantaining their aspect ratio, only the background sprite will become "deformed".

To do this, after checking the aspect ratio, I change the width of the background to WindowWidth/2, this is because since the canvas is scaled by 100% it SHOULD double.

In reality there is a discrepancy between the canvas that c2 creates and the real WindoWidth, probably this is a bug or I am simply ignorant.

Open my capx if you can, I added an event.. click on the rightmost pixel of the screen and you'll see that there is a discrepancy.

EG:

640x1366(res) aspect ratio 0.47..

Rightmost Pixel-> Mouse.X = 1019, Absolute 1365 (which is the window-1)

Another EG:

596x570(res) ratio 1.04..

Rightmost Pixel-> Mouse.X = 458.4, Absolute 569

This changes as the aspect ratio changes, going from a few pixels to huge gaps.

If I can get the REAL canvas size of C2 I would've fixed my problems, because I would set the W varible to the real width that C2 is using.

I need it to be precise to reposition object (for example sprite set X = (Width-3)-(self.Width))

u mean something like this background ?

http://ohrly.net/boingbeta/

I'm not sure if I understand what you mean, but I just set the size of the background to the size of the window...

Wishy yes! It is! How do you do it? Scale mode? No Fullscreen? Parallax.. can you fix my capx to make it work so I can see how you are doing it?

http://dl.dropbox.com/u/65731657/bgresize.capx

• Assign the BG pic's Origin Top-Left (so 0,0 is upper left)
• Add Anchor behaviour (left to left, top to top, right to right, bottom to bottom)

i think you were searching too far :)

— Thank you, you fixed my problem! I owe you!

But still, while your solution works, there is actually no need for my way not to, and I would love an explanation from Ashley because there is a big discrepancy between the window size and the actual canvas size that c2 produces!

Basically, the only way to get the actual canvas size is to get the Width of the stretched sprite (as per Wishy method). But surprise! There is no safe way of doing it. Check this example: dl.dropbox.com/u/1606950/wtf2.capx

On the start of layout the size of the Sprite is equal to the layout size. Then the first "pass" to a true condition it goes to 0x0 then it goes to the "magic" number that the canvas get.

In my real game, debugging the same way, it needs two passes to get to the "stable" value, the first 0x0 the second a number that rounded is almost the final value, the third the "stable" value.

Now I understand that the "stretching" is a behaviour that probably doesn't get initialized at the start of the layout but after a while (an unpredictable while by the way), why isn't there an event that tells us when everything is actually ready from the engine perspective?

Can you implement a way to retrieve the actual canvas size? Why isn't there an event in case the user resize the browser?

I hope this doesn't get ignored..