I have question, if that is ok.

I read 'fps style'. fp.. stands for first person ....

Meaning the camera should (since its 2D) be on the players position and look in the direction that the player is looking ?

Well, I mentioned fps as first person shooter because that is an example use that I think everybody would get right a way... and yes, I may have been using construct 2 in a pseudo 3d capacity (think old 3d games)

But the last statement you made could be another use. I think alot of games prefer not to be spinning because it is nausea inducing in the top down look in the direction as the player... human eyes don't track rotation like that and so its not as useful... but could still have its uses.

99Instances2Go

whats the n^2 rule?

...and I'm confused... what would x +=x%2 do to change the stair stepping... I didn't try it but I don't understand why doing this would change it?

The mouse plugin has no expression for tracking x and y axis! You know, you can of course save teh last position of the mouse and get the difference but that only works until you hit the edge of the screen .

What would you you need it for... well... my game for one thing as I am using it to spin the camera fps style

Couldn't you just create a family and put all the objects you want in them, then give it instance variables to record their x/y positions and compare them each frame and do any corrections if necessary?

So you'd shift them at the end of the events, and then restore their positions at the beginning of the events.

Idk.. just an idea i had.

But yeah, I only make low-res pixel games, so this sort of thing would be important to solve, as well as any other jitter related issues.

Thats 1 solution in a nut shell, but can be performance costly doing that via events depending on the type of game you are making.

Well, what feature would help with this and how would it work? Things like uneven scroll updates are due to maths, not the technology.

TLDR from previous post:

You could have an option that when enabled the following would occur:

compare the difference between the actual position of the object and its new position. (dx,dy)

if (dx > dy) then only update the render position on the y axis if x is also updating

else vica verca.

does that make sense? You would have to track the rounded render positions and were they are force to.

Well, what feature would help with this and how would it work? Things like uneven scroll updates are due to maths, not the technology.

That's just it though, I've been thinking on and off for a year or so on this topic and really haven't found a good solution. Many objects have to be synchronized (camera, player, etc...) so that makes it a hard part to make part of the engine right? I mean how is construct supposed to know what you have moving and whats not and which moving objects matter. The only thing I could figure is that some sort of behavior could be applied that looks at the objects last position that it rendered to, and its new render position. If the difference between oldx and newx is greater than oldy/newy, then it only updates y render position when x render position updates and vica versa. This can eliminate stair stepping mostly... I have a project from a year ago that does this... I just stopped doing it though because via events it starts to take a toll setting and resetting object positions twice a frame, storing the old render position and the "real" position... and so on- especially when you have many dynamic objects. As it stands I don't think there is a way to even tell the c2 renderer to render this sprite at an offset (you could do that via an effect I suppose... but again performance can tank if you have many actors) which would be helpful (actually it would be cool to be able to change the objects render setting in game - you know, draw it this big, at this offset, at this color, using this blend mode (x,y,sx,sy,rgb,mode).

On a side, I was running a nes emulator on my laptop when I was talking about nes games... They have something going on like what I described above to ensure you get that nice pixel line instead of thicker stairstepping lines (like the middle image I provided)

---- My current practical solutions via c2

In general, these days I turn pixel rounding off and then make sure I have my camera position make sure it is only updated if the actor it is following would have had a visual rounding. the stair stepping is usually only obvious when using lower resolutions. Or the character is moving at a steady angle.

This is a stupid way to do it but I also sometimes make pixel art, scale it up in Photoshop using nearest neighbor (to like 4x or 6x), then I run the game with linear and no pixel rounding at a decent resolution. Its not as crips as pure pixels but You get amazingly smooth everything including scaling the screen, and zooming in and out. It takes longer to make all the assets, and it does less well performance wise, and if you use tilemaps you have to fix that... but you get the gist.

------

Of course, it bears noting as you said, this isn't a c2 specific problem but, as you noted, a problem with trying to emulate crappy hardware of the 80s on a modern platform. Unity has the exact same problem... only it can get worse because you have to deal with fixedUpdate and regular Update syncopation and how the game interpolates position if you are rendering faster than updating fixedUpdate,

Sorry for the Long read, I'm trying to be brief.... lol

—

https://dl.dropboxusercontent.com/u/11449416/TestsJitterDemonstration.capx

The red pixels are bad... they jitter, they use defualt pixel rounding... the green pixel is cool... he knows he shouldn't be jittering around so he doesn't... stupid red pixels

— - I round my camera to what ever it is following, but If I change objects, I make sure I change them back before altering there positions. This is where I wish the engine had an option for it because updating all dynamic objects at the end of all your events before a render and then undoing those changes is a huge performance drain. If you don't undo the change then you are literally moving those objects which can cause problems.

If you have a "real"velocity expressed as a float and then calculate a "facade" velocity that works nicely with everyone that is calculated every tick based on dt... The biggest thing Iv'e noticed is that you need to have the larger component of velocity (x/y) be evenly divisible by the other. I don't think moving 1,1,2,1,2,1,1,2,1,2... and so on is as bad as visually rounding just x this tick and then just y the next tick... (x,y,x/y,x,y,x,x/y)... as this gives a literal stair step movement look instead of a diagonal look... anyway...

I'm a bit surprised that Ashley doesn't understand this. He certainty is smart enough, maybe he isn't thinking about it from an asthetic standpoint and only programming?. He understands that it does what it does, and why it does it, but doesn't see the problem with that solution... after all, that IS what you are asking for with pixel rounding. I understand where he is coming from, I think . But if he would compare, as you mentioned, the arcades, and early consoles to C2, he would notice that x/y never NEVER stair step. You can run an emulator at 0.1 speed and see Mario update x/y without the smaller component ever being syncopated. You can achieve this on a modern system with variable frame rate... you just have to emulate it mathematically. The place for that is inside the engine and not the event editor.

Know what I'm talking about?

i.e... Jitters... You know, when an object rounding to the nearest pixel clicks to a new x coordinate one tick and then a new y coordinate the next and back and forth. Rarely does the object update both x and y simultaneously at lower velocities. The result is a sort of jittering stair step movement. Once the object is moving fast enough (say 200 pixels per second, depends on resolution as well) the effect is much harder to notice. But it is super obvious when a platformer reaches the apex of a jump or a top down guy is running diagonally... and so on...

I spent some time with the nes and noticed this doesn't exist. If an object needs x updated more often than y then y only updates with x. Basically it won't alternate between the two... even if it makes mathematical sense. Now, I know the nes had a fixed frame rate.... but it did have sub pixel positions (though I only think 4). But either way if my object was at 0.5,1 and I started making it move at 1 sub pixel per component per frame, it would still update (visually) only one component per 4 frames and be alternating between the two and giving that jagged jitter movement look. But thats not what happens on the nes... Something goes on to ensure that x/y are updated together or that only one gets rounded while the other has to wait for the next update time.

Does anyone have any idea how this could be achieved with a variable frame rate... Iv'e messed around with a few ideas but I am curious if a.) anyone else has a system they use to mitigate this... and b.) why it should probably be a feature in project settings as it would be way better for the engine to deal with this.

------------------

Because some people can't visualize: Check this out. Red pixels "Jitter" sometimes because they stair step. The green pixel doesn't.... cause he is cool, so cool.

https://dl.dropboxusercontent.com/u/11449416/TestsJitterDemonstration.capx

Pixel paths and rounding: what this means for you!

R0J0hound - sorry for so many posts. Here is an image that shows the movement path of an object with input being angle 0 full acceleration, switched to angle down (90) at full acceleration.... you can see how the rat of angle change is fast but then slows down.

My current thought, is that I can calculate the angle of input and then apply a constant deceleration towards 0 in the angle perpendicular to input angle like so:

The deceleration vector would be a constant amount declared ahead of time but never pushing the result angle past the input angle in either direction. It would be calculated anytime the current angle mismatches the input angle. This is sort of neat because it would allow the character to resolve angle without affecting velocity though I think I would anly apply it if the character is traveling at or above max speed.

I just remembered a game http://store.steampowered.com/app/233150/?snr=1_7_7_230_150_1 and in it they did deal with this problem though different goals means they probably found a different solution... , but I remembered each plane still had a max speed, a current angle/speed, and an input angle/acceleration. The direction the plane was pointing seemed to affect deceleration, but only when attempting to travel beyond max speed.

-------------------EDIT----------------------------

As it turns out this works quite smoothly:

The character was traveling from the left to the right leaving a red trail. The cool part is that this can be modified in a number of ways depending on when it is used and what you provide as a deceleration parameter.

R0J0hound , alas, the above method doesn't work... at least not without me learning more about angles or something. For example, if input is opposite to current velocity, you really don't want to be changing angle at all (not until speed is 0 and then angle is changes instantly to -180) I suppose I could try basing the degree to which one accelerates towards another angle could be scaled full if the two angles are perpendicular but be 0 if they are parallel.

I think one might have to split the angle into several pieces and only adjust one of those pieces and then put it back together... problem with angles is I really know nothing about them (how to manipulate them with each other)... I don't know if quaterneons or whatever they are called could offer help...

R0J0hound - I'd share the results of whats going on now, but I use several custom plugins and behaviors that you'd need to run the capx and I think you get what I am saying?

Iv'e tried describing what I want several times and each description I don't think gets the point across. Regardless of what I have done, the angle seems to lerp towards the new input angle to varying degrees. Its like I need to be able to come up with a way to doctor the angle as well. If I just handle the magnitudes and handle angle as a consequence (like you did in your example)... I dont know... Like I said maybe I want something that can't exist. I want it to be exactly like the 1 dimensional problem, but in 2D. In all practicality, I don't suppose to many people would notice... though I think it really depends on the style of input (sticky vs inertia based)... I've been playing around with a lot of top down games to see how they were all implemented, and it seems nobody has made what I am describing (usually because direction is sticky even if velocity isn't). Characters often time can reverse direction instantly.

I suppose one could, as I said above, doctor the angle, but I want to avoid carrying the "overTheMAxSpeed" towards that new angle... WAIT, I think I may have had an epiphany: Why not treat velocity up to max speed different from the the remainder that goes above max speed!

Get angle and distance of vx, vy.

If distance > max speed get the x,y components that is the difference between max speed and current speed (I'll call this velocity spill over, or spill.x/y for shot)

Now, calculate vx +ax, vy +ay If the result < max speed... ad spill over and you are done.

Else, get check the input angle(ax,ay), and using a desired lerping method (ease in, ease out, linear, etc) change the angle to what you want it to be that tick. then add spill over back to the velocity.

In this way, I can treat velocity changes that are a result of input separate from the rest of the spill over. and then add them together. I don't risk changeing the angle of speed > max but I can deliberately doctor the angle below that value. I can also decelerate spill over using different deceleration values (that way I don't have to constantly decelerate velocity by half of what acceleration is, and so on and affect both sides) Does this make sense at all? I'm going to go try and test it. I'll let you know how it goes.