construct speed test (1 sprite, multiple instances)

This forum is currently in read-only mode.
From the Asset Store
Casino? money? who knows? but the target is the same!
  • I realize that this isn't the most practical test in the world, but I was curious how well construct performs and it also relates to a project I'm working on with fake vector objects built from very few sprites. I thought some might be interested in the results

    basically there is a sprite 512x512

    it creates a new instance of the sprite in a random spot every tick

    it also moves every existing instance and rotate it randomly every tick

    there is text to keep track of the number of instances, and the remaining vram

    I used fraps to keep track of frame rate

    here are the results:

    up to 1000 instances of the sprite(60 frames per second)

    at 1000 instances the frame rate drops immediately to 30 frames per second

    at 2000 it begins to drop slowly and by 2300 its around 20

    after 2500 instances it goes to 15 and drops steadily

    on a blank project of construct I have 252.2 vram remaining

    on this project I have an unwavering 251.8 vram remaining

    as many of you knew, the increasing number of instances has absolutely no effect on vram

    if anyone wants to try this on their system, please post your results and system specs

    I'm curious to see if the 1000 and 2000 marks are a steady point of decline on all systems <-this will track your framerate accurately(for any directx software)

    this is the cap

    my system specs

    athlon x2 4.2

    4 gigs of ram

    vista 64

    geforce 8800 gts 256mb ram

    also, as a side note, I tried the same project with tintplus applied to every sprite, regardless of whether you just have it on, or whether you're changing the tint every tick the frame rate drops rapidly from the beginning and is below 20 before I got to 650 instances

  • you could also set the application to 'unlimited framerate' to measure the performance impact with higher granularity.

  • Getting 20 from about 700 and it doesn't go lower after that.

  • In speed tests I usually measure how many objects I can get before I hit V-sync rate (for me, 75 fps). I can get about 1000 here. You should be careful when using events in speed tests, because rendering simple sprites is trivial for the GPU, so you might end up CPU capping your test with the for each loop.

    I'm on an 8800GT with the in-development version of 0.99, which has a faster renderer. I get no sudden drops, it steadily falls from 75fps at 1000 to about 35fps at 2000 which is what you'd expect.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • I'm not convinced you'd ever want to move more than a couple of 512x512 sprites around every frame, so maybe this isn't an accurate test?

    Speed testing isn't a generic thing where you can deem one engine faster than another, because they're often optimized to deal with situations that occur in games, not in random tests.

  • Rich is right, if your game uses mostly smaller sprites, the GPU cache will perform much better. Your test should as closely resemble a real world situation as possible.

  • Please fill in my ignorance and correct me if I'm wrong.

    So the FPS/speed depends on the graphics that are displayed/moved/animated/rendered-with-effects on the screen which is managed by the GPU? Does Eventing/cpu-related-stuff contribute a much to the speed?

  • It should all be explained in the Optimisation Tips article.

  • It depends if your CPU is capped, as to whether it is affecting performance. You can see in the debugger if it is, under 'CPU waiting'.

  • When i hit 1.2k i go slowly down from 60 fps to 30 and then when i hit 2k i get around 25 fps and at 3000 i get 20fps and now im at 4000 with 15fps

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