Here a new test release for people using GDevelop on big project or smaller project too.
There is big changes in the game engine codebase to come, that could cause visual differences in your games.
So that we can reduce the differences if you have any, you can test the next update.
-Why this test release ?
-The engine upgrade the API for render the objects, from Pixi 4.8.6 to 5.2.1.
If you notice a visual change on the objects between a previous version and this test version.
Whether it is on the stage, or on the preview, please give us your feedback as detailed as possible.
I’ve done a small test to see if effects works again with the preview on Windows 8 Pro 64Bit but unfortunately still not working so loaded in Canvas instead of WebGL.
I really like the new panel interface.
Actually no issues but i’ll post again if something happen.
Btw, is this new release supposed to bring any improvements or fix?
Just wondering what is the reason behind the upgrade to a new version of Pixi, is it just a “why not” or is there any specific reason?
Well we prefer to work on up to date software that’s it. GDevelop needs to keep up with the new technologies to stay relevant. Newer software is created on pixi 5 and not on 4 anymore, if we want to support the latest techs we need to upgrade such base components. The updates were not for nothing, there are probably lots of performance improvements and new features.
I see. Well, I did not noticed any significant improvement in rendering performance (I did do some tests recently) and we still get this problem even with Pixi 5 (in case anyone was hoping it may fix it):
The main difference with v4, that the v5 use a new system for render the elements.
It’s called “batch renderer”. This should improve the performance.
And it’s also a good thing for the shaders, the system behind is simplier.
You can check the migration guide on the pixi’s github and the post on their blog about v5 for learn more
Due to a design error, the game I’m developing was creating (and simultaneously killing) multiple instances of a particle emitter in each iteration of the events (even in many nested loops). This caused the game to freeze for one second every 30 to 40 seconds. I later fixed this bug by redesigning my events and changing some effects to a single instance of the particle emitter, but …
I tried the bugged version of my project (the one with the multiple particle emitters… I kept track of old versions of my projects, just in case) on the beta version of GDevelop with Pixi v5 and, surprisingly, it works very well, there is no lag of any kind.
I’m on a Windows 10, Core i5 2.6GHz, 16Gb RAM laptop.
Alright so here is my test results with this one (I tested Miko Adventures: Puffball):-
1- In general there is no difference about how the images look or rendered.
2- Program crashed 1 time when opening the preview.
3- I see no difference in performance … might be just slightly better (like less than 5%) … but I’m not really sure about that as it just feels the same.
After testing … I don’t know how I feel about Pixi 5.0 really but it might be better in other stuff and elements in GD but might not be for performance or handling big stuff (I can’t see really see that) which is kinda disappointing to be honest, or maybe this release is just not ready enough which makes sense.
I Hope that day come where I can see GD actually able to handle big and heavy stuff…
I have a feeling that “other staff” is fancy visual effects and shaders but when it comes to rendering sprites and text it is not so fast. In my tests GDevelop performed 2 times slower compared to some other engines and frameworks and 10 times slower compared to the framework I am developing for my own use, mind you it is pretty basic at this point but fast In my tests I was moving sprites around, change their position, opacity, rotation, color, scale, was doing mostly rendering staff only no complicated gameplay, visual effects or collision and physics was used and no audio was played.
Of course in my tests GD was far from being the worse and rendering 5,000+ sprites is more than enough for most cases, so it is not too bad but also not great I was actually surprised to see that how much faster some other engines and frameworks were in my tests.
It could be interesting to debug this and see where this relatively low performance coming from in GD, is it just how “slow” Pixi is or is it something in the rendering and update cycle of GD or maybe the compiler split out dirty un-optimised code or maybe it is all combined.