the canvas can be any size, can't it? would it help if you set the final viewport size to the desired dimension and only resize the canvas?

Ashley you're right. You're always right. Thanks again, and sorry to have taken up so much space to figure out this stuff.

So apparently the only way to achieve smooth 1-pixel movement is by not using dt, and fixing the min framerate to 60fps.

Yes, I sacrifice vsync, but it looks super smooth on all the devices I tested on. It's a super tiny game that takes hardly any CPU and RAM, 60fps should be easy to maintain.

It's also how old arcade games used to do it. Granted, they had unwavering 60fps, due to fixed hardware.

I don't have access to a 120hz monitor, but if what you say is true Ashley, then it will run at double speed. Is there a way to fix the max framerate to 60? Should I just edit the .js?

From this article: http://www.learn-cocos2d.com/2013/10/ga ... me-or-not/

[quote:p7b7x8s3]Even today, framerate-dependent gameplay is the de facto standard for 2D games on gaming devices with a locked refresh rate (meaning: vertical synchronization is always enabled).

[quote:p7b7x8s3]Most moderately complex games employ a game simulation module that is updated at a fixed rate regardless of the framerate. This game simulation is completely separated from the visual side of things, just like OpenGW. Many games can do away with a 30 Hz or even a 10 Hz update rate of the game simulation. The delta time is only applied to the visuals.

What happens is as follows: the game world is updated once every tenth of a second and rendered to the screen in the same frame. The visual side then (linearly) interpolates the current game object’s positions by multiplying their velocity with the delta time for the next 5 frames, until in the 6th frame the game world is updated once more.

Could we have something like that in Construct? A simulation of fixed fps. It makes *SO* much sense for an engine that only does 2D games

Ashley thank you very very much for the explanation and example.

Having control over pixels is important. Ashley is your final word that consistent 1-pixel per frame movement can't be achieved with C2? If it can be achieved, a push in the right direction please? Shovel knight can do it and apparently game maker too

Runs my project fine?

So could you record your screen with licecap or something and show me the gif, where my project achieves 1 pixel per frame consistent movement? Because none of the computers or monitors or browsers I've tried do that. Please don't make me feel incompetent, if you have info share it!

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.