(Fixed) Prevent movement on partial pixels

Edit: Aaaaand we're good. In case any other newbies out there are having my problem:

Under 'Runtime Properties' in Project Properties, setting Sampling to 'Point' instead of 'Linear' will fix this. We'll see what other problems/solutions this introduces down the road!

Hello all,

I'm trying to build a little pixel-art type game in a tiny window and running into a problem. When my sprite moves (currently have 8-direction movement in place), it sometimes looks blurry (ugly). I checked out the debugging window, and it looks like this is being caused by it stopping between pixels so Construct tries to mix everything together, creating mushy graphics.

<img src="http://i.imgur.com/h6Q68.png">

Is there any simple way to fix this? Off the top of my head, it seems like making movement only happen in whole-pixel (read: integer) increments will fix this, but I have no idea how to go about doing that. Also, I plan on replacing 8-direction movement to something controlled automatically, so I'd like something that isn't behavior-dependent, or at least is easy to apply to any movement behavior.

(And I promise, I'll replace Ness with something less stolen by the time I have something functional!)

You need to set the renderer to use point sampling, so that pixels will be drawn to the nearest whole number, rather than interpolated.

Click on your layout, then in the properties panel click on Application: Properties. Go do to Runtime Properties and set Sampling to 'Point'.

you could also have an always event that rounds your players XY position.

— - I may be wrong about this, but wouldn't that mess up the simulation in behaviours?

With point sampling, the object position still has sub-pixel resolution and only the display is rounded. If you round the actual position you will introduce errors in calculations for velocity, friction, gravity, etc. which could result in inconsistent movement. It also means you add an extra ACE to the event sheet which will be calculated every step.

First of all its one calculation, and im not sure about when behavior movement is done in the process (ie is it before or after the event sheets are run), but if it is done before then it would have no effect because it would move the sprite normally then round its XY to the closest whole number. and you wouldnt even notice a movement because the scene is first calculated, then drawn so when it draws it would plug-in the rounded XY position.

if movement for behaviors where calculated AFTER the event were run It still wouldn't really matter because all those things are calculated on a per tick basis using the current xy position it would just be rounded at a different time