R198 Feedback

0 favourites
From the Asset Store
A set of 34 small WAV files. Each plays a small sound effect that could be used as an action or event feedback noise.
  • Post your feedbacks about the new 198 release.

    I found that my mobile game is way smoother even on crappy devices!

  • I'm unearthing a lot of older projects to re-export.. I feel I'm seeing improvement, I have yet to take real measurements..

  • just made a new build and it runs great jitter has been reduced

  • Hmm, I ran a few tests, but haven't made up my mind yet...I guess I'm just a little wary of the placebo effect. Would be interesting to know more specifics about what has changed and what type of loads would best demo the improvements.

  • I'll do a new export too as soon as I'll have time for mobile.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • Found the changed code in preview.js. I don't claim to 100% understand it, but it includes some logic specific to low-latency frame scheduling on mobile devices, which should, theoretically, help reduce dropped/mis-scheduled frames.

    If you are interested you can see the changes by comparing an earlier version of preview.js with the current one. I'd recommend notepad++ along with the excellent 'compare' plugin:

    http://www.davidtan.org/how-to-compare- ... epad-plus/

  • Before releasing my game, I'm trying to optimize it as much as possible

    After test with R198 my game is like 4-6 FPS faster even on old mobile devices, that's the final push I needed!

    Awesome!

  • Frame rate does feel a little bit smoother. But, the control movements on the player feels more stiff now. Had to adjust the control values a bit to make it "feel" right again. Pretty weird I must say.

  • Haven't noticed any difference on desktop.

  • i tested my pool template , i was having problems with it and sounds replayed to many times and the collision was detected every tick when overlapping the balls or the walls of table, also before when i was shooting at maximum power i had a problem with the balls passing through each other, now they don't do that anymore, also the sound acts like it should triggers 1 time, as i set it to.. its working good here.. since im using a lot of interactions asm.js physics at least, on browsers(IE, Firefox,chrome,) and also on nodewebkit.

    you can see old template that i was working on http://www.kongregate.com/games/JohnnyC ... v1-sandbox here and u see the problems with old physics they do some weird thing and also sound is acting funny, on collisions or ball sitting near margin of pool table, now its all working good, il upload a new version soon . sorry for my missing words from phrases and my gibberish, dident slept again for 48 hrs so im guessing this is how my brain says i need to sleep ... so later guys.

    P.S also the interaction and the direction balls bounce now are more accurate, without me having to modify the interpolation stepping

  • Looking at cpuutilization, I can see around a 10-20% CPU usage drop during intense fleet action. That's a very good boost for efficiency!

  • Input feels more responsive, actually.

    Not much to say on performance...all I have are painstakingly optimized retro games ^^; Didn't notice a single jerk or anything though.

  • I feel that the fps becomes more stable. Previously the fps might float between 6x to 5x (or 4x) in desktop.

  • A little more info on this change:

    For v-synced rendering the runtime calls a function to request the next frame (requestAnimationFrame). Previously the runtime would run its entire tick logic, and request the next frame right at the end of that. Now in r198 the very first thing it does each tick is request the next frame, then go ahead and process that tick's logic.

    This should in theory give the browser more time to accurately schedule frames. Consider an intense game where the logic takes 15ms. If the runtime requests the next frame at the end of the tick, the browser has just 1ms to schedule the frame in time. Now that the runtime requests the next frame at the beginning of the tick, it has the full 16ms frame to schedule the next frame in time. This could improve the predictability/stability of the framerate.

    TBH I don't know much about the internals of browser frame scheduling, and it's difficult to know for sure if this helps, so it was kind of an experimental change. It seems to be a good idea though and feedback seems to be either no change or positive, so I think we'll keep it!

  • Ashley Thank you so much for your effort in producing such new releases!

    Construct2 is already powerful, and every release adds a pinch of awesomeness.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)