SpriteBatchNode displays false color

cocos2d-x C++
#1

f4803a687d672df6.png800×480

In the above screen shot (cocos2d-x 3.2 final):

  • the sun at the left end ( spSun1) and the blue sky (spSky) are in a same SpriteBatchNode (batchNode).
  • 2 other suns are outside the batchNode, one has same SpriteFrame with the spSun1 and the other is loaded from a separate file.
  • When create these objects, I only changed their positions, other parameters stay default.
    So why there’s is a significant difference in color between the one in batchNode and the others? And what should I do to fix it?
#2

This isn’t really a problem with false colors, but rather premultiplied alpha as discussed here:

SpriteBatchNodes are no longer the recommended paradigm for V3, as the new rendering pipeline for V3 does autobatching. You can safely rip these out of your code and still have very good performance.

#3

@toojuice, I have to do anything to use that autobatching feature?
Because the performance is really poor when I switch to not using SpriteBatchNode. I’m using V3.2 final as I said above.

#4

You shouldn’t need to do anything to enable autobatching. What are you doing that is giving you poor performance? Maybe there’s a different reason?

#5

I don’t know if there’s another reason, but practically, just by switching between using and not using SpriteBatchNode (it’s designed so that I can do that just by a very little change in code) I can see the big difference in FPS, while using SpriteBatchNode, FPS is around 60 , it’s only 23-30 in other case.
I didn’t read about the autobatching feature but a friend of mine told me once, and I’m so confused now.

#6

Wow. That’s very odd. How many sprites are you adding to the layer at once?

#7

Less than 30 sprites and 2 LabelBMFont (in both versions, the labels are outside the batchNode)
Anyway, I’m running out of time, maybe I’m just continuing using my good old approach using the batchNode. But I’m struggling finding a way to convert my texture to pre-multiplied alpha as my free shoeBox doesn’t support that. Do you know any simple way to do that?

#8

You could try this method:

http://kevin.c.krinke.ca/2012/04/24/creating-images-with-pre-multiplied-alpha-using-gimp/

#9

Auto batching can not replace SpriteBatchNode. There are some constrains for auto batching.

Sprites should be drawn continuous if they can be batched. For example

draw A
draw B
draw C

If A and C can be batched, but there is B between A and C, and B can not be batched, they all of them can not be batched.

#10

@zhangxm - What determines if a sprite can be batched or not?

#11

They should use the same material id.
Which means they should have the same texture, blend function and shader.

#12

@zhangxm - Thanks for the clarification!

In that case, under most circumstances, autobatching should be able to replace SpriteBatchNode, provided the user swapping out an existing SpriteBatchNode for autobatching in their code.

I’m making the assumption here that since the user was using SpriteBatchNode, the texture, blend function and shader were all the same to begin with.

How can the draw order of the sprites be controlled? I.e. what can @FVS92 do to ensure that when he converts from using SpriteBatchNode to autobatching that he gets the optimal performance?

#13

It seemingly turned out what caused my performance was the blend function. Now I still can not improve the performance in case I put all sprites outside the batch but I can make the batch “suck” just like the other case just by changing its blend function, and it even solved the problem of alpha color.

#14

SpriteBatchNode will copy vertices when you add a child, because you know they can be batched. After a sprite being added to SpriteBatchNode, Sprite::draw() will not be invoked, SpriteBatchNode draw all sprites in its draw. So SpriteBatchNode is still useful.