• 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

Android platform

Wingnut

Well-known member
3rd Party Module Dev
Tutorial Author
Joined
Jan 2, 2020
Messages
1,414
To me it seems that CX compiles amazingly well on all platforms but Android, which is still good but it certainly does not have the exact same quality.
Web is amazing, macos, linux, windows10 are all amazing, ios as well. Android on the other hand can show problems with graphics performance even if the devices themselves have more to give.

Is the Android platform / JAVA files that are put together very differently compared to the other platforms in CX?
 
With JAVA there is a slower performance, especially rendering wise. Mojo2 performs better but is still behind other platforms.
Only a rewite of the graphics stuff to a JNI (C++) solution would help here.
 
I don't quite see a low performance. Back in 2015 I've made this: lots of "spriter" animations running on screen, no speed problem at all.

The only problem with Java is the same with C#: garbage collection. As long as you avoid it (and also try to pack imagens into a single pow2 sized texture), you'll get good performance.
 
I'm not familiar with the exact term but Android has an option to preoptimize the first time it runs an app. This gives a very nice experience after the first 10 seconds or so. It will also remember this optimisation every time so it happens only the very first time you download and run the game. Does CX use this feature? Otherwise the app will try to constantly optimize in runtime.
 
I have no link sadly. I read about it last week but from memory I can't remember much. Maybe DEX? It started with an A. I saved the article for next year because it seemed important when I start developing for Android. It was actually bothering me at first and that was why I started to look around and I found lots of users complaining about this new update which was buggy evidently.

I had some other non-buggt version but that was how i found out and I start to love it. It gives a more stable app. I'm not sure what it does but I think it optimises JAVA byte code and it seemed to be a well known (more or less) standard thing.
 
Android's OS has a number ways to perform optimisations. The most common are JIT (Just-In-Time) and AOT (Ahead-Of-Time). For more details see the Android OS Core Topics. If I remember, Android also does optimisations when you install the APK file.

If you see issues with performance, then you should load the resulting Cerberus Android project into Android Studio.
 
But the thing is that it also happens on older devices for me so I'm not sure what it is. I use a lot of new tools and libraries now so there might be other details that matters too. I was sure that this was a JAVA optimization though.
 
I don't quite see a low performance. Back in 2015 I've made this: lots of "spriter" animations running on screen, no speed problem at all.

The only problem with Java is the same with C#: garbage collection. As long as you avoid it (and also try to pack imagens into a single pow2 sized texture), you'll get good performance.

How did you make it work? Maybe you had lower number of individual drawing? It's easier to get a few number of big draws than a high number of small drawings. Even when I batch I get problems and I don't use anything that gives me garbage.

This demo gives me half of the number of draws that I normally use easily in my world using a dedicated graphics library. I don't see any reason for CX to have a different output.

Of course I'm not sure if you will get the same result as me using this code but here it does not look good. I can't use it on low-end devices. I believe that these kind of scenarios are typically improved a great deal using JAVA byte code optimisation.
 

Attachments

  • batch.zip
    4.4 KB · Views: 61
I just batch a ton of graphics into a single texture atlas. Then I draw them all, without changing textures.
Here the atlas for all the "defenses" in my game, for example:
defesas.png

Looking briethly at your code... why on Earth are you drawing 4000 images?! If you look at the source of DrawPrimitives, you'll know why its slow:

Code:
    Method DrawPrimitives:Void( order:Int,count:Int,vertices:Float[],texcoords:Float[],material:Material=Null )   
        BeginPrims material,order,count
        Local p:=0
        For Local i:=0 Until count
            For Local j:=0 Until order
                PrimVert vertices[p],vertices[p+1],texcoords[p],texcoords[p+1]
                p+=2
            Next
        Next
    End

As you can see, it processes your 4000 tiles FOUR TIMES. Of course that will be slow on mobile, specially when rendering small 8x8 images.

If you're aiming at high resolution, you should use bigger tiles (even variable sized ones, so you can draw bigger objects in a single call) or you should render your whole game in low res and scale it up to the screen size.
 
I easily get 8000 sprites this way on same device using libGDX so its not about the method as such. But I agree that that t must be something in the code, sadly i cannot point to you where if i could i would change it.

Well when you mention the methods you are using, I have done the same my whole life so I am just asking why is it not working in Android?

As you see this works wonders inside a webrowser if you compile to HTML in Cerberus, and the same with other platforms (i have not fixed so desktop will output a screen yet becuase i usuaully use other commands but I want to show you batch.

Cerberus need to use one of few special commands to batch. Many libraries lets you batch with any commands so you batch using any commands inside tags that will the GPU what the src and dst is and you cannot change those inside the loop. That is a general batching, It's very handy.

Android have also no problem at all with 8000 objects if you use library for graphics. Cebrerus has no problem either in general with this. Only with Android. Right now I'm looking at 8k objects but sadly its not done using CX.. but use this exact method.
 
12k? it should be 1k x 4, okay i cant check it now I'm too cold my fingers are frozen 🥶, but I checked 4K last night and it too did not work well.

Actually 1k does not work either. Its inherently something wrong with the code, because you can see it does not produce any garbage or slowdowns. And you also know that graphics are done in a separate thread. On top of this code tries its best to not batch things for the GPU (i am not sure it does a good job to be honest).

Somehow it's still interrrupted all the time and that's the keypoint I wanted to make.

EDIT Okay I see now what you mean with 12k now, inside the command of the Cerberus sourcecode. I'm not sure how to batch in any other way. you have the batch start (Prim) and then you loop to give the GPU any updated data, lets say you have game so you update every frame. Well this is basically what you do then when you batch. This is the same inner code that you would se in a 3d game with only 4000 quads basically. So i don't think I am asking too much from the GPU nor CPU.
 
Last edited:
It's just JAVA code and GPU (as few call as I can possibly make, which is one per frame).
 
Why is your image 600x600 pixels? This is pretty huge for a batch like that. And still it runs pretty smooth on my fire hd 8 and galaxy s6.
Funny enough it only shows a black rectangle on html target.
 
Yes I think there might be some command needed or maybe ppl have not used it enough so it might be some bug.
I useually use DrawRect and that works perfectly on HTML too. But I needed to show off batch and this is the only way to get batch in CX.

800 x 600 ?? whoa it is supposed to b 8x8 i am not sure where you get that 800x600 it sounds terrible.
 
Nope that was a short duration of hope. I resized it and it still gave the same result. It was terrible i would not say usable.

What IS amazing is that the performance is the same using 600x600 as using 8x8 texture. That was so impressive. There's is certainly bad JAVA code here.

EDIT Btw on all other platforms you do not even need to batch it will give good result anyway. So Android forces me to explore batch commands, that is probably why HTML becomes black. I missed something critical, same with desktop. (But those platforms does spledid using only DrawRect so I am not bothered about that.

Maybe I can call the libGDX .jar file inside Cerberus somehow? As this one works perfectly. I where to try that where should I start?

I noticed just now that Android platform uses "GameView" which is inherited from accelerated surfaces. According to Googles standards these has these exact problems. It's espcially visible at high number of objects, so That might be it. Only pure Opengl will give you a better experience. What happens if you use OpenGL commands in CX? is it still inside a Gameview?
 
Last edited:
I resized it and it still gave the same result. It was terrible i would not say usable.
I have some time the next days, so I could help you get a viable solution for your use case. For that it I definitely need some more specific description, especially what android device are you using as the lower limit of supported devices and what framerate do you expect with your testcode. That's what I can test on:
- Samsung Galaxy S4 Mini phone (Android 4.4.2 = API Level 19)
- Samsung Galaxy S6 Edge phone (Android 7.0 = API Level 24)
- Samsung Tab 4 SM T535 (Android 5.0.2 = API Level 21)
- Sony Xperiy Tablet Z SGP311 (Android 5.1.1 = API Level 22)
- Amazon fire HD8 (10th Generation)
 
Last edited:
I fixed this morning. It works html now i think it was size or inregularity of size.
 

Attachments

  • newbatch.zip
    6.5 KB · Views: 56
Nice test equipment. I have Huawei mediapad Android 4.4 and Samsung A3 Android 7.0 as well as an well updated Samsung A52s 5g (currently API 30 or 31 i think)
 
Back
Top Bottom