Best way to scope screen dimensions?

cocos2d-x C++
#1

It seems that in order to maintain proper physics (with Box2d) and sprite positioning I need to first know the screen dimensions. I would like to simply store the screen width and height in some variables in the beginning of the application to access it my other classes. I’m just not sure how to scope them correctly, along with any other information i need at startup. I am currently doing this everytime i need to position a sprite:

CCSize visibleSize = CCDirector::sharedDirector()->getVisibleSize();
CCPoint visibleOrigin = CCDirector::sharedDirector()->getVisibleOrigin();
float visibleRight = visibleSize.width + visibleOrigin.x;
float visibleTop = visibleSize.height + visibleOrigin.y;

This is sloppy to me. What is that best practice I am looking for? Thank you.

#2

I have a generic class that all my visual game objects inherit from, where the class has CCPoint visibleOrigin and CCSize visibleWinSize as protected members (and other shared members I use a lot). As long as you are wrapping your objects in their own proper classes, this should be a quick fix.

#3

Why not just call CCDirector::sharedDirector()->getVisibleSize() when you need it? It’s not that slow. At least there are a lot of other things that could become a bottleneck.

Justin Godesky wrote:

I have a generic class that all my visual game objects inherit from, where the class has CCPoint visibleOrigin and CCSize visibleWinSize as protected members. As long as you are wrapping your objects in their own proper classes, this should be a quick fix.
So you’ve just expanded the memory footprint of your app sharing those data among ALL game objects? Do you think that you gain more performance and this trade-off is worth it?

#4

dot squid wrote:

So you’ve just expanded the memory footprint of your app sharing those data among ALL game objects?
I don’t know about the OP’s use case, but my game is mainly widget based and there are only ever a handful on the screen at once. All of them require the same parameters so instead of duplicating logic that’s required between all the widgets (and violating DRY), I figured factoring them out and inheriting from it made more sense for me. Of course, my non visual objects game objects (network manager etc) do not need it, so I don’t inherit there.
You’re right, maybe this wouldn’t scale well for a high-velocity action game with hundreds of dudes running around.

Do you think that you gain more performance and this trade-off is worth it?
I’m not gaining performance, but I don’t care. Readability and reusability is easily worth the few bytes memory overhead, imo. You could argue that you shouldn’t even use classes because of increased memory footprint. I’ll optimize when I need to. Your milage may vary.

#5

So you’ve got something like as follows:

class BaseWidget
{
public:
    BaseWidget()
        : m_screenSize(CCDirector::sharedDirector()->getWinSize())
    {}

    virtual ~BaseWidget()
    {}

    CCSize GetScreenSize()
    {
        return m_screenSize;
    }

/*
    Some other methods
*/

private:
    CCSize m_screenSize;

/*
    Some other members
*/
};

Correct?

#6

More or less, yeah

#7

So when you need to know the size of the screen you do this:

void Widget::DoSomethingCool()
{
    DoSomethingWith( GetScreenSize() );
}

So, what’s the profit? Why not:

void Widget::DoSomethingCool()
{
    CCSize size = CCDirector::sharedDirector()->getWinSize();
    DoSomethingWith( size );
}
#8

I try to keep as much cocos calls abstracted away behind an interface as possible when I can (I never call CocosDenshion functions or change scenes with CCDirector directly for example), for this it’s kind of moot, you’re right, but I also got tired of seeing the same single line everywhere copy pasted when it was always just getting the size.

I have a lot of class functions that need to know the size, origin, and other things. Originally I had members at the object level that I would initialize so I didn’t have to call

CCSize size = CCDirector::sharedDirector()->getWinSize();

more than once, but it turned out that every object needed it, so I opted for that.

#9

Thanks guys. I was doing something like justin said and I am now simply calling it when I need it (since before I posted). I don’t feel that the overhead is necessary to tack it onto each sprite but at the same time I have been calling getVisibleSize many times in my code. I was hoping for some trick that would give me the best of both worlds. It is what it is though. Thanks again.