Colludium's Forum Posts

  • Chrome Canary

    19.7 - 23.8 ms, no time spike every 5 sec apparent this time.

    When I run my embryonic game I see no improvement in the slight jerky performance and occasional hesitations compared to v39 Chrome (even though I no longer create or destroy any sprites during run time...).

  • sqiddster

    I tried to revert but v39 is now the latest release. It's worth adding that I'm running the x64 version of chrome. Here are my complete chrome beta / stable results:

    Chrome v39 (Version 39.0.2171.27 m (64-bit))

    19.1 - 25.2 ms; however, there are spikes to a max of 39.7 ms every 5 seconds (lasting 2 seconds)!!

    Chrome Beta (Version 39.0.2171.27 beta-m (64-bit))

    19.3 - 25.7 ms; the same spikes to a max time of 43.1 ms every 5-6 seconds (lasting 1-2 seconds).

    Edit to add - judging by the version numbers, it seems that I should expect very little difference between these tests (QED).

    Mmmmmm!!

  • On my laptop, Intel HD4600,

    Chrome v39 (beta), 22.1 to 25.5 ms

    Firefox v33, 16.4 - 31.3 ms

    IE 11 v 11, 20.8 - 26.2 ms

  • TiAm

    No, I was just being unclear... The recycle method works much better than creating and destroying. However, when I tested my improved demo on my old computer I found that the performance was still poor when recycling (and better than when creating).

  • eli0s, so I tried the 'improved' version 2.1 on my old sony (512 mb graphics card) and the performance was appalling (visual artefacts on the draw of the background, and also the periodic stutter you mentioned) = totally unusable!

    So, I can only conclude that the 'fix' I mentioned before might only improve things for users of high-end hardware. I fear that it's going to be difficult/impossible to sell games of any dynamic complexity to people with average machines (my target market, I suspect) until the browser technology improves.

  • I must confess that I only tested it in chrome, — It was running butter smooth but my system is high spec. Let me try my old laptop and I'll report back. Excitement reduced a tad...

  • Thank you all for your advice and thoughts.

    So, after TiAm started a thread about the performance gains of making an object dormant instead of destroying it, I adjusted my earlier demo so that it no longer creates any sprites during run time. And, for my eyes at least, after destroying a few objects as j0schi suggested (thank you x 1000 for that great advice!!), the 'game' now runs very smoothly right from the start....

    While tinkering around with the settings, I found that the performance improved only if the objects that are to be destroyed are created inside the layout (I initially set them to be created at -200, -200 and that had no effect on the first 10 seconds of garbage collection; it was smooth thereafter, however).

    So, create and then destroy some stuff inside the layout and then don't create/destroy sprites during run time.... What about particles? I don't think they cause any stuttering. I'll try and put together another example to see if there are any limits / gains worthy of note.

  • Wow, thanks GeometriX for the example test, there's a huge difference in performance (4k v 15k)! Now I'm going to make some adjustments to the jitter examples that eli0s and I created for the jitter thread - and see what happens there with respect to garbage collection....

    Edit - I've posted an example of the jerkiness thread - definitely advice worthy of note!!

  • No probs.

    Magicam

  • It's a 3rd party plugin and isn't supported here. You need to contact whoever wrote it to get support.

    Edit to add: you can use the Scroll To behaviour and get the screen to shake that way. There is also a good camera plugin that will allow you to shake the screen...

  • eli0s, LOL!

    I too feel a tad helpless and at the mercy of 3rd parties to improve their browsers' GC. I'm going to have to shut off sections of my events and see if there's anything I can do to improve things; I suspect, however, that only time will provide the solution for browser games.... Oddly enough, Node performance is flawless - so why should that be if it's based on Chrome??

  • Nice work!

  • skelooth, I think part of the problem is one of my expectations compared to yours - I understand that you don't see this staccato game play as a problem, but my expectations are that all game movement from C2's engine should be as smooth as every other html5 game I have seen... Especially the first 20 seconds, when a new player is likely to decide whether or not to quit a game.

    I am also just embarking on my first 'proper' and hopefully 'for sale' project - and I made the GTA reference, as — so eloquently put, because I am not sure I will receive favourable reviews if this cannot be fixed. If more demanding games like GTA play smoothly on the same hardware then my simple platformer will always appear to be at fault. I am already being very careful to avoid the unnecessary creation/destruction of objects mitigate this. However, and especially during the first few seconds of a layout, this problem doesn't seem to be manageable just by being careful with events. I want to avoid having a 15 sec 'loading' splash or showing a message like "some users may occasionally see stuttering game play (just ignore it)".

    A couple of Ludum Dares ago I created a platformer and received a couple of comments that the game play was jerky, even though the effect was far less apparent than the demo I linked to earlier in this thread - so it's not just my imagination that this is a problem. I'm expecting to put a lot of hours into my game, but if C2 isn't up to the job then you might be right - maybe I'm trying to use the wrong tool for the job (or maybe I should limit myself to 640x480 or similar with no scale up to full screen). I have tinkered with Unity a little bit over the last couple of years and Unity's 2D optimisations are really quite brilliant; but C2 is far easier to use and I intend to stick with it for long term because I hope that this issue can and will be fixed.

    I have no idea how Ashley has implemented garbage collection in C2 (assuming that is the culprit) and I have no idea how difficult a job it might be to fix. But there is definitely room for improvement and I live in hope, and if you don't ask you never get.

  • Yes, small window res and letterbox integer scale can certainly reduce the jitter, but my laptop will quite happily play GTA at resolutions that make a C2 platform game appear like it is being rendered on 1980s technology.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I agree that it it doesn't look like the end of the world, but it does detract from an otherwise glossy performance. A quick visit to various html5 gaming sites and I cannot find any examples of other games that exhibit this sort of stuttering problem...

    What I found interesting in trying to set up that little example is that the jitter didn't seem to get any worse even if I went mad and created dozens of extra sprites - so there was little difference when I had 500 dynamic objects bouncing around or 50.

    What I find frustrating is that when there's a ludicrous amount going on, the player is less likely to notice any jitter because they will be focussed on other movements, but when there are just a handful of sprites on screen, any jitter to the scrolling background (ie the player's movement when scrolled to) really stands out.