Colludium's Recent Forum Activity

  • I am from the UK but currently working in the US. I have to say that I really enjoy participating in the C2 community - it somehow 'completes' the editor experience...

  • Telyko, ha! Yes, I was not clear at all. It certainly appears that the driver could be optimised to run external, and perhaps more modern, hardware. Have you tried turning webgl off in the editor and seeing if that makes a difference to the laptop performance? On my older laptop I found even just having webgl on made a huge difference, even with no shader effects.

    That would still not explain why the driver is not running each screen the same. Perhaps it self-allocates more memory to running another monitor and that just happens to be what node requires. If you can manually set how much memory the driver uses then, perhaps, increasing that might also help.

  • Telyko, that sounds a bit weird - I don't know why the monitor size should make any difference, but perhaps the required driver for the external monitor is is newer and better? Also, just out of interest, on the back of the jerky performance threads, was there a resolution change that went with running on the new monitor?

  • 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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • 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

Colludium's avatar

Colludium

Member since 26 Aug, 2013

Twitter
Colludium has 11 followers

Connect with Colludium

Trophy Case

  • 11-Year Club
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • Forum Hero Made 1,000 posts in the forums
  • x3
    Coach One of your tutorials has over 1,000 readers
  • Educator One of your tutorials has over 10,000 readers
  • RTFM Read the fabulous manual
  • Email Verified

Progress

18/44
How to earn trophies