[stayscrisp]

(Cryptic), on 08 February 2011 - 03:39 PM, said:

stayscrisp, so there is only 1 right answer? Also would this question be for Experienced ? Senior ? Junior? Or you would not care, and just ask the candidate?

There is no exactly right answer, it's just to get you thinking and see what you come up with. A good answer would at least show that this is something you have thought about and have some knowledge of

[ghillieLEAD]

Quote

This was one of the things I thought no one would come up with

Since this week is over can you tell us what else there is that hasn't been mentioned yet?

[stayscrisp]

Apart from the already mentioned answers I would try to remove the virtual function as it would create a vtable pointer. ButchDean's answer would also be something that would make a good difference to the size and if the health value was something like 0-100 then a char would be better than an int. That's what I came up with

[ButchDean]

A point to note as well about deceptively space-saving techniques. View the following code using bit fields:

#include<iostream>
using namespace std;

struct STATUS
{
    unsigned visible  : 1;
    unsigned alive    : 1;
    unsigned animated : 1;
};

int main ()
{
    STATUS sts;

    cout << sizeof(sts) << endl;
 
    return 0;
}

It appears to be taking up only 3 bits, but when you run it what do you see?

[stayscrisp]

I'm guessing this is because the compiler will pad out the struct, yes? the struct will not necessarily always be the sum of the sizeof() its variables due to padding.

To further illustrate this, what about this:

struct STATUS
{
  unsigned visible  : 1;
  int i;
};

This post has been edited by stayscrisp: 11 February 2011 - 05:02 PM

[kruser]

stayscrisp, on 03 February 2011 - 05:46 PM, said:

Question 1

Look at this class declaration can you calculate how much memory an instance of this class would take up?
You may have to make some assumptions, please list them too. What improvements could you make so that this class could take up less memory?

class GameObject
{
public:
    GameObject();
    ~GameObject();

    virtual Mesh &GetMesh();
    float GetAnimationTime() const;

private:
    uint       m_health;
    Vector3    m_position;
    Vector3    m_velocity;
    bool       m_bVisible;
    Quaternion m_orientation;
    bool       m_bAlive;
    float      m_creationTime;
    bool       m_bAnimated;
}

I had to do some research for this, so I hope the information I looked at was correct. I also made a couple of assumptions. Thanks for this questions, should help keep my skills sharp as I have been in a non-programming position for about 1.5 years out of college, but thankfully I am moving into one in two weeks. Thanks again for taking the time to do this!

Spoiler

• uint: 4 bytes (short<=int<=long, I'll assume int = long_min)
  
• Vector3: I assume this consists of 3 floats, I believe floats are 4 bytes too, so 12 bytes * 2 Vector3s = 24 bytes
  
• bool (first): I'm not sure if variable ordering matters here with bools (i.e. if a char comes before an int it is allocated 4 bytes), I'll assume it is sizeof(Quaternion), so 16 bytes (see below)
  
• Quarternion: unsure how big this would be, I'll assume 4 floats for x,y,z,w for orientation, so 16 bytes
  
• bool (second): I will follow the reasoning for the above bool: 4 bytes
  
• float: 4 bytes
  
• bool (third): 1 byte
  
• Virtual function: 4 bytes

Total: 4+24+16++16+4+4+1+4 = 73 bytes

To improve this, order the variables so the booleans are at the bottom so they are allocated only 1 byte of space, which would reduce the size to 54 bytes.

[aragonsr]

The destructor isn't virtual, but the GetMesh() is..
Which means it's meant to be derived from... I see a possible memory leak if the destructor deallocates memory.
It already has a vtable because GetMesh has the virtual keyword.

You can replace the Quaternion with 3 Euler angles. This can be converted into a Quaternion if necessary at runtime.
Of course it may be easier to keep it as a Quaternion (for interpolation and gimble lock avoidance, etc.)
Someone already mentioned the bit flags. Good idea.

Correct me if I'm wrong, I don't know much about padding, but I believe the compiler will auto-pad the class if the variables aren't aligned to some bytes...
I don't know though..

Design-wise: You could start off by stating that this code is complete crap. I'm sure this would get them interested.

The cohesion is very low. Notice that the class groups "health" and "orientation" together in the same class...
They don't have anything to do with one another.
You could, oh I don't know..... factor out position, velocity, and orientation into say, some sort of component... Like a physics component...

Or, for runtime optimization: It looks like you could use Data Oriented Design...
This class is a perfect example of cache poisoning.. Or cache pollution... If we have an array of game objects, for example, we have, not only the good stuff in the cache lines, we have the useless crap too... We only want good stuff... When the integrator loops through each game object, it has useless crap it doesn't need in there, such as health... So where does it have to fetch the next position/velocity/etc. from? Main memory because the cache is all full of useless crap.

Create an array of velocities, an array of positions, an array of orientations... So when the integrator loops through these arrays and updates them all,
the next position (or whatever) will will be in the cache already.. It's locality of reference will be good.

Data oriented design will, not only be faster, it'll decrease the footprint of all the game objects in the game because less padding will be used per game object... right?
I dunno, I'm not 100% sure about the padding.