[Potential bug in v3.2] On certain device the screen is swamped by white when my ScrollView subclass is added (empty)

[JonB]

I describe the problem, it can be avoided somewhat by remembering to stretch a black sprite across all Nodes and Layers instead of assuming they’ll be black, why this particular one is both black and white and doesn’t really know itself, I don’t know. What I would say is some devices are introducing white opacity where no sprite is used, maybe because I’m using mutltiple Layers?.

After reading a bit of the new Dev Guide I realise I’ve confused console based projects with Eclipse, as I run cocos-console to create the project I import into Eclipse, so duplicating the cocos2dx library code, which is may be why I am still using cocos2d::Layer while everyone else is telling me to use Node.

I’ve read [Cocos2d-x 2.2.2] Change background color and appreciate that this is probably an Android specific one, but my problem is the reverse. On almost all devices (all emulators at least) I have a black background but at least one (pesky, new, locked down, Samsung phone I can’t even see in adb devices to debug) I am getting a white background instead. This hides my white text the game was designed for

    static Color3B &invCol(const Color3B &origCol) {
        static Color3B colPH = {255 - origCol.r, 255 - origCol.g, 255 - origCol.b};
        return colPH;
    }
    
    static void toast2Cols(const Color3B &foreCol, const Color3B &aftBackCol) {
        char tmpStr[256];
        sprintf(tmpStr, "f={%d,%d,%d}, b={%d,%d,%d}",
                foreCol.r,
                foreCol.g,
                foreCol.b,
                aftBackCol.r,
                aftBackCol.g,
                aftBackCol.b
        );
        Globals::showJavaToast(tmpStr);
    }


//init then contains:
    //this->setOpacity(255);
    //false is default and true causes failure.
    //this->setCascadeColorEnabled(false);
    this->setColor(Color3B::BLACK);
//Some setting of member variables
    pTimerLabel = Label::createWithBMFont(fntNm, "3:00");
    pTimerLabel->setColor(invCol(this->getDisplayedColor()));//Color3B::GRAY
    toast2Cols(pTimerLabel->getDisplayedColor(), getColor()); //Displayed
    addChild(pTimerLabel, 1);//Must be zOrder > 0, or it's not seen.

But this new Samsung phone is really weird. Not only can I not see the Label at all when using default zOrder (0, or -1 I think?) but when I increase that to 1 the font is still white with a darker outline, which is how I made the BMFont. The routines I show to display background (this's) colour are reporting it as black when it is clearly white, just on this phone, that I know of.

The bottom bar is supposed to show the timer and both bars be black, I’m dumbfounded why the text box below the top bar has kept a black background when nothing is drawn there (as yet).

Sorry to self promote but the apk is available free here

[JonB]

I appreciate you’re all very busy and thank you for writing open source and portable code but I’ve filmed the problem and link and repeat the text description here:

This Samsung Ace 4 LTE (1GB) is exhibiting strange white out behaviour while all my other devices and emulators don’t, I’ve fixed it with the main game board. That required some reshuffling of zOrder values until eventually I gave up on global zOrder and just stretched a black sprite behind each of the top and bottom bars where icons and text were being camouflaged. I thought that was enough and maybe it was my fault. Now I’ve explored other options/screens and they too are swamped by this strange white glow.
I can’t see where it is coming from. The Contested words should be white on black and black on white but you’ll see all that is showing is the black on white. I’ve tried reading the background colour and inverting it but it is saying it’s black so sticking with white text.

The Word Lists look like:

class WListV : public cocos2d::ui::ScrollView {
     populate(const cocos2d::Rect& bbox, SrcData &srcData) {
         setContentSize(bbox.size);
         setPosition(bbox.origin);
         setBackGroundColorType(ScrollView::BackGroundColorType::SOLID);
         setBackGroundColor(srcData.colour);

so shouldn’t even cover the whole screen and stretching a black sprite over the top of them using

//    opaqBG = Sprite::createWithSpriteFrameName("b4x4");
//    opaqBG->setScale(bbox.size.width / opaqBG->getContentSize().width, bbox.size.height / opaqBG->getContentSize().height);
//    opaqBG->setPosition(bbox.size.width / 2 + bbox.origin.x, bbox.size.height / 2 + bbox.origin.y);
//    addChild(opaqBG, 22);//default, 0, 1 and 2 are too small for Galaxy Ace 4 LTE. 3 big enough but blanking stuff out.
// 22 did nothing, invisible

has no effect at all. I’m forced to use the background that was translucent and added underneath the Word Lists and add it on top, which of course obliterates all sense from the Word Lists.
See my other video

for how this opacity looked on other devices before this nasty kludge.

EDIT:

I think it’s something to do with the macro code:

Scene* MenuScene::createScene() {
    // 'scene' is an autorelease object
    auto scene = Scene::create();
    // 'layer' is an autorelease object
    auto layer = MenuScene::create();
    // add layer as a child to scene
    scene->addChild(layer);
    // return the scene
    return scene;
}

As that appears to be adding Layer's with conflicting z-order to the global Scene. Too late now, I’ve called it half a dozen times and only just regretting it. Oh, and this is cocos2dx v3.2 BTW

EDIT2

I’ve tried removing both the lists you see in the Lenovo video. That solves the problem nicely. Then I tried reintroducing them one at a time. The WListV to be added last takes precedence, I can see a black background with white text now the black list is added last. (I’ll try populating it so it’s easier to see away from the notification area.)

If I add just one (each has one horizontal half of the screen) the whole are aside from the header box is rendered white, despite the caller not delegating updation of the bottom menu bar.

If I remove all the addChild calls from WListV (these were part of the populate method since touch handlers aren’t called) it is still covering the whole screen in white.

Sort of Conclusion

Something about how I’m using (I always subclass from it) ScrollView must be wrong, as it was so poorly documented at the time I thought getting it to work at all was good enough, rather than on every device.

What I’ve noticed is the ScrollView is itself displayed correctly but everything around it is turned white. I’d hazard a guess that this is occurring at the same zOrder as the ScrollView itself and will report back.

Conclusion

Crikey, 13hours since last update, beginning to think post got canned.

Spent the day rewriting several classes pulling my hair out in frustration. I love this place, but it was poorly documented bugs like this that lead me to trying SDL for my second game. All regrets concerning that little sabbatical were duly vindicated. What can I add? Some of the rewriting was not deemed worth while as I don’t know how many devices are affected like this. If you try my Plucky Words you will still find out by viewing the bottom bar, under the ui::ScrollView that is displayed after non-quick-fire games, the one with all the words listed. The bar is white and selectively letting the ScrollView's Labels bleed through it. According to my zOrder it shouldn’t happen, and I hadn’t ever deliberately painted a white background before tackling these bugs so can deny blame.