Sprite Image Editor - ERROR over 1000 px

Problem Description

I loaded a PNG file with transparency which was basically an upside down U. I then began to define the SET COLLISION POLYGON points following the shape of the U. Everything works fine if you manually enter the X,Y numbers. But, if you attempt to fine tune the settings using the up/down adjusters an error occurs switching from 999 to 1000 and above.

Instead of changing from 999 to 1000 it changes from 999 to 1,000 which makes the program think it returned to 1.000 thus moving the point and line to the far left of the graphic.

Attach a Capx

No file to upload, just import a picture as a sprite larger than 1000px by 1000px and then set the polygons.

Description of Capx

N/A

Steps to Reproduce Bug

• Step 0 : Set the Layout to 1920 x 1080.
• Step 1 : Import a picture (1920 x 1080) as a SPRITE.
• Step 2 : Place it on the LAYOUT
• Step 3 : Right click the sprite and choose edit.
• Step 4 : Select the COLLISION POLYGON tool
• Step 5 : Select the lower right point.
• Step 6 : Using the UP / DOWN fine adjustment tool next to the X, Y boxes reduce the X value.
• Step 7 : Now manually set X to 999
• Step 8 : Increase X by 1 using the UP / Down tool.

Observed Result

Any number larger than 999 will cause this error.

Watch the blue line shift to the far left.

Expected Result

As described above

Affected Browsers

N/A - in program only

Operating System and Service Pack

Latest Version of Windows 10

Construct 2 Version ID

Release 239 64Bit

This sounds like it could be a localization problem. I think you should post your Windows region settings.

EDIT: It seems to be broken for US English settings too, which was unexpected.

I not an expert programmer by any means. But, I think it is within the main program itself. It seams to handle larger numbers as floats instead of integers.

Thanks for the response.

I not an expert programmer by any means. But, I think it is within the main program itself. It seams to handle larger numbers as floats instead of integers.

Thanks for the response.

The transition from 999 to 1000 isn't significant for floating-point numbers, so why would that have anything to do with the problem? The only significant thing that happens is the introduction of the thousands separator, which will be a comma in some regions, and a period in other regions. There appears to be a mismatch between which thousands separator the control uses, and how the application interprets it. You can see this for yourself by typing '100,000' into the box. It will interpret it as 100.

Alternatively, it may just have an issue with non-digits in the field. Using a period instead doesn't seem to change the result.

Thanks, should be fixed in the next build.