Pixel Rounding Issue

Hey guys, have done some searching and seems like others are having similar issues to myself but I couldn't see a concise answer that applied to my situation, so apologies if I missed something obvious.

I'm in the early stages of making a very low res platformer, and having troubles with pixel rounding. With it off, I get obvious visual artifacts on some of my sprites (some sort of texture wrap around?). If I turn it on, the visuals are fixed, but I get significant amounts of jitter around the player object. The player is an invisible hitbox with several sprites oriented to it (including the camera), and they appear to move slightly out of synch. Here are current builds with pixel rounding on/off:

OFF

dl.dropboxusercontent.com/u/58256916/Test/MiniQuestNPR/index.html

ON

dl.dropboxusercontent.com/u/58256916/Test/MiniQuestPR/index.html

A+D to move, J+K for jump/attack

Anyway feel like I'm probably missing something obvious here so much thanks in advance to anyone who takes the time to set me right.

I've had similar issues when sprites werent at exact locations, so for instance if sprite.x was 200.25 instead of 200.

This bothers me too. I'm making a game based on Gameboy Color specs (160x144 resolution) and pixel rounding seems to be causing a lot of issues with jump-thrus. IE: run off the edge of a jump-thru then try to make your player fall back towards the jump-thru and they will teleport back on top of the platform.

Ashley

What is the reasoning behind visual pixel rounding with floating point positions instead of integer-based positions? Is there any way to have all positions strictly integer-based?

— Your game is SO CUTE. I really like the graphics.

I've been having a similar issue with my game, there's a weird jittering going on whenever the player is going left/right. I tried to track it down but I didn't think of turning pixel rounding on/off... I'll have to try it tonight.

Here's a quick capx to apply pixel rounding to the sprite's position.

https://dl.dropboxusercontent.com/u/161279569/construct2/forum/truepixelrounding.capx

Basically:

Every Tick

Player | Set Position round(Player.X), round(Player.Y)

As you can see in the example, solids seem to push the player up one pixel (bug?). I have pixel rounding turned OFF in the capx.

Edit:

I should also mention I was incorrect thinking the pixel rounding is affecting the jump-thru. The bug is still present in this example, even with the recommended one pixel height.

—

How are you positioning the sprites to your hitbox? And can you post a capx? It doesn't have to be one of your game. A quick mockup with basic colored blocks will work. Maybe we can all help figure it out :)

superdbop dl.dropboxusercontent.com/u/58256916/PRSC.png

I should probably have shown this from the start, there's a lot going on there. The player is split into multiple pieces that can be switched out or animated independantly (try attacking while running/jumping) and the outlines are also separated on a different layer to prevent certain overlaps. I also shuffle the layers a little during some animations. Ummm. This project was supposed to be an attempt at doing something less needlessly complicated than my usual fare, go figure. You might be interested to see the last thing I was playing around with, which also roughly uses the GB limitations (except scaled to the nearest even fit for 1080p), I never noticed these issues here but then it's also much simpler, maybe I'm just trying to do too much.

dl.dropboxusercontent.com/u/58256916/Test/GBNew/index.html

I also tried a similar thing with all the art pre-scaled to 4x size, which seemed to work a bit better. That might be the way to go?

andreyin Thanks! I'm first and foremost an artist, so I worry about visual considerations before anything else.. hence my terrible OCD character setup~

CC & C2 are simply not designed for low resolution games. Variable time step, no tiles (even though high res games use them too), floating points, etc. Pixel rounding also doesn't come into play when scaling or rotating - you get that "pixel art in a flash video" look.

Pretty funny because there aren't that many "modern" games being made them due to performance issues and until Spriter is finished you can only use sprites anyway.

Anyhow..."solutions"...Only way to prevent the shaking & seams w/ pixel rounding is to move your player by framerate*dt, but that only fixes it when moving strictly horizontally and is pretty stupid for obvious reasons. You can try putting the camera code before your player movement code but that will probably just shake the rest of the screen instead of the player. You can also try int() on your camera to prevent seams w/o pixel rounding but then you'll get more shaking. Adding 1px transparent borders around your platforms helps there but you can't do that with tiled BG objects.

Personally I just leave pixel-rounding off and use sprite objects acting as tiles (see:TMXimporter) then paste them to a canvas prior to destroying them, preventing seams.

—

Hmm... Maybe try using the Pin behavior. This way, you can avoid imagepoints and pin your sprites On Start of Layout rather than setting the position every tick.

Or... Maybe the combination of Pin and the position rounding I mentioned earlier will allow you to stay pixel-perfect without the need to turn Pixel Rounding on? Just make sure the position is being rounded early in the Every Tick.

Hopefully someone else can help too. I'm still a Scirra newbie :D

—

Would a camera following the sprite with lerp do the trick? I just thought of that and I'll give it a try when I arrive home, but I'm feeling it can at least solve something.

EDIT:

Now I thought about making JUST the tiles be pixel rounding dependent, while the animated sprites (like NPCs/player) do not depend on it. Is that plausible?

Hummm. Currently considering giving up, removing camera movement entirely, and having single screen maps, zelda style. I guess that's the fallback plan. Have messed around with some of these ideas but without much luck. I guess upscaling all the art externally to a higher resolution would make the issues far less visible, but that seems like a silly way to do things. A large part of the issue is that because the player sprite is made up of several components, the individual pieces end up disjointed from each other on random frames, so some of these solutions might otherwise work, but not here. Looking at "most acceptable alternative" for now, since it looks like I won't be able to get things exactly perfect without considerable effort.

if you post a generic capx of just the one screen like that i can mess around with it and see if i can get it to work otherwise it would be kind of hard to recreate the multi-object player without seeing more of how you did it.

Might as well, if it could help. Here's the whole thing.

dl.dropboxusercontent.com/u/58256916/Test/MQCX.capx

—

May I say how amazing your graphics are?

Also: CAPX

have a look. I fixed the horizontal problem by shaving 1 pixel off EACH side of the Player.boundingBox

I also moved the image point by one pixel vertically, seems to have solved some of the vertical jiggling.

I suspect you need to play with odd and even numbers in your dimensions and image point positions.

Also, it might help to pin your accessories to the player sprite, instead of setting their position. But even then, you need to find what numbers play well with Construct's engine. Remember, if you force Construct to divide a pixel in half, it's going to have trouble deciding which half, which I suspect is the cause of the jitter.

A 1x1 pixel player sprite might work, but then you need a new "player" sprite for collisions and the like.

Let me know if this helps.

OK, what gives??

Vertical jittering can't be fixed even if I set the player sprite bounding box to an odd number.

Ashley could this be a candidate for a bug report? Is there no way to have smooth vertical scrolling at this resolution, when pixel rounding is on? Why does Construct2 treat horizontal and vertical scrolling differently?

— However, if you turn pixel rounding off (which makes for smooth scrolling), you can get rid of the seams by making the Height of your tiles 15 instead of 16 in the level editor (not in the sprite editor). That way you are forcing the renderer to ignore a whole pixel, and since the problem seam is less than a whole pixel, you solve it.

Again, this is something that, ideally, shouldn't be happening

christina Thank you! Knocking that pixel off seems to work just fine, that'll do me for now. I can't open up that capx as I'm not running the latest beta (and it just failed to download twice in a row, my connection has been poopy all weekend so I'll take another look later today). Should I be aiming for odd numbers in my dimensions? I've been loosely sticking to multiples of 8 just out of habit, hence why all my tiles are 16x16..

Also wow always impressed with how helpful everyone is here on these forums, thank you all of you who've been looking into this. Hopefully somewhere down the line I'll have a game for you all to try.