• Dear Cerberus X User!

    As we prepare to transition the forum ownership from Mike to Phil (TripleHead GmbH), we need your explicit consent to transfer your user data in accordance with our amended Terms and Rules in order to be compliant with data protection laws.

    Important: If you accept the amended Terms and Rules, you agree to the transfer of your user data to the future forum owner!

    Please read the new Terms and Rules below, check the box to agree, and click "Accept" to continue enjoying your Cerberus X Forum experience. The deadline for consent is April 5, 2024.

    Do not accept the amended Terms and Rules if you do not wish your personal data to be transferred to the future forum owner!

    Accepting ensures:

    - Continued access to your account with a short break for the actual transfer.

    - Retention of your data under the same terms.

    Without consent:

    - You don't have further access to your forum user account.

    - Your account and personal data will be deleted after April 5, 2024.

    - Public posts remain, but usernames indicating real identity will be anonymized. If you disagree with a fictitious name you have the option to contact us so we can find a name that is acceptable to you.

    We hope to keep you in our community and see you on the forum soon!

    All the best

    Your Cerberus X Team

performance question

Dubbsta

Active member
Joined
Jul 13, 2017
Messages
208
i have a background that is 5000 pix wide that i want to repeat would i get better performance making a second copy ( so 2 huge images) and loop or slicing it up into almost 500 slices and rendering what is visible and looping that? thx
 
Which platform and hardware do you want to display such huge pictures? How high is the picture?
 
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).
 
so if its a memory issue probably best practice for pc too?
 
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!
 
Last edited:
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 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.
 
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.
 
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.
 
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,
 
Not sure what manage mode is could you tell me where to find it
 
Back
Top Bottom