Construct can't handle many animations at once?

  • Tinimations

    Yes, unfortunately for me it was rather unplayable. It is really surprising, as this machine can handle quite a lot ;-) (5.9 Windows mark, i7 Quad, Geforce Quadro 600)

    Gerg

  • Strange... Have you had similar problems with other webkit games you've played? It bugs me so much that the game only performs poorly on computers I can't watch it run on personally.

  • I am on a 5 year old dualcore 3.17Ghz, GTX280, 4GB RAM, WinXPSP3 and Klang12_8 runs quite smooth even while player melee strikes!

    Is this the r140 or the r141 compilation? Can we please have both for comparison?

    I'm intending to make an animation heavy game at least this size with node-webkit, so I'm very interested what happened and the speed must remain at r140 level.

  • This build is running off r 139. If you want to check out the build where the problem is present, please check out the capx. File shared in my topic in the bugs section.

  • hey man, nice game you have!

    i'm played it and is running smooth, but the sections i have fps drop was the ones with A LOT of effects + colision checks

    i'm on a AMD quad-core 3,80 GHz 8GB RAM with a NVIDIA Geforce 8400GS

    i think your problem may be the JUST effects + animated backgrounds

    your game is not just heavy animated; it is VERY heavy animated with heavy effects + alot of background heavy animations

    i'm pretty much impressed that construct2 could handle the numeber of effects in your game without break the rapid gameplay feelling, but i think you should review your design on the fight rooms because there is too much stuff happening at the same time, maybe changing the background effects a little when there is colision checks or even removing some stuff; like, when you have a big fight you could make it on a new layout room with less effects happening on the background or change the way your dinamic effects to something simple like frame by frame or using spriter

    maybe just ashley can say what is really the problem but i hope you can keep the scope of your project because is looking very cool :D

  • Tinimations: Nice work on the game! This quality level must have been a lot of excruciating work!

    hey man, nice game you have!

    [..]

    your game is not just heavy animated; it is VERY heavy animated with heavy effects + alot of background heavy animations

    [..]

    I am very happy that Tinimations uses so much animation. Go Tinimations! This problem should be solved, otherwise I can't use:

    • animated bushes,
    • animated trees with moving leaves **
    • swirling fog
    • rain
    • dust devils
    • animated enemy & player "battle-ready" stances
    • battle animations **
    • AND spell effects **
    • or medieval bombs exploding on the Battlescape.
    • !!!plasma effects!!! = is there a solution for these in C2 since the excellent plasma effects in C1?

    Most of these animations I plan on-screen at the same time.

    Tinimations I wouldn't reduce number of animated objects, rather please pursue that this problem shall be fixed.

    For the only reason:

    If we cannot push C2 to the limits its not really worth developing in it, since we cannot innovate to such a large extent as most of us are planning to innovate.

    Checking out the CAPX now!

    ** I already did these in my game prototype - Fantasy IV: Army of Darkness coded in C. It looked awesome 13 years ago so I hope C2 is up for the task.

  • Very interesting looking game there.

    Some observations from running it from an IT guy but not a developer of anything - yet;

    1. It could do with a performance monitor/hud output showing FPS and renderer used.

    2. It doesn't appear to use WebGL as there's no GPU usage showing on my monitor and even my little test games register on this.

    3. It spawns 2 instances of the .exe plus a Chrome.exe over 45-50 individual threads, together these use around 950Mb of memory just into the second area.

    4. The "defend all angles" bit is so hard I couldn't get any further to test how much this would grow by!

    5. I couldn't find a way to exit the game.

    6. On an i5-3450, performance was fine in game, the title screens looked slower maybe 15fps but hard to say without a monitor, this wasn't cpu or gpu bound though using 10-15% CPU (but no GPU).

    You may know all of the above already, but I test/troubleshoot system performance in my work and look for bottlenecks so maybe it's just something I'm used to doing.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Thanks for the kind feedback everyone. I really appreciate it! :)

    As for the difficulty, I might haven't communicated it well enough in the tutorial, but this is actually a rythm-game. If you try to follow the very predictable beat in the songs, it should become a lot easier.

    Zantium: Issue number 3 is something I'm also worried about. Do you have any proposals of working around this? Isn't this simply how construct 2 works, and that I simply need to optimize my sprites better?

  • This is a very nice concept. I like the general design and animations very much. Seems to me there's not *that* many animations or effects that C2 should croak over em. But I often got jerkiness when a projectile moved within range and the character didn't always respond to input during those times. You say things sped up when you turned off animations.. do you use a lot of collision polygons for your frames? If so, maybe try to use simple boxes instead?

    EDIT:

    Actually, scratch all that. I tried to lower the desktop resolution to 800x600 and the game ran so much smoother it's not even funny. So I got a lot further than before and yeah, you have a *lot* going on in some areas. The jerkiness for collisions went away but I got it in other places. When new gfx got shifted into video mem perhaps? I dunno. Hard to tell.

  • Zantium: Issue number 3 is something I'm also worried about. Do you have any proposals of working around this? Isn't this simply how construct 2 works, and that I simply need to optimize my sprites better?

    Tinimations - I've had a look through your CAPX and it looks to be the backgrounds that are going to cause you memory problems.

    FirstBackground is 1900x1900 for instance, the Chaser/s (not backgrounds) are quite big but there are a lot of Clouds at 1024x1952.

    I too wanted to draw nice big backgrounds, I mean it's not doing anything how hard can it be to process right? Ashley pointed me towards his blog post on the subject, very much worth a read: scirra.com/blog/112/remember-not-to-waste-your-memory

    When I was playing with C2 I had the idea of moving dynamic (morphing) clouds in the background in a platform game. To that end I "made" a dynamic cloud generator using the particle system. I'm sure something similar could save you a lot of memory as it can be tweaked using the same 2 particle generators to produce different effects.

    youtu.be/7SCnpf9zh_Q

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