[ChristianFelgo Team]

Hi, everything is working in my game so far 🙂

But I have noticed that we have serious performance problems on older single-core phones like my HTC Desire Z (512MB, 800MHz).

I have tried solving that in two ways so far:

• Loading sprites from spritesheets: Until now I have just been using Image elements for my graphics, loading every sprite from a separate PNG file (~20 files of ~100×100 pixels). I understand that loading them from one spritesheet would be a great performance gain. But the problem is, when using sprites from a spritesheet, you can’t seem to dynamically adjust their Z-values, which I need for my game as we discussed earlier. Or am I just doing it wrong? I have the SingleSpriteFromSpriteSheet element as child of my entities.
• Particle effects: When moving blocks I use particle effects. I want a little bit of smoke coming out of the Block when it slides across the field (only for not even half a second). It looks very cool i think, but they seem to be causing performance problems. When I disable them, the performance problems are gone. Maybe I just didn’t set them up right, would you be so kind as to look into my particle configuration:

SmokeParticles.qml
Particles {
    property real vectorZ: 1000

    textureFileName: "../resources/particles/particleSmoke.png"
    duration: 0.1
    emissionRate: 60
    maxParticles: 1000

    particleLifespan: 0.3
    particleLifespanVariance: 0.02

    sourcePositionVariancey: 0
    sourcePositionVariancex: 0
    sourcePositionx: 0
    sourcePositiony: 0

    startColorRed: 0.75
    startColorVarianceRed: 0
    startColorGreen: 0.75
    startColorVarianceGreen: 0
    startColorBlue: 0.75
    startColorVarianceBlue: 0
    startColorAlpha: 0.800000011920929
    startColorVarianceAlpha: 0

    finishColorRed: 0.1000000014901161
    finishColorVarianceRed: 0
    finishColorGreen: 0.1000000014901161
    finishColorVarianceGreen: 0
    finishColorVarianceBlue: 0
    finishColorBlue: 0.1000000014901161
    finishColorAlpha: 0
    finishColorVarianceAlpha: 0

    startParticleSize: 7
    startParticleSizeVariance: 3
    finishParticleSize: 30
    finishParticleSizeVariance: 10

    gravityx: 0
    gravityy: 300

    angle: 90
    angleVariance: 60
    speed: 10
    speedVariance: 0
    radialAcceleration: -30
    radialAccelVariance: 10

    blendFuncSource: 770
    blendFuncDestination: 771

    emitterType: 0

    minRadius: 0
    maxRadius: 100
    maxRadiusVariance: 0

    tangentialAcceleration: 0
    tangentialAccelVariance: 0
}

As texture i use the particleSmoke.png from the StackTheBox game.

[ChristianFelgo Team]

PS:

For some reason my build isn’t working anymore:

https://builds.felgo.com/builds/195

Info: Created directory structure
Using Felgo SDK version: v1.1.0
Create Android project..
Copy assets..
Copy Felgo jar...
Build native Android project..
Error: Android library not created
Create iOS project..
Build Xcode project...
Error: iOS ipa not created
Build finished in 0 min 7 sec

Could you please take a look at that too?

[AlexFelgo Team]

Regarding the latest build, we found a small error in our build environment and already fixed that, thanks for the hint. 😉

Alex

[ChristianFelgo Team]

Hi Chris,
I really appreciate your posts – challenging and it shows you are making good progress with your game! 🙂

You are right, we did not support changing the z value of sprites from spritesheets at runtime – until now! We just added this functionality to the latest version and now you can change the z value of a parent item (in your case the Entity) dynamically and the sprite will be reordered correctly.

Please test this functionality with the latest build, available temporarily here:
https://dl.dropbox.com/u/13974554/VPlayLibsWindows-zOrderingSpriteSheets.zip

If everything works for you as expected, we will integrate it into the next release, which should be released in about 1-2 weeks. In the meantime, it will not work on the build server as well, before we did not test it locally with your use-case.

Regarding your particle performance issue:
As the documentation is saying about the maxParticles property:

The maximum number of particles that get created during their particleLifespan. The emissionRate is calculated based on this property.

Note: Particles do have a performance impact. Try to use as few particles as possible to achieve a good-looking result and test the performance on the mobile devices.

In your case, you modified the emissionRate, particleLifeSpan AND maxParticles. Please only modifiy 2 of these properties, favoribly the maxParticles and particleLifespan props. We recommend to set maxParticles to values lower than 100, because usually you do not get any visual improvements by setting it higher! However, please test these settings on your desktop first and then set it to a value that still suits your visual requirements. It is then essential to test the particle effects also on mobile devices (as you did), because particle performance is much worse on mobiles than on desktop platforms!

To assist you with this testing, we are working on improvements of the ParticleEditor, so you can test the impact of particle property changes directly on your device! This will also be added in the next release.

Here are some more tipps to make the smoke particles appear bigger:

• Increase the startSize to values around 20, so your effect looks “fuller”
• Make the startcolor darker, by decreasing the startColor values for red, green and blue to values around 0.2

Cheers, and I can’t wait to test your game!
Chris

[ChristianFelgo Team]

Hey Chris & Alex,

thanks you so much for helping all the time 🙂

The build is working fine again.

I considered your hint for the particles, and it turns out i can set maxParticles to as low as 25 and still get it to look nice 🙂

As for the sprites, I’m afraid i didn’t get it to work by now.

I use this inside my EntityBase-objects:

    SingleSpriteFromFile {
        id: sprite
        source:  item.sprite
        filename: "../resources/sprites/sprites.json"
        anchors.left: parent.left
        anchors.top: parent.top
    }

With sprites.json being generated by TexturePacker (actually sprites-hd.json and so on).

Everything is drawn correctly, but the sprites appear on top of everything else (I would sometimes like to place a menu or a text on top of a sprite) and they don’t seem to be ordered when the z of their parent (The EntityBase object) changes.

But at least they are in correct z-order when they are first loaded.

So your fix didn’t change anything for now, or could it be that I’m missing something?

Cheers,
Christian

[ChristianFelgo Team]

Hi,
yes this is expected behavior, because all sprites from the same spritesheet are added on top of all other sprites by default. To change that, you can put a SpriteBatchContainer wherever you want to:
http://doc.felgo.com/qml-components-vplay1-spritebatchcontainer.html

We did the same with Squaby for example, where you can have a look at the source code.

So please note that z-ordering does only work for the sprites within the same sprite sheets, and all sprites are drawn in the SpriteBatchContainer.

If placing the SpriteBatchContainer manually does not work, here is another approach:
Put all sprites of your game into the same spritesheet. That way, z-ordering of them works because they are drawn correctly. If you exceed the maximum texture size of 2048×2048 if you put all into one spritesheet, you could separate the graphics into different sprite sheets, e.g. one for the overlay menus, one for the game graphics, etc.

Please also mention to clean your build when using the updated library with z changing support of sprite sheets from the dropbox link above. For testing if the z-ordering works, you can use this qml file and use the all-*.png and all-*.json files from Squaby demo:

import QtQuick 1.1
import VPlay 1.0

GameWindow {
  Scene {
    id: scene

    Rectangle {
      anchors.fill: parent
      color: "lightgrey"
    }

    // tests the changing of z at runtime for cocos renderer - by clicking on the window the z order of the 2 images change from 0 ... 2
    // this test must have the following behavior (for both cocos and QML renderer!)
    // initially, ten must be below twenty: they have the same z value (1), but ten is defined first so it is rendered first and twenty will be on top of it as it is renderer afterwards
    // with z=0 twenty must be below ten, as it has a lower z than the sibling
    // with z=1 twenty must be on top of ten, because it has the same z as the sibling, but is put at the end of all same z items
    // with z=2 twenty must be on top of ten, as it has a higher z than the sibling

    // NOTE: in contrast to the ZChangeTest, the behavior in cocos renderer is exactly the same as in QML what is desired!
    // so even when z changes later on to the same value, the twenty is put on top of the ten image!

    SingleSpriteFromFile {
      id: ten
      x: twenty.width/2
      y: twenty.height/2

      filename: "img/all-sd.json"
      source: "10.png"

      translateToCenterAnchor: false

      z:1
    }
    SingleSpriteFromFile {
      id: twenty

      filename: "img/all-sd.json"
      source: "20.png"

      translateToCenterAnchor: false

      z:1
    }

    // this simulates the behavior, when the Sprite is put as child of an entity, and the entity z order changes
    // this also has to change the sprite z order then!
    // so the test must show the same z ordering of both the left and right 2 sprites
    Item {
      id: tenFolded
      x: scene.width-twenty.width*1.5
      y: twenty.height/2

      z: 1
      SingleSpriteFromFile {

        filename: "img/all-sd.json"
        source: "10.png"
        translateToCenterAnchor: false
      }
    }
    Item {
      id: twentyFolded
      z: 1
      x: scene.width - twenty.width

      SingleSpriteFromFile {
        filename: "img/all-sd.json"
        source: "20.png"
        translateToCenterAnchor: false
      }
    }

    Text {
      text: "10 z: " + ten.z + "\n20 z:" + twenty.z
      anchors.centerIn: parent
    }

    MouseArea {
      anchors.fill: parent
      onClicked: {

        // toggles the z order of twenty from 0 to 2
        if(twenty.z === 2)
          twenty.z=0
        else
          twenty.z++

        // also change the entity-simulation
        if(twentyFolded.z === 2)
          twentyFolded.z=0
        else
          twentyFolded.z++
      }
    }
  }
}

Cheers,
Chris

[ChristianFelgo Team]

EDIT: I forgot to clean my build…it works!! Thank you so much 🙂

Everythings working perfectly fine, would be nice if you could update this on the build server too 😉

[ChristianFelgo Team]

OK one more thing… (I hope I’m not annoying you 🙂 )

When you change the source of a sprite in a SingleSpriteFromFile element, and the new sprite has a different size, it gets screwed up pretty badly…this also happens in your demo when i do this:

 twenty.source = "bed.png"

(I solved this by using same sized images for parts where they can change, but it’s still weird)

[ChristianFelgo Team]

No you are absolutely not annoying anybody – great you have these requests!

Well the issue with source-changing is, that it is not supported to change the source at the moment 😉

The better approach would be, to create different variationTypes of an EntityBase where each one has its own sprite and pool. This is also more efficient for pooling as the source never needs to be changed, as it is done in Squaby.

Would you require this functionality to change the source of sprites in a spritesheet at runtime?

Cheers,
Chris

[ChristianFelgo Team]

Quote from Christian on January 9, 2013, 23:16
Well the issue with source-changing is, that it is not supported to change the source at the moment 😉

Cool, because when you use sprites of exacly the same dimensions, it still works 😛

With different variationTypes, did you mean changing the variation type and then setting a different sprite visible?
Because I need one entity to have different “appearences” based on properties.

Btw, the game performance got worse when playing on a real phone now that I’m using spritesheets. Especially the loading of levels when creating and deleting a lot of items dynamically. The overall performance could even be slightly better now.

I’m assuming that’s because of the building in debug mode, because on the PC it also takes a lot longer to load now, and in release mode it works perfectly fine.

Oh and please let me know when the build server does the sprites z-ordering correctly 🙂

[ChristianFelgo Team]

No with variationTypes I meant you keep the same source per entity, as it is implemented in Obstacle.qml in Squaby.

Do you really need different appearances for one variationType, or could you reuse the same entity with different variationType settings?

You are right, loading of the sprites of a spritesheets takes longer than images, because the file information of the json file from TexturePacker nneds to be extracted and the sprites are more complex to create. You can alleviate the problem by pre-creating entities at the application launch or when loading the level first time and showing a loading screen so the users don’t get impatient. Pleas also see Squaby how we implemented it.

The runtime performance of sprites is much better than with images, because only a single draw call is involved and not one per image! The number of required draw calls is one of the most limiting performance factor on mobile devices, so you should get a decent 60fps up to a couple of hundred images. If you want to test the performance differences of Images and sprites you can build the PerformanceTestCollectionMain.qml file in the examples folder of the Felgo SDK.

The build server will support z-ordering with the next release 😉

Cheers,
Chris