COCOS2DX 3.3 cut scene when Rendertexture crash

Source: Internet
Author: User
Tags addchild

In COCOS2DX 3.3 The following myscene have a probabilistic crash when cutting out (the code is minimized to illustrate the problem):

Class Cmylayer:public layer{

Public

Cmylayer () {

M_sprite=null;

M_rendertex=null;

}

Virtual~cmylayer () {

}

BOOL Init () {

M_sprite=sprite::create ("A.png");

This->addchild (M_sprite);

M_rendertex=rendertexture::create (W,H);

This->addchild (M_rendertex);

    

return true;

}

void udpate (float dt) {

M_rendertex->begin ();

M_sprite->visit ();

M_rendertex->end ();

}

Private

Rendertexture* M_rendertex;

Sprite* M_sprite;

};

Class Cmyscene:public scene{

Public

Cmyscene () {

}

Virtual~cmyscene () {

}

BOOL Init () {

Cmylayer*mylayer=new Cmylayer ();

Mylayer->autorelease ();

Mylayer->init ();

AddChild (Mylayer);

return true;

}

};

When the myscene scene is cut out, the probability crashes in two positions:

(1) in the Onbegin function of Rendertexture, Onbegin is sent out as Customcommand in the implementation of Rendertexture.

(2) crash in the Groupcommand of Rendertexture.

Where the first crash position occurs in most of the frequency.

The crash is the most pit-daddy in command, because its execution is asynchronous, so when it crashes it's hard to investigate the state of the object at the time the command was issued, and even the command-issuing object is hard to know! Data/State consistency issues and debug difficulties are the main reasons I hate the command mechanism.

Stop the groove, guess the cause of the crash, it is likely that the scene is cut out due to the M_rendertex with Mylayer destroyed, but M_rendertex emitted Customcommand has been added to the command queue and has not been executed, So when this customcommand executes, it calls M_rendertex's Onbegin function, but M_rendertex is destroyed, resulting in unpredictable results.

In order to avoid the "call object not present" condition caused by "object destroyed but its customcommand issued but not yet executed", I try to take the following two actions:

1. Stop Cmylayer::update as soon as the scene is cut out. (Because the customcommand of the crash is emitted in the m_rendertex->begin () of Cmylayer::update)

2. Postpone destruction of M_rendertex when the scene is cut out.

Specifically, the Cmylayer code is changed to:

Class Cmylayer:public layer{

Public

Cmylayer () {

M_sprite=null;

M_rendertex=null;

}

Virtual~cmylayer () {

if (M_rendertex) m_rendertex->autorelease ();//add, inorder to achieve delay release, use Autorelease instead of release

}

BOOL Init () {

M_sprite=sprite::create ("A.png");

This->addchild (M_sprite);

M_rendertex=rendertexture::create (W,H);

This->addchild (M_rendertex);

M_rendertex->retain ();//add

    

return true;

}

void udpate (float dt) {

M_rendertex->begin ();

M_sprite->visit ();

M_rendertex->end ();

}

void OnExit () {

Cclayer::onexit ();

This->unscheduleupdate ();//add, stop update as soon as possible

}

Private

Rendertexture* M_rendertex;

Sprite* M_sprite;

};

I don't know if both of these changes are necessary, because it is a probabilistic crash, it is time-consuming to validate and reproduce, so that two changes are retained until there is no clearer analysis. So far no more crashes have occurred. But this kind of repair is obviously unnatural, do not know there is no better way.

Add:

In this case, because M_sprite is a normal sprite and does not contain customcommand, there is no problem with the "Call object does not exist" m_sprite, but if m_ A sprite is a custom sprite or a more complex sub-tree structure that also contains Customcommand, and m_sprite needs to be treated like M_rendertex to postpone its release.

COCOS2DX 3.3 cut scene when Rendertexture crash

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.