My mistake, I meant ScrollTo. MoveTo is one of Rex's add-ons.

I haven't been using pixel rounding since having these issues crop up. Despite that, aside from the overt smoothness of everything I haven't really seen any seams or related problems pop up. I guess it's a plausible solution to just ignore that option nowadays? I'd like to say that conclusively, but I'm not as versed in Construct as other similar programs.

I've actually seen these problems in other creation software. It seems to be a common problem when making pixel-accurate games with engines that are designed with higher resolutions in mind. Erek's potential solution is sophisticated sure, but most people probably shouldn't need to go to those lengths to eliminate all of the movement stutters. Risk seams or other undesirable side-effects by leaving pixel rounding off, or set it to on and constantly wrestle with every movable object in your game to ensure that every number is being rounded to an integer.

Ashley Is it possible for behaviors like MoveTo or Sine to account for whether pixel rounding is set to on or off? Are they supposed to already do that? On my end, they seem to operate in fractions regardless of what project properties are set. If we can force these behaviors to always use integers with round(), surely it's possible to implement some kind of option that will just make them default to that?

Seems like my problem was the result of something different on my end. Sorry it couldn't help!

I'm not sure if it's just because I haven't used Construct in a long time, but I experienced horizontal jittering while scrolling and using HTML5 or the node-webkit exporter. I haven't tested it on multiple machines, so I don't know if it's related to my computer or not.

Anyway, I was able to remove the jitter by adding a round() function to my X coordinate. It must have incremented the screen coordinates in decimals and not whole numbers, which seems to have been a problem for my project.

I have pixel rounding and point sampling enabled if that happens to be of any additional help!

I'm a little inclined to say your opinion leans toward fact!

Seems the complications of high pixel density technology means anybody using these kinds of displays will have to create some kind of alternate resolution profile when working in Construct for the time being.

I really appreciate the timely response from Ashley, it's inspiring to know that attention has been paid to so many emerging trends, even if it is still quite early to provide a decisive fix on the issue.

Ah, okay. I'm currently running r152 at a resolution of 3200x1800. I think 2560 counts as high DPI as well, but I'd assume this is a large enough jump for the pixel density to be different.

I did try resetting all dialogs as recommended, but I still come back to this very problem. I might be able to get a hold of another machine with a comparable resolution and fresh install to see if I can reproduce these display issues.

EDIT: I've just made a fresh install on a new machine with the same kind of display and resolution. Construct is still exhibiting the same issues as before.

I think the issue is mostly isolated to improper dialogue box scaling in C2 when windows scaling is enabled to 200% at high pixel densities (around 275 dpi). I'm going out on a limb with this one, so I hope somebody else out there can add some additional testimony to this..

I'm curious, as there hasn't been a lot of discussion regarding this issue on the forums. There's official support for running Construct-built games with DPI awareness, but what about running the editor itself on high DPI devices?

When running the editor under screen resolutions comparable or higher than retina displays, the editor breaks, tears, and hiccups. This can be fixed by changing the OS window scaling below 150%, but it results in everything being rendered unreadable. The compatibility issues are ugliest when in the event sheet editor, where dialogue boxes overlap radio or form boxes and commands on the edit action/condition windows vanish when they are moused over.

Here's an example:

<img src="http://i.imgur.com/sc3EiTh.png" border="0" />

Another example:

i.imgur.com/G6fnTb3.jpg

In the above URL, you can see that set scale, size, width, x, and y have all vanished from the size and position action set. This is another issue that occurs when using Construct 2 on high resolutions.

So my question for now is, does anybody else out there develop with Construct 2 on high DPI displays? I realize it's a real shot in the dark to try and ask for any feedback or improvements made for emerging technologies, but if Construct 2 is really billing itself as a future standard, then there must be something that can be done to alleviate high resolution woes.

I'm also wondering the same thing. It's a shame there seems to be no implementation.

I've been trying to find where Construct saves game states to the disk for days but have had no success. I'd really like a way to remove them for testing purposes.