Using Sprite.graphics increases its width and height to unnecessary amounts in native

#1

… and possibly Flash too. When testing the following code:

if ((e.target == _redMatcher && (_currentColour == "red" || _currentColour == "purple" || _currentColour == "yellow")) ||
            (e.target == _greenMatcher && (_currentColour == "green" || _currentColour == "aqua" || _currentColour == "yellow")) ||
            (e.target == _blueMatcher && (_currentColour == "blue" || _currentColour == "purple" || _currentColour == "aqua")))
            {
                trace("hello");
                //SUCCESS
                _comboBar.increase();
                _txtCombo.text = "x" + _comboBar.combo;
                var primaryColour:String = "";
                if (e.target == _redMatcher && Colours.isSecondary(_currentColour))
                    primaryColour = "red";
                else if (e.target == _greenMatcher && Colours.isSecondary(_currentColour))
                    primaryColour = "green";
                else if (e.target == _blueMatcher && Colours.isSecondary(_currentColour))
                    primaryColour = "blue";
                
                if (e.target == _redMatcher)
                    _redAbilityBar.increase();
                else if (e.target == _greenMatcher)
                    _greenAbilityBar.increase();
                else if (e.target == _blueMatcher)
                    _blueAbilityBar.increase();

                ...

The trace output to display “hello” does not show up. In the Flash target, the combo bar does correctly increase however, as expected, while the ability bars do not.

In the neko target, I am getting a completely different line, which is outside the scope of this function about 100 lines down. I am using a Tilesheet to draw and display graphics inside a class called AbilityBar. Is the Tilesheet the reason why the AbilityBar has its component sized to exponentially larger than what was intended (not to overlap the Matchers) or could it be the graphics component from Sprite.graphics?

I can’t tell yet.

The above image displays the current interface for the game. I just can’t quite get my head around this. Or maybe my Flash Player is for some reason not displaying the traces, because when you click on it you can see the results clearly… that combo bar does increase!

The function inside the AbilityBar for increase() looks like this:

public function increase():Void
    {
        if (_currentChunk + 1 > _chunks)
            _currentChunk = _chunks;
        else
            _currentChunk++;
        
        trace(_currentChunk);
        
        var value:Float = _currentChunk / _chunks;
        
        var percent:Float = Utils.roundToNearest(10, value);
        getAbilityState(Std.string(percent));
        
        
        if (percent == 100)
            _active = true;
    }

private function getAbilityState(value:String):Void
    {
        _back.graphics.clear();
        _abilityBar.drawTiles(_back.graphics, [0, 0, _map.get(value)]);
    }

Changing the order at which the graphics are added to the stage does make a difference in neko in that the Matchers can now be interacted with, but that doesn’t really solve the Flash issue, nor the original, which is why these Ability Bars won’t increase in either target. I’m just confused at this point.

Anyone have any suggestions? Any help is appreciated.

#2

Nevermind… Got what I needed to know… Although I would still like to know what this width/height issue is when using the Graphics component in native targets:

Using the following code:

_map = new Map<String, Int>();
        
        _abilityBar = new Tilesheet(Assets.getBitmapData("img/AbilityBarTiles.png"));
        _map.set("100", _abilityBar.addTileRect(new Rectangle(0, 0, 112, 13)));
        _map.set("90", _abilityBar.addTileRect(new Rectangle(0, 13, 112, 13)));
        _map.set("80", _abilityBar.addTileRect(new Rectangle(0, 26, 112, 13)));
        _map.set("70", _abilityBar.addTileRect(new Rectangle(0, 39, 112, 13)));
        _map.set("60", _abilityBar.addTileRect(new Rectangle(0, 52, 112, 13)));
        _map.set("50", _abilityBar.addTileRect(new Rectangle(0, 65, 112, 13)));
        _map.set("40", _abilityBar.addTileRect(new Rectangle(0, 78, 112, 13)));
        _map.set("30", _abilityBar.addTileRect(new Rectangle(0, 91, 112, 13)));
        _map.set("20", _abilityBar.addTileRect(new Rectangle(0, 104, 112, 14)));
        _map.set("10", _abilityBar.addTileRect(new Rectangle(0, 118, 112, 13)));
        _map.set("0", _abilityBar.addTileRect(new Rectangle(0, 131, 112, 13)));
        
        _active = false;
        
        getAbilityState("0");
        
        addChild(_back);
        
        trace(_back.width + ", " + _back.height);
#3

Right now, the bounds check is disabled when using drawTiles, if we looped in the data to determine the size, it might ruin any performance benefit we get from batching. On the other hand, perhaps a size of zero would be better than the stage width and height?

I think we should consider moving drawTiles to a different display object, which might help make the distinction clearer and open up some other good opportunities for it…

#4

What if you put the expensive calculations in get_width() and get_height()? Then the programmer could chose when to calculate width/height, but by default, the calculations would be skipped. Or am I missing something here?

#5

Graphics bounds are updated as you add draw calls, it is used not only for bounds or width/height checks, but also for hit testing when processing mouse events