christina's Forum Posts

  • newt can you replicate 1px per frame consistent movement without subpixel movement? May I see it please? It's driving me mad that I can't make it happen.

    My comment about pixelart being useless for 600+PX resolutions was misunderstood. I mean pixelart shines in resolutions under 300x240 but those are exactly the resolutions where each pixel matters. By the way my system is quite typical for gamers nowadays, on the high end. I don't understand why shovel knight works pixel perfectly on my system at NES resolution but not construct 2

  • R0J0hound Ashley so it's decided, c2 or chromium/NW.js can't do precise 1pixel per frame movement. So I should stop trying for retro pixel platformers where single pixels matter. It should either be fake pixel games with ugly subpixeling or really huge resolutions of 600+ pixels where single pixels don't matter, but pixelart is also sort of useless.

    Am I assessing this correctly?

  • Ashley liquid kids, parasol stars, shovel knight, three wonders, etc.

    All retro games with parallax Scrolling were able to consistently move the player 2 pixels per frame and the background half that per frame. Is there proof of concept of C2 doing that please?

  • R0J0hound thank you for all the help again... Unfortunately it doesn't look acceptable to me. Compare it to the perfectly smooth scrolling of Shovel Knight above. I'm despairing

    For example, in your capx: with 60px/sec max player speed scrolling should be 1 px per frame (1,1,1,1,1,1, etc).

    Instead it's 2,1,1,2,1,2,2,2,2, etc I don't know what's going on.

    Ashley I still haven't managed to implement your solution. Is the engine capable of smooth and accurate scrolling? I really can't get it to behave

  • Ashley thanks again for the in-depth reply. I'm not implying in the least that any of this is simple and uncomplicated, and I know you're a genius programmer, and I'm super thankful for C2, and the community and your guidance.

    I think I understand now the limitations of half pixels.

    I agree with you, high quality and pixel rounding off *does* solve the smooth scrolling problem. But it introduces subpixel movement.

    But you say this can be prevented too, by enabling and disabling the movement? Would you mind helping me out a bit? Your solution is

    * high quality full screen scaling

    * pixel rounding = off

    * tickcount%2 = 0 (even ticks) -> Platform enabled,

    else: plaform disabled

    Is that right? I can't get it to do what we're after. Am I doing something wrong?

    Let me define the new problem that high quality + pixel rounding off creates for me:

    It does preserve the blocky sprite style. But it allows sub-pixel movement, which destroys pixelart completely, as do rotated non-square pixels.

    Retro platformers, and neo-retro platformers like Shovel Knight (coded in a custom C engine) don't allow sub-pixel movement.

    As is evident from studying this Shovel Knight gif, no sub-pixel positions occur at all, even when scrolling

    You probably had an amiga or speccy growing up. Their respective emulators can handle unwavering fps and pre-FPU pixel-perfect position calculations admirably.

    I promise I'm not asking you to code my game for me, I'm just completely baffled. If you're saying C2 isn't to blame, then it's capable of doing what I want, and I just can't see a way to do it. That's why I'm asking for help, we'll make a perfect capx and save it as a template and bury this stupid issue forever.

    Would it help if I kept a decimal value position stored in a variable and only move the player when its integer is >0? Then subtract the integer and keep the float, which will continue to increment in irregular ways (because of dt). That way there's no brute force rounding, and even 0.5 increments will only affect movement in a predetermined way.

    Is that a good direction to go? I'm probably not clever enough for all this. But if you tell me it's possible, I'm determined to get proper pixel-quantized movement without crippling rounding and smooth scrolling with no sub-pixel movement.

    thanks again for your time, I know I'm a super small niche of C2 clients

  • Ashley newt thanks for the replies <3

    Ashley you're absolutely right, I was wrong to not have accounted for precise pixel per frame speeds. And thank you for the thorough reply.

    Platform.maxSpeed= 60 pixels per second is the ideal speed, as we've all figured out.

    The background layer, at 50,50 parallax also scrolls smoothly, presumably moving at 30pixels per second or 1 pixel every 2 frames. (EDIT: I screen captured it and both player and background layer are jaggy, but not very noticeable)

    _________

    Can we account for the fact, though, that Platform.maxSpeed = 30 has the jaggiest scrolling on the parallax layer?

    The player would theoretically move at 1 pixel every two frames (30 p/s divided by 60Hz = 0.5), which sounds fine. Regular intervals are fine for the human eye as you said, and I can confirm as an animator.

    In practice, however, player moves at 1 pixel every frame, except for rare frames when it moves 0 pixels. I don't know why.

    The parallax layer would theoretically scroll at 15frames per second, which would produce a regular pacing of 1pixel every 4 frames, which would also be fine. However practically, it staggers even more: 1px,0, 1px, 0, 0,1px, 0,0, 1px, 1px, etc

    I think this is what has confused me most. I can't account for that error in rounding.

    You can try it in this stripped down minimal .capx (scrollx = player.X for simplicity, I do not introduce my own rounding anywhere)

    https://dl.dropboxusercontent.com/u/28087823/Construct%20Examples/DAIKO_TWINS_JERKING_MOVEMENT/jerking30.capx

    (I tested by screen capturing a gif of the game window)

    Is there a way for the engine to evenly distribute those increments in time? Has anyone else ever checked that 60px/sec movement, with pixel rounding on, does indeed move the player 1 px per frame? Because my tests say it isn't so.

  • Thank you newt, thank you R0J0hound

    You would probably have to make your own movement system rather than use the platform behavior.

    You're right. doesn't that defeat the purpose of a game making tool though? Last time I made my own movement system, Ashley discouraged it, and for good reason. It couldn't handle slopes either. But even so, what kind of a custom movement were you thinking? Set X to self.X+60*dt ? Isn't that what platform movement does, when I've maxed acceleration and deceleration?

    Hmm...

    One thing you could try is to use the "set minimum framerate" action to set it to 60. That way dt will stay at 1/60 instead of going to 1/30 at times.

    Another idea to get things smoother is to only use speeds that are evenly divide into 60. 36 doesn't but speeds like:

    1,2,3,4,5,6,10,12,15,20,30,60 will give a more even motion.

    3

    I set the minimum framerate to 60 (even though I don't like the implication that it might run worse on some systems). And I set the player maxspeed to 30.

    Still some jerking. And parallax is even worse: by setting the background parallax layer to 50,50 , it would theoretically move at 15pixels/sec which is a number that evenly divides into 60.

    But in practice, it creates a ton of jerkiness!

    When I set player.maxspeed = 60, I do get a smooth result.

  • OK, when it's drawn. So how can I make the game draw 1 pixel movement per frame? Instead of irregular increments of pixels?

  • andreyin newt the tearing did indeed go away! Victory!

    Defining frame now: Frame as in, animation. As in, if you record the screen, as in andreyin's capture for example, each *frame* is not a construct 2 tick, it's a construct 2 frame. Like fps. I don't know how else to explain it.

    And right now, even though tearing is fixed, jerky movement is NOT fixed. Have a look:

    What i want is that every frame, the screen scrolls by 1px. What's happening instead is (due to the rounding probably? or something else?) the background moves a different number of pixels each time. 1, 2, 3, even none.

    This is very noticeable in fullscreen.

    Is there a way to fix it? Is it just a matter of finding the correct player.Platform.MaxSpeed ? Is it something else? Ashley?

  • I tried round(lerp()) and ceil, and floor :/ nothing. I want the player to consistently move 2 pixels per frame. Not per second, not per tick. Is that doable?

  • I guess what I really want to know is: how can I move the player 2 pixels per frame and the background 1 pixel per frame. Consistently. At any size, even fullscreen (where 1 game pixel is obviously going to be huge)

    Even when I scale up the 128px layout to full screen, 1 pixel per frame would still read smooth.

    And then I can speed up. R0J0hound ? Magistross ?

  • but your camera completely jerks. Like, I stop in place and the camera slowly shifts into place, and then, half a second after it's stopped, it clicks one more pixel! It's very distracting. Apparently you have pixel rounding on as well. It doesn't scroll to subpixels.

    And anyway even if yours did (it doesn't), I don't want mine to.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • in full screen? it's very jerky, yes. Performance is smooth, but lerp scrolling is jaggy.

  • thanks — Tried it, it's even jerkier then! Try it?

  • 60 is too fast. Are we sure it can't work with smaller max speeds? If so, I should have thought twice about the tiny size