Jitter adventure step 2

About Monkey 2 Forums Monkey 2 Development Jitter adventure step 2

This topic contains 8 replies, has 3 voices, and was last updated by  DruggedBunny 1 year, 2 months ago.

Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
  • #13993


    Getting closer to hunt down what we begin to call “the jitterbug” in the M2 sourcecode. We’re 7 people now doing it the hard way comparing Monkey1 and Monkey 2 source code line by line.

    This short example is a good way to show how it behaves for both window and MacOS (also for both windowed and fullscreen mode). This is how it expresses itself all the time even when things appears smooth, it’s just blown up here.

    It induces a good kind of strain, but you need a powerful computer such as a MacBook Air 2015 or 2017 for this particular code. If you got a weaker or more powerful computer you can just increase or decrease the tilesize variable until you get an almost “stable” 60 fps, and then you go backwards to cut the strain in half. This will be a great sweetspot to see what happens.

    I show this action in the video.

    Overall graphic performance
    We noticed that the overall power is about half of Monkey1 but that’s not a problem as there’s plenty enough power to go around still on everything except maybe the weakest computer.

    But the jitter is there all the time on all systems and machines so far we’ve seen. Even when things seem to be smooth in Windows and MacOS it’s there it’s just tiny, miniscule. It seem to be a timing problem that has to do with events.

    If you got one of those convertible tablet/notebooks and you detach the keyboard while a Monkey2 app is running then you can see also that it pauses exactly 4-5 times each and every time you detach it in sequence with it takes about 4-5 seconds to complete.

    Monkey1 would not give a damn when you do this, It’s perfectly robust, not a glitch.
    Monkey2 somehow reacts on a huge amount of events that the OS sends, even “invisible” ones that’s constantly there, this mess up timing of also e.g. graphics in a miniscule (but still important) way. Other things are also affect of course.

    Note that this is not using only standard commands anymore but also OpengGL/SDL2, the problem is still there.



    EDIT it might be hard to see the video in fullscreen using the thumbnail so here’s the actual url
    h t t p s : / / streamable.com/4hj29



    I’m getting a compile error..



    It was meant for the last Monkey2 version that works without updating Macos to HighSierra.
    The update that made the error is the transient from naming opengles into a general OpenGL module.
    Here it is rewritten for the new one, same result. Don’t forget to set width and height to your native screen before you run it for best effect.



    The effects are not exactly the same in all installations though, in some you get the event interrupts when you move the mouse in the app window and some gives the results shown in the video but they are both related.



    If running a nice M2 app with a steady 60 fps, then a trained eye could easily compare this to something like the M1 equivalent (I can provide an code if wanted but any code works as long as it’s written in Mojo2) and then compare it with this “smooth” M2 app and you would see and feel the difference of micro stability.

    I was personally fooled a long time, so when I noticed glitches I thought it was something wrong with the device like a bad update or driver. Fresh installs on 14 different systems and Windows / Macos machines (haven’t tried Linux or Pi yet because those are lower priority still for us).

    Android can never give this experience so it doesn’t matter much if your developing for Android but iOS and Macos and Windows CAN give this ultrastable & smooth experience (but with M1 only so far).

    It makes a huge difference on the user overall experience.



    There’s a strange resemblance in Monkey2 & Monkey1-used-together-with-only-Mojo1, but it seems to be nothing but a coincidence, they have nothing to do with each other. There seem to be no inherited code which is a shame I guess because that would have made things so much simpler to fix.



    I have to run it at 500*500 to get 60FPS!

    I can see jitter only when the mouse leaves/enter the window (on windows10). I think it’s a sdl2 thing. monkey1/mojo2 is using glfw so it’s managing the events another way.
    I must say I cannot help much, it’s too close from metal for me. Is it mojo managing sdl2 events in a way it can be optimised or is sdl2? You could try to do something in native code using pure c++/OpenGL/sdl2 to see if it’s not sdl2 before diving in mx2/mojo code.



    Ya, the source of lag is that we can’t use the threadsafe SDL_PeepEvents, switching to SDL_PollEvent seem to be the only way to be lagfree.
    Actually the way to use SDL_PollEvent is important too.

    So it seem we need to change while(SDL_PollEvent(&event)) into (SDL_PollEvent(&event))
    or to change SDL_PollEvent() into SDL_WaitEvent() SDL2 generates key repeat events automatically so repeated key events needs to be filtered out manually by checking the repeat member of a SDL_KeyboardEvent.



    Probably best to raise an ‘issue’ on Github to make sure Mark sees it:


Viewing 9 posts - 1 through 9 (of 9 total)

You must be logged in to reply to this topic.