Looking good.
Hi intoxicat3. Quick post to let you know I’m playing Guncat right now and also that I did use code 7HL7MJR3NMX4. Again, thanks a lot.
As far I can see you are moving only one object (the player) which is updating collisions, rest of the collisions are static and won’t be updated during game. Updating something with collisions make CPU overhead.
We are doing update where we will disable UE collisions and make our own. btw Week from the release we have almost 1 mln downloads.
Nice info, I was suspecting that but thanks for confirming it. This will actually affect the design of my next project.
And congrats on the downloads! If the player retention is also nice, that would mean that the besides being fun, the game is not running into performance or stability issues. Which is a great news for anyone working on UE4 mobile titles.
One more question, it has just came to my mind… did you check if the objects with collisions off (turned off with the BP node) also add up to the CPU overhead? In other words are the active collisions a problem or the fact that a mesh is having a collider at all?
Nope if you have disabled collisions Collisions Updates won’t tick. Basically in 4.7 there is some optimisations with collisions so it’s better but for your example and ours it’s better to implement simple 2d collisions from scratch instead of using PhysX.
Another thing that we are seeing is Blueprints performance. Guncat i 95% blueprint based and they are taking a lot of CPU. We are moving functionalities to C++ and we’ll see how the performance will change.
Thanks for the response. I will be keeping an eye on this thread so please do not forget to post about the BP vs C++ performance test results.
Basically we found out that everything that requires some math is about 7x slower in blueprints than in C++. For devices like iPad2, iPad3 and mid-end androids it’s big difference but for Air/iphone5s it isn’t big deal.
Adding math to C++ is really simple, always extend from custom C++ class and when ready with prototyping move math to C++. The one problem is that you will need github version of the engine because you can’t package iOS with custom code in 4.7.
Thanks for the info. I will need to consider this option for the game I am working on right now. Always good to know where you can find some extra performance on low-end devices.
Well we did 2d game using it and a mobile game so it isn’t exactly true. For PC 2D games UE4 is good, on mobile there is couple of things that Epic need to do (mentioned in this thread)
I will try PC 2D games with Unreal 4.
Hey, i was looking also for a way to optimize the package size on mobile devices and i was lucky enough to find this thread https://forums.unrealengine.com/showthread.php?67166-How-do-I-set-the-name-of-the-application-in-Android and it reduce the total size of my game by 70 - 80 MB. Maybe it can help you and others looking for the same
We are working on a 3D runner on 4.5.1 and we managed to get 30fps on the iPad 2 by using unlit materials and vertex colors everywhere. These low-end devices have severely limited pixel processing performance, but they seem to do fine with large amount of (batched) geometry.
All our collision logic is done using custom C++, so there’s no performance issues there. The player control and movement is entirely done using blueprints, but it has little effect on performance since there’s only one player and it doesn’t do anything that would compromise performance like iterating through objects or performing collision checks.
Slate is a performance hog, however. Anything involving scrolling lists murders the iPad 2. It seems slate has no batching/atlasing capabilities at all, which really hurts performance.
Slate batches on texture, material and layer. There’s just no texture atlas for UTextures, but all the textures that are the same they can all be batched as 1. The ScrollBox isn’t designed to handle large lists of items. The ListView is the recommended widget to use for large lists of items that are all the same size that need to be virtualized when not in view.
What do you mean by batching by layer? Is it batching elements which use the same texture, but are at the same “depth” at different branches of the widget tree?
I cannot use ListView since attempts at upgrading past 4.5.1 were catastrophic. I’ll try to backport it. Any other slate improvements past 4.5.1?
Layer is kind of depth, but not every widget increments layer as it processes the widget tree. Some widgets only adjust layout and don’t actually draw anything, like the SBox (SizeBox in UMG). It just controls sizing information, so you could render,
HorizontalBox
- SizeBox
++ Image
+Image
Both Image’s would be part of the same batch assuming they’re the same texture, because they both are on the same layer. Now, if you had this,
HorizontalBox
- Border
++ Image
+Image
They will no longer batch because Border draws some of its own stuff, and therefore increments the layer before drawing children.
So many improvements, tick folding (Only tick painted widgets), 1 layout pass, instead of 2. We’re working on even more perf stuff now for 4.9.
Sweet sounds cool i’ll check it out, c if i like it. i’ll give you feed back. ok it says it needs ios 8.0 or later to run on my ipad, does this mean anything created with unreal engine will not work on my ipad?
Hi @intoxicat3, I was long time looking for an example like yours; someone trying to make something serious for android with UE4.
Nice game Guncat, and as you may being expecting is sadly having lot of bad ratings on Google Play because of crashes and incompatibilities. This is what I have to expect from my UE4/android game even if they like it.
May I ask if you after this experience still think worth make your next comercial games with UE4 or would be more convenient use Unity for mobile games until UE4 is mature enough??