Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

AppGameKit Chat / Better stutterfree movement?

Author
Message
c0d3r9
1
Years of Service
User Offline
Joined: 2nd Oct 2017
Location:
Posted: 13th Jul 2018 00:36 Edited at: 13th Jul 2018 00:40
Unfortunately I still have a problem with the player movement from time to time.
I do this.


And I know that the stuttering that happens to me now and then depends on the internal calculation "issues".
Since I seem to be one of the few I wanted to ask in the round if you can show me your ways to make this maybe better.
I know that vsync(1) helps a bit but i read here and there that the most doesn´t use it and have no problems with that.
I have done some work on my platformer but that problem makes me headache.

I know that the internal physic calc are extremely accurate but for a platformer i don´t use it.
fubarpk
AGK Developer
Gold Codemaster
13
Years of Service
Recently Online
Joined: 11th Jan 2005
Location: Adelaide
Posted: 13th Jul 2018 01:08
I imagine your using getframetime() to stop the stuttering. But the reason its stuttering is that some process in the background
has to update its calculations. I dont think a calculation with frametime and movement is of any benefit even tho some calculations
happen in the background with the engine while others happen immediately. It would be better examining your code to see whats
causing a delay perhaps there is some calculation that could be improved. Either by post calulating and then using the values that
the post processing created. The location of parts of your code can also make a difference. for example if you do movement then
you call sync it will move to the new spot straight away. Sync isnt the only way of syncronising there is Update(), Render(), Swap()
these are all processes called by Sync(). If your having problems with stuttering and your machine is working well you could make
use of manually updating there is also Update2D and Update3D() commands that can be used to replace the update command.

fubar
c0d3r9
1
Years of Service
User Offline
Joined: 2nd Oct 2017
Location:
Posted: 13th Jul 2018 02:41 Edited at: 13th Jul 2018 03:03
nope, i use GetFrameTime() for framebased movement.
I cut down a short code and there are nothing else that is calculated.
I used SetSyncRate in the code but i know vsync(1) helps most of time.(but not always)
Are there other ways to handle smooth stutterfree movement?
How make the pros it?

I know i could split the sync command but i don´t what is the best way to use update2d(), render() swap in this case.(or similar one)
I.e. Update2D(time) for what is time?
It updates all in time i.e. 1 second and so it waits 1 second till is done or what did it mean?
Back to the main question: in wich way the people here handle the movement?

btw. if i move with physic or 3d objects there is no stuttering...thats confusing me.

fubarpk
AGK Developer
Gold Codemaster
13
Years of Service
Recently Online
Joined: 11th Jan 2005
Location: Adelaide
Posted: 13th Jul 2018 03:18
Quote: "I.e. Update2D(time) for what is time?"


Update2D(0) To update all 2D now

The above code you have given works perfectly fine for me absolutely no stuttering very smooth
and i have allot of processes in the background chewing resources
fubar
IronManhood
3
Years of Service
User Offline
Joined: 6th Feb 2015
Location: US
Posted: 13th Jul 2018 05:17 Edited at: 13th Jul 2018 05:17
I've noticed the stuttering as well and it only happens when I use SetSpritePosition commands everyframe.
basicFanatic
1
Years of Service
User Offline
Joined: 7th Jun 2017
Location:
Posted: 13th Jul 2018 12:41
Got stuttering too. ScreenFPS() was behind the optimal framerate. But I just found the culprit: My particle mist took up way too many resources. (512 pixels was a bit too large particle size)
c0d3r9
1
Years of Service
User Offline
Joined: 2nd Oct 2017
Location:
Posted: 13th Jul 2018 13:42
should i set the new spriteposition only every second frame?
i don´t know what i can do now.

i tried a similar code with cerberusx and monkey2 and this doesn´t happen.
It seems anything internal.

In background here it runs not much.
Only bitdefender but on my desktop pc it runs nothing like that and i have the same problem.
Or did i nee a high end gfx card to have correct 60.0 fps?
But that couldn´t be the solution.

I hope anythere/anything can help but at the end i don´t can accept such stuttering.
IronManhood
3
Years of Service
User Offline
Joined: 6th Feb 2015
Location: US
Posted: 13th Jul 2018 15:24 Edited at: 13th Jul 2018 15:26
Well, updating the position every second frame would only result in the sprite looking as if it is updating at half the frame rate. So even more stuttering. I don't know what is causing it but increasing the frame rate seems to help. I wonder if it has something to do with the refresh rate of the monitor you are using?
GarBenjamin
1
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 13th Jul 2018 15:53 Edited at: 13th Jul 2018 15:58
I think the only way we achieve perfect stutter free movement is by locking to the refresh rate of the monitor.

So basically set vsync on and also use framerate independent timing code (because some monitors will run at 59 fps such as mine and others will run at 120 fps and others anywhere in between).

If we only use vscync then game runs faster or slower than intended for some people but movement should be smooth no stutter.

If we use only AppGameKit command to set a specific framerate game should run at desired speed on all devices but movement will not be smooth and will have stutter on the machines where desired frame updates are not aligned with monitor refresh.

If use only framerate independent coding game will run at desired speed on all machines but again will stutter when not matching the monitor refresh.

So what I am moving toward now is use vsync and framerate independent timing code. We need both imo.

Even then it will never be stutter free perfectly. It is impossible. If you were developing on a C64 that had ONLY your game running then sure it could be perfect. For last decades games are just one of dozens of things running at the same time. Always services running doing this and that in background. Sometimes they will take processing enough to overlap monitor display update by time OS gives your game time... your game runs... frame is skipped etc.
TI/994a (BASIC) -> C64 (BASIC/PASCAL/ASM/Others) -> Amiga (AMOS/BLITZ/ASM/C/Gamesmith) -> DOS (C/C++/Allegro) -> Windows (C++/C#/Monkey X/GL Basic/Unity/Others)
c0d3r9
1
Years of Service
User Offline
Joined: 2nd Oct 2017
Location:
Posted: 13th Jul 2018 16:06
I have 59.x hz too.
Okay atm i would use vsync and timebased movement.but its not perfect.
I wonder why this happens not if i control the sprite per physics and with 3d movement there is no stuttering too.

I wish paul or any other from the dev-front can say why thats happens and with 3d and 2d-physics not.
Maybe i can figure out a combination of physic-nonphysic controller.
basicFanatic
1
Years of Service
User Offline
Joined: 7th Jun 2017
Location:
Posted: 13th Jul 2018 16:10
GarBenjamin wrote: "vsync and framerate independent timing code"


Sounds good ... can you give me some example code?
GarBenjamin
1
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 13th Jul 2018 18:03 Edited at: 13th Jul 2018 18:09
I can when off work tonight. I wonder if best way of all would be to do things similar to how they used to be done many years ago. I think I will experiment more. Already spent a good amount of time experimenting with this over last projects but be good to have a definitive solution done with.

Basically calculate speed of machine and monitor refresh and using that set a speed and scale factor.

Like target say 120 fps. Determine this machine can handle that but monitor updates at 70 fps. Vsync locks to 70 fps and scale is set to 1.7[1429] (120 / 70) and these remain like this instead of changing every frame based on last frame time. Might occasionally get slowdown but it could be better more stable overall. Maybe 150 fps be a better base target. Not sure need to experiment.

Would be a non-issue if monitors all updated at same. But they don't. My work computer is at 60 fps. My main dev personal laptop is 59. My second laptop is 72. I know I have seen others advertised running at 80 and even 120. Huge range. Might be some high end and future ones running at 150+.
TI/994a (BASIC) -> C64 (BASIC/PASCAL/ASM/Others) -> Amiga (AMOS/BLITZ/ASM/C/Gamesmith) -> DOS (C/C++/Allegro) -> Windows (C++/C#/Monkey X/GL Basic/Unity/Others)
smallg
Valued Member
12
Years of Service
User Offline
Joined: 8th Dec 2005
Location: steam
Posted: 13th Jul 2018 18:16
what do you mean by "stuttering"? if your frame rate isn't constant then naturally there will be "stuttering" where the block is sometimes moving faster and sometimes slower... that's how you coded the movement to work, or am i misunderstanding and you're seeing something else?
life's one big game
spec= 4ghz, 16gb ram, AMD R9 2700 gpu
c0d3r9
1
Years of Service
User Offline
Joined: 2nd Oct 2017
Location:
Posted: 13th Jul 2018 18:55
@GarBenjamin: sounds fantastic.I can wait...i tried so much different things but nothing really work.
GarBenjamin
1
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 13th Jul 2018 19:51 Edited at: 13th Jul 2018 19:52
I did a very quick search on lunch and found they already have 144 and 240 refresh rate monitors. Lol Maybe the base is around 60, 72 and 80 and higher ones are multiples of these rates. Which may or may not be useful to know but seems like it would be useful if true.
TI/994a (BASIC) -> C64 (BASIC/PASCAL/ASM/Others) -> Amiga (AMOS/BLITZ/ASM/C/Gamesmith) -> DOS (C/C++/Allegro) -> Windows (C++/C#/Monkey X/GL Basic/Unity/Others)
GarBenjamin
1
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 14th Jul 2018 05:03 Edited at: 14th Jul 2018 16:06
I knocked this out to test the two different methods. Variable frame time scale (meaning it is calculated per frame in this case just using GetFrameTime) and Constant frame time scale which is pre-calculated.

And honestly, I can see no difference in stability. Both methods are completely stable smooth movement on my laptop.

Granted, it is late and I am ready for sleep so I may have made a mistake somewhere but it *seems* correct at this point.

I think the whole key is being sure to enable both vsync and the frame rate independent time scale multiplier. Unfortunately, I am pretty sure users can override the vsync setting in their graphics properties. lol But the way I see that is if they do well just the way it is. They did it. Can't waste forever on something like this. Just make a solid effort.

TI/994a (BASIC) -> C64 (BASIC/PASCAL/ASM/Others) -> Amiga (AMOS/BLITZ/ASM/C/Gamesmith) -> DOS (C/C++/Allegro) -> Windows (C++/C#/Monkey X/GL Basic/Unity/Others)
c0d3r9
1
Years of Service
User Offline
Joined: 2nd Oct 2017
Location:
Posted: 14th Jul 2018 15:54
Thank you.With VSync(1) its complete stutterfree.
I take a deeper look tonight.
c0d3r9
1
Years of Service
User Offline
Joined: 2nd Oct 2017
Location:
Posted: 14th Jul 2018 22:49
If i´m right then State 1 is exact the same like me. Movestep * GetFrameTime()
Only in State2 you calc the frametime in a kind of idle mode.
Precalc is in my opinion not the best way.

It seems that we have to live with these microstutter here and there sometimes depend on what happend on the loop.
VSync(1) seems to be a must have.

Last days i read so much about this problem.
Read about its fixed on a newer opengl version, about multibuffering....some workarounds....
But what me makes wondering is that there are so much games of the world without that problems.
(don´t know exactly if that problem exist on directx but i believe not - only read about microstutter with opengl)
GarBenjamin
1
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 15th Jul 2018 05:09 Edited at: 15th Jul 2018 05:10
Yeah that is exactly it. Test 1 just uses GetFrameTime and Test 2 calculates the frametime (well the length of a frame in millisecs) during program start. I agree just GetFrameTime is better.

Well I'd guess most games are using vsync. But when playing a game most people won't notice an occasional "pop" etc in movement of a sprite because there is generally so much going on. Animations, particles and other FX, time limits, evading danger etc. I am sure other games do stutter at times just people wouldn't pay any attention to it unless it was major and / frequent enough to distract from gameplay.
TI/994a (BASIC) -> C64 (BASIC/PASCAL/ASM/Others) -> Amiga (AMOS/BLITZ/ASM/C/Gamesmith) -> DOS (C/C++/Allegro) -> Windows (C++/C#/Monkey X/GL Basic/Unity/Others)
c0d3r9
1
Years of Service
User Offline
Joined: 2nd Oct 2017
Location:
Posted: 15th Jul 2018 09:26 Edited at: 15th Jul 2018 11:30
Yes that could be the reason....i´m most a perfectionist.Thats the problem
Try it with more action....

in sfml it was fixing with something: Replaced time-based joystick poll with a hardware event handler (even if no joystick connected)

edit: another way https://gafferongames.com/post/fix_your_timestep/ i try to port

Login to post a reply

Server time is: 2018-10-23 18:28:57
Your offset time is: 2018-10-23 18:28:57