IOS testing found a performance issue that you can check out

Bugs
1

  • Using the engine provided by the demo revamp added a virtual joystick to achieve the effect of control movement

  • The demo path I used is: examples\deprecated_to_upgrade\isometric_game

  • So what I’m going to do is I’m going to create an imageControl and I’m going to put a button under it and I’m going to handle three events on that button to figure out where the character is going

  • The three events are: OnPress,OnRelease,OnMotion

  • I had almost no performance loss on windows and android, it was very smooth, but it was almost impossible to play properly on ios

  • When I entered the game on ios platform and the screen was still and I did nothing, I only had 5-6 FPS. At first, I thought there was something wrong with my logic, so I started to debug

  • After repeated verification, I got the following results:

  • I had 60 FPS when I didn’t render the map and characters at all and left my virtual joystick scene in a black screen where only the joystick was visible

  • But I kept the logic of the code that calculates the direction of the joystick when I touch it to move it. As long as I keep moving the joystick, the logic will keep triggering, and the fps will drop from 60fps to 50-35 FPS

  • The code of my calculation direction does not have any loops, only some simple arithmetic operations, and the code is less than 20 lines, which is obviously not enough to make the frame drop so badly in my understanding

  • It is worth noting that the same situation I had on windows and android with almost no framerate loss.

  • And I opened up the rendering code for the map scene and I didn’t use the joystick and it only had a frame rate of 5 or 6 FPS so obviously that’s a big performance result

** I want to know what the problem is and I need your help. If you need my code, please provide an email address and I will send it to you so that you can study and debug**.

2

Thank you for the report!

As I understand, in your program, the worst framedrop (to 5-6 FPS) occurs when you don’t move the joystick. That is weird… Let’s debug :slight_smile:

  1. To be clear: what FPS do you have if you execute just the unmodified examples\deprecated_to_upgrade\isometric_game ?

  2. Does activating batching help?

    • Find the WindowRender procedure in examples\deprecated_to_upgrade\isometric_game\code\gameinitialize.pas,
    • add a call to TDrawableImage.BatchingBegin at the beginning of that procedure job,
    • add a call to TDrawableImage.BatchingEnd at the end of WindowRender work (these are class methods, so literally paste TDrawableImage.BatchingBegin; or TDrawableImage.BatchingEnd; into the code).

  3. What FPS do you have when you execute examples\isometric_game ?

Note: As the name says, the approach from examples\deprecated_to_upgrade\isometric_game to make isometric game is deprecated. It’s quite complicated to manage these TDrawableImage instances, and not that functional (e.g. you cannot add ready physics or sprite sheets on top). We recommend instead following new examples\isometric_game . It uses a different approach to render (using TCastleScene, TCastleTransformImage instead of TDrawableImage) which is more flexible (more discussion about 2 methods to render 2D in CGE: How to render 2D games with images and sprites | Manual | Castle Game Engine ). That being said, of course neither example (not even the deprecated one) should have so bad framerate like 5-6 FPS.

3
  • Hello! Thank you very much for your assistance in dealing with this problem
  • I have carried out some tests according to your reply, let me follow the steps to feedback your suggestions
    • I made some minor adjustments to examples\deprecated_to_upgrade\isometric_game:
      I’ve tweaked the order of Render so that I can display the UI which is TCastleView
      The normal drawing order is that TCastleView.Render takes precedence over tcastleWindow.render
      then normal TCastleWindow. The Render for TCastleView will be slower than the Render for
      TCastleWindow. The Render of TCastleView overrides the Render render of TcastleView
      And I used the WindowRender example directly in TCastleView.Render to cancel the “.
      Window.OnRender := @WindowRender” This code
      That’s the only difference
    • I added the way you tell TDrawableImage BatchingBegin and TDrawableImage BatchingEnd frame rate from 5 ~ 6 to 20 ~ 30 frames This is a surprise
      According to my careful observation, when the map has fewer tiles, the frame rate can be about 30, and when the map has more tiles, it will be reduced to about 20
      Therefore, I feel that DrawableImage.Draw takes more time and WindowRender returns slower
    • examples\isometric_game I didn’t test the frame rate because my computer was already borrowed
      I dissected the source code for examples\isometric_game and looked at the TCastleImageTransform, which did not meet my requirements for the project
      Because I usually probably encrypt the images and gather them in an encrypted file and read them out of memory and draw them, for security reasons
      TDrawableImage It’s more suited to my needs and it’s flexible even though it’s a little bit more difficult to manage and I still want to use it to bring out the goals that I need