construct speed test (1 sprite, multiple instances)

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

http://www.fraps.com/setup.exe <-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.

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