How do I eliminate jerkiness/tearing when fullscreen

It was working OK with the alternate enable/disable platform behavior for me, the only reason it looked bad was the parallax background. Note that game animation you posted uses a fixed background, presumably to avoid the same problem of making scroll aliasing obvious. I don't recall many retro games using an approach like that, unless it's like Sonic where the background is scrolling relatively slowly (and at a variable rate) which makes the effect less noticable.

I'm pretty sure Construct 2 has all the tools you need to do this, it's just difficult to make the right game design choices. If you are deliberately making scrolling low-resolution, something like parallax is going to suddenly make scroll aliasing very obvious, and it's made worse when you blow it up on to modern HD/2K/4K screens, whereas retro games were on an SD screen at best.

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?

What if you save the previous x/y positions, and then do a comparison everytime you reposition an object? So you'd assign the position to prevX, prevY.. then you move the object. Then you compare- has object traveled further than 1 pixel; if so then reposition.

If at 60pixels/sec it's moving at 2 pixels per frame sometimes then your graphics card isn't really supported by browsers. I probably have the same issue with my blacklisted card, which never can reach 60fps with html5 on browsers even though normal exe games can.

Basically there are three things that could be at fault: C2, the browser engine, your machine.

You've likely played those retro games you mentioned on your machine without issue, your PC is capable so we can rule that out.

Here in this topic we explored many ideas from the C2 side to improve things. Since they're not working it can either be C2 or the browser. We can do tests with C2 vs other html5 engines or straight JavaScript and see if any do it better, and if they do we can find what they do different. However, I don't think C2 is to blame.

Even with a simple js to move a box isn't smooth for me on my machine. So it's the browser to blame I'd say. It's either the js engine or the renderer. As mentioned earlier in this topic I was able to take a JavaScript engine and add enough of it to partially run a c2 html5 export. Even though I ran it though Python and didn't do any optimizations for the renderer (sfml) it was buttery smooth with a very stable framerate at low object counts.

So I revise my statement to say that I think browser's renderer's are to blame.

This isn't a call for a native exporter, but if the renderer could be replaced things might improve. I say that as if it's easy, but it's probably way to hard to do. Especially since browsers can take so long to compile.

It's not possible to make an entire browser, but I do think it's possible to build a basic runtime using a JavaScript engine as a base and some multimedia library with it to handle input, graphics and sound. Of course that leaves out every single other browser feature.

Anyways in the end I lack anything really helpful here.

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?

I wouldn't say it's useless. Quite the opposite.

It's just bad performance on your system.

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

My system is from 2008, and runs your capx fine.

The thing that gets me is my Amazon Fire tablet runs many of my projects even better than the pc.

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!

I didn't say anything about pixel perfect movement.

Honestly I don't care about it, and I would guess most people won't either.

I do care about choppy movement, and both the background, and player move smoothly here.

There's a point where you have to accept what you can do and go from there.

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

TBH the last example you posted looks fine to me. FWIW here's another version which works by having a double movement speed and disabling the behavior on alternate ticks: https://dl.dropboxusercontent.com/u/15217362/30fpsmovement.capx

It seems to work fine even without a minimum framerate. That looks pretty much the same as the previous example to me though.

R0J0hound - you're mainly talking about v-sync, which is a slightly different problem. It's possible to move at precise pixel offsets, but not v-sync accurately, or to v-sync accurately but not move at precise pixel offsets. Construct 2 definitely can do precise pixel offsets (either lock dt or just make your own events to move at integer amounts). All modern browsers can v-sync to within 0.1ms, at least on my system. If you see poor-quality v-sync you should file a bug report at crbug.com or at least comment on the existing v-sync bug (crbug.com/422000) with your system spec. As far as I can tell it's been a solved problem for a while now, but maybe some different system setups work differently.

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

Ashley

Thanks for the link, the vsync test is especially useful. My pc doesn't vsync and gets an average of 30fps. However the solution for me probably has to be to get a new pc, since my graphics card hasn't been supported by amd since 2010, and windows vista is no longer supported by chrome. I won't be upgrading though, unless I have a major hardware failure.

On the plus side, anything I make in C2 will run fantastic on any other machine.

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