SOLVED [Noob] Creating a simple fps benchmark.

Old2DGuy

Member
Hello, I'm (finally) wrapping up a project that has kept me from diving into GM, but I'm hoping to make a final decision on pursuing GM very soon. Performance on mobile devices is crucial for my development, so I was wondering if anyone would take the time to write this small benchmark test that I could run and compare performance to my existing framework? It's crazy how performance on mobile devices varies compares to PC. Even an old PC out performs most of the latest phones, so these types of benchmarks are at the least, very interesting when run on multiple devices.

Requirements: The main requirement is an Android APK I can test on a few devices, but an additional version for PC would be great too.
Background image size: 1294x728 (HD ratio) On wide screen devices, it's fine to have black bars on the side. The background can be anything, but it can't be just a black screen.
Sprite size: 104x104 The sprite should have transparent areas. Maybe a simple round marble, ball, etc.
Background and sprite should be high color jpg, png, transparent png (or whatever GM uses).

I've attached the test images I've been using if you would like to use those.

Program Operation:
Every loop, the background gets drawn, then the sprites on top. I'm aware there are some tricks that could be used to avoid drawing the background every frame, but I wanted to draw the background every frame to understand fill rate and how it affects rendering performance. Especially when the screen fills with 100s or 1000s of sprites.

The app starts out with zero sprites on screen. With every touch of the screen, 10 sprites get added to the screen. The sprites start out in the middle of the screen and they simply move around the screen and bounce off the edges like a pong ball. They never die, they just keep bouncing around the screen. Each sprite should have a random velocity when it's launched so all the sprites are moving around at different speeds.

The app should display frame rate and current number of sprites moving around.

Options: Would be cool if there was a check box(s) to select random scale size, random rotation. Not needed but would be a nice addition.

Would be great if standard GM sprite functions were used, just something that represents typical GM performance. But if you do end up using something that enhances the performance, please let us know so we can better understand how it improved performance. It also would be cool if the source to the project was posted in this thread so I and others, could view and learn from it.

ok..now for the obvious... I KNOW I'm going to get flamed with "do it yourself a$$hole, we don't have time....". I've been down this road before in the past but there's usually one or more experts floating around who can bump this kind of stuff out in a few minutes. So I hope you don't mind the request. Plus it might end up being something useful others could use to test performance on multiple devices, etc. For anyone that takes the time to do this, I thank you in advance for your time.

I was part of something similar years ago..lol.. it was great to see the various frameworks bumping out the results.
 

Attachments

Old2DGuy

Member
welp.....I just downloaded the free trial and will be tackling this myself. I'm also going to be adding my thoughts in this post as I learn the basics of GM2. I'm doing the space rocks tutorial first (obviously) lol. The naming convention used for properties seems a bit off imop, image_angle, sprite_width, should just be sprite_angle, sprite_width, etc, etc. We'll see if there's a reason for this as I progress. lol..
 

Old2DGuy

Member
hmm... so far it's all step based logic/rendering. No delta time being mentioned. Cool thing is I have a space ship firing a 60 bullets a second. :) I'm starting to see how I can put my request demo together fairly easily. hmm.....
 

Old2DGuy

Member
Almost done with the benchmark test. Would appreciate if someone could answer these 2 questions. Thank you.
1) I'm displaying 1000s of objects and the frame rate is obviously not at 60fps, but the debugger is showing speeds of 200-1000 fps. lol.. How can I get the actual frame rate of the program? I have "use synchronization to avoid tearing" checked in the graphics options. My monitor's refresh is at 60hz, so I should be getting frame rates of 60,30,20, etc.

2) I have a background object and in the step event I check for a keypress and create an instance of a sprite to move around the screen. This created sprite does not render on top of the background, it renders below it. yah...I was stuck on that for a while before I gave up. lol.. How do I correct this? Thanks!
 

Old2DGuy

Member
How are you creating your sprite? From a game handling object? If so then in the create tab just add a line that says depth = -1
Perfect! Thank you, much appreciated. :) I have to add, GM2 is looking nice. I noticed I can add an object to a room and have it not seen, and have it act as the main loop (controller, states, etc) for the entire game (or room, level, etc). Sweet...
 

Old2DGuy

Member
well.. bummer... I can't get the default text to display the fps. I have this in my background object's post-draw event:
draw_set_font(-1);
draw_set_colour(c_white);
draw_text(32, 32, "FPS = " + string(fps));

Any ideas? Thx.
 
Is that background object visible? Because if you've set it to be invisible, it literally skips all drawing events. Also, if the reason you are drawing in post-draw is because you want the text on top of everything, just draw it in the Draw GUI event instead.
 

Old2DGuy

Member
Awesome! :) Draw_Gui event worked and makes sense. lol.. Thank you! Do you know a way to count the total number of instances in an object? I'm trying this but it's throwing a global error. Thx again.

draw_text(32, 32, "Total Sprites=" + string(obj_sprite.instance_count) + " FPS = " + string(fps));
 
Well, for one thing, it's very important to come to terms with the difference between objects and instances. Objects are the blueprints for instances, instances are the "things" in your game. If you have more than one instance of an object in your game, you should not use dot notation in reference to it's object index (i.e. obj_sprite.something). Instead, you get the instance ID for the specific instance you are targeting and use dot notation with that. Read the link I shared above for various ways of getting instance ID's instead of using object ID's.

However, that's not totally related to your problem. How many instances there are of something is not a property stored in any instance/object in your game. It's simply a function call:
Code:
var _total_number = instance_number(obj_sprite);
draw_text(32,32,"Total Sprites = "+string(_total_number)+"FPS = "+string(fps));
Above, we're storing the returned value from the instance_number function in a local variable called _total_number and then drawing that.
 

Old2DGuy

Member
Success! :) Thank you for taking the time to help me, I greatly appreciate it.

I have a few final questions, thank you in advance for anyone who takes the time to answer them.

1) Is this method of sprite rendering pretty much the standard way of rendering sprites in GM2?
2) I see there is a particle system that comes with GM2. If I rolled my own particle system using the built in sprites, would that be just as fast or does the built in particle system have an optimized render pipeline?
3) Same as #2 but with tile maps.
 
1) As far as I can tell from what you've written previously, you are simply creating 1000's of instances right? And those instances are drawing themselves? If you are wanting 1000's of things drawn, it's probably more efficient to have one instance of something and then draw all the sprites inside that instances draw event, instead of individual instances for each sprite. This is because all instances come with a bunch of built-in baggage that relates to various properties for that instance. In general using an array/list to track the properties of each sprite that you want drawn and then looping through that list and drawing the sprites according to those properties is going to be faster than having many many instances.

2) I think you are imagining sprites and objects as very separate things, when they are linked in a very deep sense. You cannot draw a sprite without having an instance of an object in the room (you can add sprites to the room layers, I believe, but those are basically non-dynamic and can be thought of as a simple background image). The instance is what handles the drawing and this instance will come with baggage that is not contained within the sprite itself, so it's basically impossible to remove ALL the baggage that comes from drawing sprites. This, in general, means that using the in-built particle system is always going to be much faster than rolling your own particle system (the structures you'll have to use to keep track of the particles are not as optimised as the in-built structures keeping track of the standard particles). However, the caveats are that there are no collisions with the in-built particle system and some dynamic effects are very hard/impossible to replicate with the in-built particle system. For instance, having many particles in a ring move towards the center of the ring and then disappear requires a lot of adjustments and refinement using the in-built particle system and any later adjustments to positioning (as an example, making the ring bigger) will then require redoing all of those previous adjustments. This means that if you just want some pretty particle effects, use the in-built particle system as it is guaranteed to be faster. On the other hand, if you want collisions or are aiming for a very specific set of particle actions, you'll have to look into creating your own particle system.

3) In-built tile maps are faster than custom made ones and they have fewer of the caveats that the above in-built particle systems have.
 
Top