Blockquote It could be interesting to debug this and see where this relatively low performance coming from in GD
I’d like to see that happen with the future updates because I can really feel that the engine can give more you know … but something is just stopping it from doing that.
I’ve been testing GD since beta 30 or even before that and yeah the engine have come a long way in features and so on … but not really in the performance aspect, it is the one thing that makes any game … a game …
Hope to see in the future (hopefully near future) more focus on performance … it will send this engine to another place.
Yes this is why I’m thinking it might be faster rendering visual effects and shaders.
In my tests, I was focusing on quantity and CorianderGames was trying to render high res images in his game with no success so if there is any performance improvement it must be focused on effects and shaders and not sprites indeed
But this is actually sounds something like that should also help with sprites:
After doing some testing it looks like it could do with the boundaries of the layer for the outline effect.
Here is an image of all objects in the layer in a clump, there’s a visible boundary where the effect is not being applied.
When using 2 dummy objects to make the layer area larger, the effect is displayed correctly (except on the dummy objects). I have tested both v4 and v5, and v4 does not require this work-around.
Remember, the focus on this Pixi release is for now not really to improve performance - though it would be a nice side effect, because as explained by Arthuro555 there are a bunch of performance improvements that can make rendering with Pixi.js very fast.
Performance is a complex topic, it can be:
rendering performance
collision handling… and how much collision check you’re doing
how much objects you’re moving (needing to update their collision masks)
how much object are animated
how much conditions/variables check/etc you’re running on objects that are actually offscreen.
What could be useful is if you make a simple example that seems to under-perform - at this point we could look at if there is something that is clearly sub optiomal in the game engine. The game engine is itself not super complex.
Here we’re just testing that upgrading Pixi does not break your games
What I think would be useful, and it’s a point where GDevelop could be better, is to give you tools to understand why things are slow. The profiler is very basic. I’m thinking of adding better instrumentation of the games to warn when too much work is done (events using too much objects, collisions taking too much time, physics, too much rendering of objects, too much effects). Whatever the performance of the game engine is, you will always easily make it break if you’re not aware you’ve done something that is too resource intensive (I wonder how many games are creating tons of objects and never deleting them, or making stuff happen outside of the screen while it could be avoided)
Ah, I think you just mentioned the reason behind the low performance in my rendering tests. Yes, it was a rendering test, just to see how many objects I can put on the screen and move around, no collision was checked.
But even if I don’t check collision, the engine still continuously update the collision mask as the object move and rotate right?
If I don’t want to check collision with something, it is sounds like a total waste of resources to update collision mask position and rotoation especially if it a custom shape.
Would that be possible to stop updating? Would it be possible to add an option in the sprite object properties if we want to update collision mask or not, also an event to be able to toggle on and off.
When an object is moved (example for sprites), it should just toggle a boolean indicating that the “hitboxes” of the object are now “dirty” and do nothing else. Then, it’s only when a collision check is being made or when the hitboxes are used (for example, to know if an object is visible on screen) that the boolean is checked and that hitboxes are recalculated.
So this specific optimization should already be there - but:
such optimization can backfire if for example if you’re moving too much objects and recalculate too much hitboxes (at which point the boolean is not useful, and has a slight overhead) (though flipping a boolean is really really the cheapest thing you can do).
such optimization may be not enough if you have too much moving objects - in which case it would be useful to know from GDevelop if you’re making “too much” collision tests (but how much is too much?).
I see what you mean, but if you don’t check collision ever, it may be uses too much resources I mean, as I mentioned GD was 2-3 times slower in my tests than some other engines out there but now that I think about it, in the other engines I did not even have a collision mask so that must be part of the reason and I think worth investigating imo. Now, one might say that if all you do is move objects around the screen then you can use particles instead but the thing is, with using sprite objects you can still have animations, object variables and able to take control any individual object at any given time, with particles it is not so easy because as far as I know currently we don’t have control over individual particles but the particle emitter.
It is depends on the device and the shape of the collision mask (the number of polygons) I guess. I grabbed my cheap tablet and was able to check collision with 900 objects on screen while mainlining 30FPS. So if someone put a gun to my head and ask the question, I would say 100 considering the cheapest possible device people may own which is my tablet as of today and also that probably want to do other things in the game not just checking collision. So when there is more than 100 collision checks happen, you can put a warning in the console saying the number of collision checks may hit performance on slow devices.
But then people may don’t care or don’t even see the warning. I mean people don’t see the examples included, constantly every day asking how to do something that is already demonstrated in examples included, so do you really expect them to see a warning in the dev console? Maybe if GD would have a console built in to the IDE that can be hidden and display a giant red “!” sign if there was a warning during preview maybe.
Lol. Realized I can actually remove the hitbox by having a custom hitbox with 0 polygons.
It is improved the performance by 10 FPS and allowed me to put 1000 more objects on the screen while maintaining 30 FPS on my dev PC. But it is till way below the results of some other engines, wondering how much the calculation to update the hitbox cost even if I have an empty array of polygons.
The BB Text issue should be resolved. In theory very few things should be changed - don’t expect mad performance gain or any gain at all. The idea is just to test the stability.
In particular let me know if an effect is not working anymore.
BBtext issues still persist with pixi v5. Top is custom font, bottom is default font. Seems custom fonts react badly for some reason. I tested 3 different ttf fonts from different sources, all behaved the same.
Another thing to note, is that the BBtext font seems to change when left as it’s default setting of Arial when compared what is displayed in the scene editor and in the preview.
Sorry for the confusion, when I said “BB Text issue” solved I was thinking of the one crashing the editor.
Before we go any further, is this issue of line height related to Pixi v5 or is it also appearing in GDevelop beta 97 (i.e: using Pixi v4)? I believe what you are reporting here is already an issue in the current version of GDevelop, reported here: BBText line height · Issue #1521 · 4ian/GDevelop · GitHub
I know it’s frustrating but I want to make sure we’re here only dealing with Pixi v5 regressions here, otherwise this will delay the adoption of Pixi v5 which is largely overdue already In a way I want to verify that Pixi v5 is not “making things worse”.
To be clear I think I should take another look at this issue because it’s clearly a bad bug making BB Text almost unusable Will try to see if I can do something.
Any chance GD5 will get the implementation of BitmapText and automatic bitmapfont generation they added?
I think that would make a great object/feature! Should be more performant and could help with some pixel perfect rendering issues.
I’ve added a card here:
GDevelop 5.0 beta 97 with Pixi 5:
