Very Slight Stutter

Monkey Forums/Monkey Programming/Very Slight Stutter

QuickSilva(Posted 2011) [#1]
As a new user of Monkey please forgive me if this has been discussed before but is it not possible to remove the ever so slight stutter that occurs every couple of seconds or so causing the graphics to jump?

This seems to happen with all of the examples included with Monkey and I have yet to try something that is as silky smooth as BMax. Is this just not possible? Hopefully I am just missing something obvious, if not then please could someone explain what is causing this?

I have tried with html5 and flash targets so far in both Firefox and Chrome. I expected html5 to be slightly slower but was hoping that flash wouldn`t suffer from this problem.

All in all though I am very happy with Monkey so far.

Jason.


Spacehunter(Posted 2011) [#2]
Sounds like a hiccup on your system.

Have you tried building on a device?


QuickSilva(Posted 2011) [#3]
No I haven`t yet. So this shouldn`t be happening then?

Jason.


AdamRedwoods(Posted 2011) [#4]
HTML5 and Flash will rarely ever be as smooth as BlitzMax. They are both interpreted languages, which runs through a browser, which THEN connects with compiled machine code, whereas BMax is compiled machine code.

Plus, if you have other websites open in your browser, or plugins, or whatever, that will slow your Flash and HTML5 down a bit (unsure about Chrome's threading, though).

Also try lower Update Rates.


QuickSilva(Posted 2011) [#5]
Hi, lowering the frame rate to around 30 seems to help. I did suspect that it was just because things are working in a different way to BMax.

The main reason that I asked was because Zombie Trailer Park seems to run great and that is Flash.

Jason.


taumel(Posted 2011) [#6]
@AdamRedwoods
Maybe you want to update your knowledge about Flash.


MikeHart(Posted 2011) [#7]
@quicksilver? Is the movement of your objects related to the delta time of the OnUpdate event?


QuickSilva(Posted 2011) [#8]
@Mike Hart, yes I am using delta timing but the issue still occurs without it (although it is a bit smoother).

Is delta timing as necessary with Monkey games as with BMax ones? I wasn`t sure whether to even add it.

Anyway, the stuttering effect is most noticeable on scrolling maps and so on, even the platformer example in apps on this site does it so I guess it`s pretty normal and unavoidable.

It does bother me a little though.

Jason.


Uncle(Posted 2011) [#9]
I haven't seen any slow down with flash as yet. Perhaps you could host your flash somewhere to see if other users experience the same? If so then you would know its code related, rather than hardware.


ziggy(Posted 2011) [#10]
Flash AS3 is not interpreted, it's JIT compiled (except constructors if I'm not wrong). Then, most browser's javascript use JavaScript Background Compilation to produce native machine code and are not completely interpreted any more.


MikeHart(Posted 2011) [#11]
Were do you messure your delta timing. During OnUpdate or OnRender? You need to measure this inside OnUpdate.


QuickSilva(Posted 2011) [#12]
@MikeHart - Thanks, it is already in the OnUpdate method so this isn`t the cause.

I`m going to try some other targets and see how they fare.

Jason.


AdamRedwoods(Posted 2011) [#13]

Maybe you want to update your knowledge about Flash.


Why you dogging me, bro?

@QuickSilva
Have you tried other games NOT made by Monkey and noticed any stutters?
Also take note of the screen size they run on.


taumel(Posted 2011) [#14]
@AdamRedwoods
No idea what you're talking about but Flash offers JIT-Compilation since Flash 9 which was introduced five years ago, so updating your knowledge about the current state of Flash makes kind of sense.


muddy_shoes(Posted 2011) [#15]
Even if there's no performance issue with achieving a desired frame-rate the update rate is unstable to a greater or lesser extent across all the targets I've used (I don't have iOS or MacOS devices so I've no idea if they are better). The update code uses timers, so you're at the mercy of the timer implementations on each platform. Repeated dropping of frames could certainly be down to fixable issues with garbage being created in the game loop or other processes but there is probably a limit to what can be achieved if you're looking to match hardware-based frame-rate locks for scrolling.

Talking specifically about Flash, I see a noticeable difference in the stability of the update rate between browsers. I believe that IE is actually the best in terms of the fidelity of the timing.


QuickSilva(Posted 2011) [#16]
@AdamRedwoods, BMax games run perfectly fine as do most others.

I`m thinking maybe it is because I am creating new instances of objects during the running of my game, as mention above. Could this be causing the stutter and should I create all of my objects in the OnCreate method instead and reuse them? For example, have a limit on particles, create them in the OnCreate method and then just reuse these ones in game.

Is there any real benefit to doing things this way?

Jason.


QuickSilva(Posted 2011) [#17]
OK, I`ve now tried the GLFW target and get the same stutter with and without delta timing. I am creating just one small image in the OnCreate method and simply moving it from left to right. No other instances are created when the game is running and no music is playing so nothing is loading\being created mid loop. I am not using any blending\transparency\rotation so I`m really not sure what is causing this?

As I have said before BMax and Blitz3D games run super smoothly. Any other ideas anyone as to what may be causing this?

Jason.


muddy_shoes(Posted 2011) [#18]
It's hard to say but, as I wrote above, the update rate is based on timers and they're unreliable by nature. If you run the code below you'll be able to see how variable the update rate is. You also need to be aware that even if the update rate is smooth, the rendering might not be due to the differences between the way that updates are timed and the actual timing of buffer swaps etc.



Edit: I've updated the code above to draw bars showing the update and render intervals and to allow the update rate to be changed with the up and down arrows. It's useful to see some of the periodic timing issues that come into play with certain update rates on different platforms.


MikeHart(Posted 2011) [#19]
@QuickSilver: Can you post your code with that one sprite please?


QuickSilva(Posted 2011) [#20]
@muddy_shoes I`ll give you program a try and test my results, thanks.

@MikeHart, give me a hour or so and I`ll post my code.

Jason.

Edit, here you go. Images not needed to demonstrate the problem as simple rectangles do the same. Both rectangles seem to shudder every so often with both delta timing and no delta timing. (Delta class from Monkey examples.) Tested with HTML5, Flash GLFW and XNA. All of which stutter on my system.




MikeHart(Posted 2011) [#21]
Jason,

I think it has something to do with the OnRender method not being called on every updated frame. I hardly notice anything and inside a game where a lot of stuff is going on I would say the user won't notice it.

Michael


QuickSilva(Posted 2011) [#22]
Maybe it is my system then as I am seeing quite a huge stutter. Thanks for taking the time to check though.

Jason.


Grey Alien(Posted 2011) [#23]
Haven't tested your code yet but for sure HTML5 and Flash won't look as smooth a BMax with Flip 1 because they aren't VSyncing. Perhaps GLFW isn't either - depends how mark coded it.


QuickSilva(Posted 2011) [#24]
Hi Grey (nice to see you here). Sadly I`m getting the same problem with all targets at the moment, I`m hoping that it is something on my system that is causing the problem. Please let me know how you get on.

Jason.


muddy_shoes(Posted 2011) [#25]
People need to avoid confusion between vsync of the redraw/buffer swap and vsync of the game loop. The targets generally are synced at the drawing level but not synced at the game loop level. This means that it is not possible to guarantee that you will have a direct relationship between the loop timing and the frame updates that the user sees.


muddy_shoes(Posted 2011) [#26]
QuickSilva, I've taken your example and tweaked it a little to try and demonstrate some of the issues around update and frame rates in Monkey. I've no idea if this is going to help, but I regularly read posts that suggest some basic misunderstandings so hopefully this will at least get across the point that there's no simple answer to problems with smooth movement like "use delta timing".

First, here's a link to a build to Flash as per standard Monkey.

What I've added are three lines. These lines show the results of movement calculations based on different strategies:

Green - this is calculated using the overall time elapsed. It is not a delta-time calculation as it doesn't use the change in time between renders. It calculates the position based on the total time since the app started.

Red - this calculates the position based on the number of calls to OnUpdate.

Blue - this calculates the position based on the number of calls to OnRender.

Red and blue lines start positioned at the front of the squares and the green line starts at the back. The movement of your boxes remains based on per update addition on top and update delta calculation on the bottom. I've tweaked the delta calc a little, but not in a way that affects the comparison. Basically, if everything were perfect then the red and blue lines would stay together at the front of the boxes and the green line would stay exactly on the back line of the boxes.

Okay, so what do we see when running the above? Well the fact is that I don't know what you will see exactly because of variations in browser/OS/running processes. What I see is the blue line drifting back in the first second or so as rendered frames are dropped due to start-up performance wobbles causing the update to miss the desired frame-rate.

Once it's all up and running everything remains pretty much synchronised at least for a while. However, even though all the lines seem to move together and the fact that the red and blue lines don't continue to separate shows that no frames are being dropped, the overall update isn't smooth - I'm assuming that this is what you're referring to as "stutter". My assumption from this is that the stutter is a result of the actual display of the frames being uneven.

Is there anything we can do about this? Well, the only thing I've found is to set the wmode to direct, which enables hardware rendering on supported platforms (which includes all major browsers, AFAIK). Here's a link to the same standard Monkey build with the wmode set to direct in the HTML.

Now for me that's significantly smoother. Is it for you? If so, then problem solved, right? No, not quite. Yes, it's smoother, but if your browser is showing what mine shows then if you watch closely you'll see the blue line dropping back, or to be more accurate, the red and green lines are inching forward with five or so extra hops per pass across the screen.

TBC...


muddy_shoes(Posted 2011) [#27]
Okay, so where is the hopping coming from?

To understand this, you need to understand what the mojo update loop tries to do. When you set your update rate to 60, mojo attempts to provide you with a fixed update rate of just that. The first thing to recognise is that it is specifically about updates and not frame draws. If your update misses the timing window to match your requested update rate then mojo will expressly skip the OnRender step, which is visible in the examples by the blue line falling back from the red line.

Now, lets assume that we're having no problem meeting the update timing, which should be the case with our examples on any reasonably fast PC. Why do we get hiccups in the updates? Well, because of variance between the timing of the display and the timing of the update.

On the Flash target, the update loop is driven off the Flash engine's EnterFrame event. For the purposes of argument, lets assume that this provides trustworthy timing to the frame as long as we're meeting the performance contract. So, mojo receives this event and goes into the update loop and everything is spot on? Nope, because mojo is tracking its own concept of the update rate and on every call it checks to see if the game has fallen behind that rate. If the update rate hasn't been met then extra calls to update are made to make up the difference. Or, to look at it another way, mojo makes an OnUpdate call without a matching OnRender.

Why does this happen even though we're easily able to perform the OnUpdate and OnRender within the requested update interval? Well, it turns out that the reality of update timing is a little less than perfect. So, while mojo assumes that 60fps will result in a neat 16.666...ms per frame the reality is that refresh rates are not so exact. If I measure the mean update rate on my PC I get about 16.82ms per frame, or 59.45fps.

What this means is that mojo's concept of frame-rate will drift away from the actual rendering rate. When that drift adds up to a missed "perfect" frame, mojo forces an extra update and actually introduces a glitch.


muddy_shoes(Posted 2011) [#28]
So, where does my waffling lead us? Well, as far as mojo is concerned, smooth scrolling is not going to work with the current implementation. It needs to be understood that there's no absolute criticism in this -- mojo simply makes a certain set of choices about ease of use and abstraction of the realities of updates.

What could be done for mojo is to offer various update strategies so that if you want to lock to the frame, you can -- as long as the platform supports it (I don't know what the HTML canvas situation is). I'd guess that the problem from BRL's perspective is that it would start to make Monkey look less "friendly" by exposing fairly low-level issues. However, I'm sure it would be possible to reduce the issues with the existing strategy by being a little smarter about the update rate calculations or even just more lenient.

On the other hand, we're all free to replace the update loop. I've done it to be more friendly to programs where the update costs can soar (e.g. physics-based games), as shown in the test variant I posted in the box2d thread. Here is the example from this thread running with an update loop that discards mojo's strategy for maintaining the requested rate and locks the update and render together synced with the EnterFrame event. For me it makes the top square, red and blue movement smooth, and shows the jitter in the timing based movement.

Anyway, the bottom line is that this stuff is a bit of a rabbit-hole and not nearly as straight-forward as some seem to think. In particular, there seems to be a tendency to treat delta-timing as some sort of magic wand - it really isn't. Delta-timed movement is very useful to enable your game to handle alterations in frame-rate across platforms or to reduce the effects of frame-rate changes on players in games that require movement predictions but it will actually make matters worse in many circumstances.


QuickSilva(Posted 2011) [#29]
Thanks muddy_shoes for the explanation. It does clear a lot of the questions that I have had up. My machine is not slow so it did baffle me as to why this would be a problem.

In answer to your question, the example with the wmode set was a whole lot smoother so I can understand what you are saying.

Thanks for taking the time to explain,

Jason.


Amon(Posted 2011) [#30]
Maybe not to do with the slow down but what Security Software do you have installed. Some Antivirus software, if not all, now come with systems called defense+ (Comodo), autosandbox (Avast Antivirus), etc. I had similar issues when first using monkey because I hadn't added monkey as a program that was safe.

If all else has failed maybe try looking towards your Internet Security or Antivirus Security software to see if it is the cause of the bottleneck.


QuickSilva(Posted 2011) [#31]
Hi Amon, muddy_shoes hit the nail on the head with his post above. I had already tried disabling virus\security tools and nothing changed with regards to smoothness.

Jason.


spraycanmansam(Posted 2011) [#32]
"we're all free to replace the update loop. I've done it to be more friendly to programs where the update costs can soar (e.g. physics-based games), as shown in the test variant I posted in the box2d thread. Here is the example from this thread running with an update loop that discards mojo's strategy for maintaining the requested rate and locks the update and render together synced"

@muddy_shoes: If it's not too much trouble could you please post a quick code example of doing this? I'm creating a GLFW target game which has a belt of sorts rendered as square objects that loop around the screen; when using delta timing to control the movement or the program loses focus the belt segments get moved all over the place.


muddy_shoes(Posted 2011) [#33]
I'm not sure an example makes a lot of sense as I'm just talking about rewriting the mojo code for each target, which is in the native sub-folder in the mojo module directory. If you aren't familiar with the target language/library then any example would remain fairly mysterious and I don't know exactly what your issues are so I can't provide a specific version for you.

Can I make a different suggestion? Try building the code I posted above with the three movement calculation techniques for GLFW and check out what happens when you do your focus test. I presume you're talking about doing something like dragging the window around by the title bar.

Look at what happens with the various strategies. The top square and the red line remain perfectly synced, the blue line falls back and the green line and bottom square kind of go off sort-of together but not exactly. What you see with the bottom square is the problem with delta-timing, which accumulates errors from frame to frame. If your belt is meant to always follow the same path then delta timing is absolutely not the thing to use. However, you can use any of the other three techniques.

The easiest thing for you to do is to simply drop the delta-timing and do fixed-step movement in your OnUpdate. This is actually what mojo is designed for. The whole point of the update loop is to make it so that you can write code with a fixed-step update and leave mojo to correct for frame-rate wobbles. That will solve your movement issues.

If you're left with the glitches mentioned above from mojo inserting updates then simply putting the movement update in the OnRender could resolve it. Otherwise, if your frame-rate is unsteady and you want the movement to be correct in time, then you want to use a global time based position calculation as per the green line.

Getting your hands into the target specific update code should probably be a last resort.


muddy_shoes(Posted 2011) [#34]
Oops, I just realised that I didn't post the test code. Sorry.

Here:




spraycanmansam(Posted 2011) [#35]
Yeah I thought it would be more target-oriented which would make things messy for me. Ok I'll try it out, thanks for the reply :)


Rixarn(Posted 2011) [#36]
Well... I think this is serious. At least for me and the game I'm developing. I hope Mark will consider using some sort of strategy pattern as muddy_shoes said, to handle multiple Update Strategies. Because a game with slutter (even if it's slight) looks... well... not good for a commercial release...

IMHO, I disagree with this path being less friendly to people. The strategy pattern could allow Mark to do this in a manner transparent to the user, set the appropiate update strategy with a function and leave monkey using the default one. That way no code is broken and we can all be happy.

Something like SetUpdateStrategy(new OurNewUpdateStrategy())

Or even better! Make a Monkey-side interface called IUpdateStrategy or something like that... and let us personalize the update strategy to our needs... is this possible? :)


muddy_shoes(Posted 2011) [#37]
To be honest if I were Mark I'd be cautious about offering users more rope. The word I used above is "could" -- I'm some way from saying "should".

As I mentioned above, if you just shove all your update code into the render call then mojo's update timing issues will go away*. That's probably the easiest solution to try if you're seeing the hiccups described in this thread.

*Within reason. This won't help if your code is too slow to hit the frame, or if the platform render timing is unstable, or if you've sprinkled "delta-timing magic" over your code. Also, I've no idea what will happen on XNA as it looks like XNA does its own fixed-timing update loop and then mojo slaps another update timing adjustment on top just for good measure.


Rixarn(Posted 2011) [#38]
Well... I really don't think it's acceptable for a professional game making tool not to be able to do such a simple thing as rendering a moving object in integer steps (not even floating steps) without having any stutter. If the "Out of the Box" Monkey is not apt for making any kind of game with moving sprites without stuttering... beginner or not the types of games we can make with that can look professional is very narrowed.

Even worst, the current workaround is a hack that goes against the way Monkey is designed! And since it's a hack i don't expect beginners to use it in their games right away. They will struggle, as we have. Yes, it's a very simple thing to put all your update logic in the OnRender() method,but if we are doing this to skip the way monkey works, it means the current design is getting in the way rather than helping...

Now don't get me wrong, I Love Monkey language. As a language it is very well designed, user friendly and lots of things. And as it is now, it's a very neat piece of software. I can only imagine how hard can it be to have a unified tool that works for so different target languages.

I'm currently making a game for the Ipad, and I ran into this issue today because i have spent the past 2 months building my Framework (statemachine manager, resource manager etc... but no rendering code yet)

If the current strategy for managing the update & render is a stuttering machine I don't see why keeping it. Just my two cents. As for me, even thought I really love Monkey A LOT, if i can't make the stutter go away i'll have to drop it for something else :(

@muddy_shoes I'll try your suggestion muddy_shoes, thank you for taking the time to investigate this matter and clarifying the problem... and sorry for the long post

@Mark You Rock, even if Monkey Stutters. Please consider a solution for us :)


muddy_shoes(Posted 2011) [#39]
Yes, it's a very simple thing to put all your update logic in the OnRender() method,but if we are doing this to skip the way monkey works, it means the current design is getting in the way rather than helping...

The mojo idea of having an update mechanism that tries to compensate for variable performance is not unique to monkey. It's intended to help programmers by allowing them to write fixed-rate game logic, trusting that the framework will smooth out the bumps, and it does just that. Where people go wrong is assuming that it's a good solution to all possible game requirements or failing to understand the actual issues involved when they see problems and then pursuing the wrong solution to fix them (use delta-timing on ALL THE THINGS!!!).

The thing is that Monkey and mojo, by their nature, are abstractions intended to hide the variations across targets. Writing rock-solid, v-synced scrollers and the like is a pursuit that tries to break through that abstraction. There's a fundamental mismatch between the two and that's just the way it is.

Working around the update compensation by pairing your update code with the OnRender is really just recognising how the update works. The only reason it looks like a "hack" is because the naming and the conventional usage says "Here's where your update code goes". The reality is that it's just a method that is called based on a certain timing logic. If OnUpdate and OnRender were called FixedRateTick and DoFrameUpdateAndDraw, would it seem such a hack? Those aren't serious naming suggestions, by the way.


sorry for the long post

There's no need to apologise. This stuff requires long posts. There are too many factors for sound-bite advice to be adequate. Less tl;dr attention deficit on forums would be a good thing in my eyes.


Rixarn(Posted 2011) [#40]

The mojo idea of having an update mechanism that tries to compensate for variable performance is not unique to monkey



Yeah, i know that... Fixed Rate Logic, Frame Tweening, Delta Timing... all of them are different ways to smooth a game, it's not something inherent to monkey. What I mean when I say "hack" is...

Monkey is using that Fixed Rate Logic Strategy to help smooth out the bumps. In theory it should work. In practice it doesn't. And In order to implement my own solution to fix the problem (since I can't shut down fixed rate logic in Monkey) I'm forced to do a workaround to "ignore" the fixed rate logic thing (put everything in the OnRender()). The hack is about "ignoring" Fixed Rate Logic. It's a way to hack through the embedded Fixed Rate Logic Monkey Has.


Now...I'm blaming the algorithm, not Monkey. I have tried the same small program I did in the Ipad Sim, Ipad hardware, Web (HTML5 & Flash) GLFW on different computers and all have pretty much the same result: They stutter, some of them more, some of them less...but they all do.

The thing is, I really think it doesn't solve anything... really. I agree that abstractions by nature are intended to hide the variations across targets. But if your abstraction doesn't do what it is meant to do, then it's just in the way. I have no use for a Fixed Rate Logic algorithm that doesn't give me a smooth game, and the fact that I can't turn it off is a liability for me.

Now, what I propose is to Isolate the algorithm using the Strategy Pattern: We define a common interface for our Update&Render algorithms and Isolate the current implementation to an Implementing class of that interface (i.e. DefaultStrategy) and use an instance of that Object to handle the update & render. Monkey just does this under the hood and no harm is done. Nothing is broken. For more advanced users, this allows them to make their own implementations for their needs and set the custom Strategy with a simple method call. For beginners and the rest of the world, they won't even now something has changed. And everyone is happy.


There are too many factors for sound-bite advice to be adequate. Less tl;dr attention deficit on forums would be a good thing in my eyes.



Lol =)


Playniax(Posted 2011) [#41]
I did not have a good look at it yet but I suspect calling your update stuff from the OnRender () method skips the timer mechanism. The game would 'only' slow down if your program 'to heavy' for the device. I can imagine the OnRender () method is synct properly but like I said, I did not have a look yet and is just a theory :) Actually could be a nice experiment.


Rixarn(Posted 2011) [#42]
@Playniax Indeed,calling the update stuff from the OnRender() kind of skips the mechanism.

Okay, I too will do some contribution to this issue. Since muddy_shoes had done a lot of testing using delta timing(DT) I'll try a Custom Fixed Rate Logic (FRL)

Ipad Simulator (XCode 4 with IPad sim 4.3)
MonkeyFRL: Stutters in Horizontal Views. Almost no stutter in Vertical view.
CustomFRL: Stutters in Horizontal Views. Almost no stutter in Vertical view.

No matter what I do It will always stutter in both Horizontal Views. Strangely the vertical Views are more stable, and stutter just a little bit.

Ipad Hardware (1st Gen IPad)
MonkeyFRL: Almost no stuttering
CustomFRL: No stuttering

Misjudged Monkey, because out of the Box Monkey's FRL runs well this example code without my FRL algorithm. Perhaps I'll need a performance sensitive test?

Flash

MonkeyFRL: Ocassional Stuttering at the beginning of the run, but keeps stable during the run with almost no stuttering.

CustomFRL: Slightly better than Monkey.

HTML5

MonkeyFRL: Stutters every n seconds.
CustomFRL: Stutters every n seconds.

GLFW
MonkeyFRL: Stutters every n seconds.
CustomFRL: Stutters every n seconds.

ANDROID
Not Tested

And here is the code:



Conclusion?

A Custom FRL routine makes no significant difference. Somehow even when we Put our stuff in the OnRender Method Stuttering keeps leaking... Perhaps I'll do some tiletests to see how smooth the scrolling looks. But I don't expect much... Before I ran these test I wrote the routine in BlitzMax. There, the FRL strategy helps smooth things a Lot. But here it's like its worthless.

Anyway... Since the Ipad Hardware can run w/o Stuttering I'll have to live with this w/o worrying too much... for now..


slenkar(Posted 2011) [#43]
I tested the HTML5 and flash versions,
it stuttered twice in the first 10-20 seconds but didnt stutter anymore.


Rixarn(Posted 2011) [#44]
@slenkar Did you noticed any significant difference between raw monkey's FRL and the CustomFRL I did?


Playniax(Posted 2011) [#45]
Nice for testing this!

Anyway, in my experience it also makes a difference if your app runs in windowed or full screen mode. Running your app on a windows machine almost guaranties a stutter once in a while, that’s just how it is. I think this has nothing to do with Monkey. Have not that much experience with a Mac but I am working on a Monkey game right now and tested it on the iPhone but it runs silky smooth. And I’m calling the updates from the OnRender method. But I have to do more tests and dive into the mojo code to know more about this.


muddy_shoes(Posted 2011) [#46]
I suspect there are several levels of terminology failure here. The problem that QuickSilva was talking about with Flash as "stutter" was the introduction of updates that are out of sync with the rendering rate. This is separate from issues with interruptions to the monkey app processing(e.g. clicking/moving the GLFW app titlebar) or issues with targets that have a fundamentally unstable refresh as HTML5 seems to have.

The posts I made above don't just look at delta-timing, they show the differences between frame delta-timing, overall time based movement, locking movement to the render and also using the conventional update mechanism. Each of these will produce different results on different target due to variations in the timing and rendering mechanisms. The update algorithm isn't going to behave the same on a platform based entirely on timers with a best precision of 1ms as it is on a platform where the timers are of nanosecond accuracy or one that actually triggers the update sequentially from the underlying display update.

The bottom line is this: if you want to lock to the frame, you are best advised to perform your game update in the OnRender. This doesn't mean that you'll get a smooth frame-rate if the target doesn't offer it, nor does it mean that you wouldn't get a smooth frame rate if you use the OnUpdate call any given target. What it does mean is that you avoid the possibility of having the update timer incorrectly "correct" your frame-rate and stutter.

Edit: I think I'll skip posting further in here about this as I'm not sure the forum format is helping matters. Perhaps it's something better put in a blog. Anyway, I notice that the wmode="direct" tag was quietly added to the base Flash build, so at least something has come out of it.


Rixarn(Posted 2011) [#47]

Edit: I think I'll skip posting further in here about this as I'm not sure the forum format is helping matters. Perhaps it's something better put in a blog. Anyway, I notice that the wmode="direct" tag was quietly added to the base Flash build, so at least something has come out of it.



Perhaps a blog with a summary it's a good idea, but at least for me, it did helped what you posted here ;)


The bottom line is this: if you want to lock to the frame, you are best advised to perform your game update in the OnRender.



Agreed, and at least for my current project I can live with that.