performance question
- Thread starter Dubbsta
- Start date
- Joined
- Jan 2, 2020
- Messages
- 1,284
I had a similar problem. Android seems to love 256x256. My phone performs x20 times better with
16 256x256 instead of one(!) 320x200. Depending on how new android devices you're aiming for I think that size gets larger. If you want to cover all Androids, go with 256x256 tiles and puzzle them together (like Chrome does).
16 256x256 instead of one(!) 320x200. Depending on how new android devices you're aiming for I think that size gets larger. If you want to cover all Androids, go with 256x256 tiles and puzzle them together (like Chrome does).
- Joined
- Jan 2, 2020
- Messages
- 1,284
Yes, I've looked into that quite a bit, let's say you have a computer that has a native resolution of 1366 x ?
Often it maks a huge difference if you pick 1280 x ? instead, which is suprising in a way you would think they match the GPU with the native resolution to produce a good product (Apple is great at this).
So "Slow" computers are often just misstreated hardware, they don't have hardware that matches their native resolution.
If you start respecting that fact, you can find the actual resolution that a machine is comfortable using, it will make an enormous difference.
I have some sourcecode that runs incredibly nice (steady 60 fps) across many different devices, and then I try some supersimple demo that's not correctly written and get reminded of how bad it can get. The cost of execution is well hidden in patterns that you have to learn for yourself per platform.
Android is the only one that is giving me a hard time still so it stands out in being particular difficult
I think part of it is becaus it runs JAVA so you must think a lot about the actual datastructures and such that you use.
For instance tiling more than 8000 tiles is not possible within one frame I can tell you right away. Mauby not becaue the graphicschip can't handle it but becuase the quickest way that you can go through an array in JAVA is not quick enough.
EDIT : btw I've checked how CX translates it's code to JAVA and CX does JAVA arrays in one of the best ways (as far as I can see).
The true fillrate on ay Android devices is easy to spot though they always lay around 2-3x their native resolution (they're supposed to handle x4 but that last bit gets lost somewhere). I normally aim for 2x that seem to work perfectly smooth even when you put your phone in battery saving mode.
I hope this information is of any help and that you find out a way to paint that huge scene as you wish!
Often it maks a huge difference if you pick 1280 x ? instead, which is suprising in a way you would think they match the GPU with the native resolution to produce a good product (Apple is great at this).
So "Slow" computers are often just misstreated hardware, they don't have hardware that matches their native resolution.
If you start respecting that fact, you can find the actual resolution that a machine is comfortable using, it will make an enormous difference.
I have some sourcecode that runs incredibly nice (steady 60 fps) across many different devices, and then I try some supersimple demo that's not correctly written and get reminded of how bad it can get. The cost of execution is well hidden in patterns that you have to learn for yourself per platform.
Android is the only one that is giving me a hard time still so it stands out in being particular difficult
I think part of it is becaus it runs JAVA so you must think a lot about the actual datastructures and such that you use.
For instance tiling more than 8000 tiles is not possible within one frame I can tell you right away. Mauby not becaue the graphicschip can't handle it but becuase the quickest way that you can go through an array in JAVA is not quick enough.
EDIT : btw I've checked how CX translates it's code to JAVA and CX does JAVA arrays in one of the best ways (as far as I can see).
The true fillrate on ay Android devices is easy to spot though they always lay around 2-3x their native resolution (they're supposed to handle x4 but that last bit gets lost somewhere). I normally aim for 2x that seem to work perfectly smooth even when you put your phone in battery saving mode.
I hope this information is of any help and that you find out a way to paint that huge scene as you wish!
Last edited:
- Joined
- Jan 2, 2020
- Messages
- 1,284
Btw there's one thing about my discussion that I missed to say, and that is that I'm using 32-bit CPU and JAVA can most likely use 64-bit to improve its code efficiency. Maybe not because of the double sized databus but because gets so many more registers to play around and that will show up in loops as a big speedup. So my "8000" should be seen only as true for a general 32-bit Android device. 64-bit Android phones will certinaly give you a lot higher number. I just want to explain when you see a higher number when you're testing.
I deal alot with re-using old machines and I still want to keep the same game-quality as on a new phone, so if anyone says Android can do much higher I will still stand by my 8000. It depends on where you release your app. Some countries recycle their phones increidbly well so thy still use phones 10 years ago, while other countries destroys the earth by getting a new phone every other month.
I deal alot with re-using old machines and I still want to keep the same game-quality as on a new phone, so if anyone says Android can do much higher I will still stand by my 8000. It depends on where you release your app. Some countries recycle their phones increidbly well so thy still use phones 10 years ago, while other countries destroys the earth by getting a new phone every other month.
I would be very surprised if you would be able to use such large images. You should also bare in mind that GPU works better when images are of a power of two e.g. 256x256, 512x512 etc. On modern hardware using the latest API's non power of two images shouldn't be a problem, but Cerberus isn't using the latest GL API. And if I remember, each device will have size limits to an image can be used.
Another thing that will cause speed issues are the number of different loaded images being rendered to the screen. This is why you see many games use sprite/texture sheets to cut down the number of times the GPU's buffer has to be flushed. Read the article Render Hell.
Another thing that will cause speed issues are the number of different loaded images being rendered to the screen. This is why you see many games use sprite/texture sheets to cut down the number of times the GPU's buffer has to be flushed. Read the article Render Hell.
- Joined
- Jan 2, 2020
- Messages
- 1,284
More than 70% of all devices supports GL ES 3 or higher now and everything that supports GLES 3 hardware also supports Vulkan and has Vulkan drivers. So the low-end GLES 2 Android devices are the only problem on the market right now.
Android 4.3 = GL ES 3.0
Android 5 = GL ES 3.1
Android 7 = Vulkan 1.0
Android 9 = Vulkan 1.1
I think that Android 7.1 (not Android 7.0) started early to translate GLES2 to something better under the hood because you see a big improvement in performance happening at that point even if you just use GLES2.
Android 4.3 = GL ES 3.0
Android 5 = GL ES 3.1
Android 7 = Vulkan 1.0
Android 9 = Vulkan 1.1
I think that Android 7.1 (not Android 7.0) started early to translate GLES2 to something better under the hood because you see a big improvement in performance happening at that point even if you just use GLES2.
- Joined
- Jan 2, 2020
- Messages
- 1,284
Another interesting fact is that Android is the only platform that in some respects loves Mojo1 more than Mojo2.
Mojo1 is faster on Android (maybe not all aspects I still have many tests to confirm that I don't think it will always be faster than Mojo2, but for many things it is. (While on HTML and DESKTOP (linux, windows, and macos), and ios ; MOJO2 wins every time.)
Another thing is that can even improve Mojo1 with Android even more, for instance change one magical line in mojo's graphics java file and make it even 20x faster with pixel access (you cannot do that with Mojo2). I'm not saying pixels is the way to go, but it's unbeatable and actually produces 60 fps fullscreen pixelaccess. That's the only way to do it on Android with Cerberus-X currently.
Mojo1 is faster on Android (maybe not all aspects I still have many tests to confirm that I don't think it will always be faster than Mojo2, but for many things it is. (While on HTML and DESKTOP (linux, windows, and macos), and ios ; MOJO2 wins every time.)
Another thing is that can even improve Mojo1 with Android even more, for instance change one magical line in mojo's graphics java file and make it even 20x faster with pixel access (you cannot do that with Mojo2). I'm not saying pixels is the way to go, but it's unbeatable and actually produces 60 fps fullscreen pixelaccess. That's the only way to do it on Android with Cerberus-X currently.
- Joined
- Jan 2, 2020
- Messages
- 1,284
Samsung Note 2 with 7.1 needs 256x256 texture if you use managed mode in Cerberus.
If you don't use managed mode (which preserves the textures when your game is loosing focus on Android) , if you don't use the managed flag the size is much more loose, i havn't seen any slowdowns at all actually.
But if you flag it to be managed, you need 256x256! (you can do even 512x512+ on recent devices I've confirmed).
On my Samsung 32-bit flagship from 2012, you need 256x256. 1 pixel above that and it will go from 60 fps to 4 fps.
The good side of things is that you can have a lot of those 256x256,
If you don't use managed mode (which preserves the textures when your game is loosing focus on Android) , if you don't use the managed flag the size is much more loose, i havn't seen any slowdowns at all actually.
But if you flag it to be managed, you need 256x256! (you can do even 512x512+ on recent devices I've confirmed).
On my Samsung 32-bit flagship from 2012, you need 256x256. 1 pixel above that and it will go from 60 fps to 4 fps.
The good side of things is that you can have a lot of those 256x256,
MikeHart
Administrator
CX Code Contributor
3rd Party Module Dev
3rd Party Target Dev
3rd Party Tool Dev
- Joined
- Jun 19, 2017
- Messages
- 3,500
It's a flag when you create an image via Image.New