As I discover new improvements to C++, it encourages me to look for more of them. A couple of weeks ago, I was adding a new screen for space combat, and I found myself cutting & pasting code from the existing territory screen. Although I was eager to work on the new space combat screen, I ‘did the right long-term thing’ and started a small project to refactor the common code from several screens into a new shared base class that I could also use for the space combat screen. There were some constants at the top of each .cpp file that are sometimes used in various unique ways by each screen.

const f32 RATIO = 0.86602540378f; // sqrt(3) / 2
const f32 CELL_HEIGHT = 1800.f;
const f32 CELL_WIDTH = CELL_HEIGHT / RATIO;
const f32 FACTOR_X = CELL_WIDTH * 0.75f;
const f32 FACTOR_Y = CELL_HEIGHT;
const f32 SPACER = 0.98f;

Continue Reading

Today I came across something simple I though might be interesting to others.

bool Client_Globals::IsInitialReplicationComplete()
{
    m_mutex.Enter();
    const bool isComplete = m_isInitialReplicationSent && m_galaxyUpdates.empty();
    m_mutex.Leave();
    return isComplete;
}

I was reviewing some code changes for a check-in today, and I thought to myself, this function should really be const because it doesn’t modify anything in Client_Globals. I proceeded to add const, and was immediately reminded that Mutex::Enter/Leave was not marked const. I went and looked at my implementation of Mutex::Enter, and was reminded of course that I was modifying some things.

class Mutex
{
public:
    Mutex();
    ~Mutex();
	
    void Enter() const;
    void Leave() const;
    bool IsInMutex() const;
	
private:
    friend class Thread;
	
#if defined(_WIN32)
    CRITICAL_SECTION m_cs;
    DWORD m_currentThreadID;
#elif defined(__APPLE__) || defined(__linux__)
    pthread_mutex_t m_mutex;
    pthread_t m_currentThread;
#endif
    s32 m_currentEntryCount;
};

void Mutex::Enter()
{
    EnterCriticalSection(&m_cs);
    if (0 == m_currentEntryCount)
    {
        m_currentThreadID = GetCurrentThreadId();
    }
    ++m_currentEntryCount;
    assert(m_currentThreadID == GetCurrentThreadId());
}

After internally debating the …

Continue Reading

When I first started learning about perfect forwarding, I had a lot of trouble making the leap from academic descriptions of r-value references to usage patterns that would help me make my code faster and more robust. I experimented with code that used r-value references, and used the debugger to learn how they worked under the covers. This really helped me understand what was possible and allowed me to start using perfect forwarding in the game I’m currently working on. There were some misunderstandings I discovered along the way. I figured it might be useful for others that are just starting with perfect forwarding to talk about the usage patterns that have been useful for me. This is not an exhaustive list, it’s just what I’ve ended up using.

Cheaply moving an object

There are often times where I need to cheaply move an object. Sometimes the object has a …

Continue Reading

Some parts of my game have an isometric 2D view to them.  I decided to try using Direct2D to draw those parts of the game.  Under the covers, Direct2D uses Direct3D, and despite an extra layer, I figure it’s probably more efficient to do it this way because each object only has to draw 2 triangles instead of the 1,000s that each model includes.  In theory, this will allow me to draw more objects, or attain a higher frame rate on lower spec video hardware.  It’s also possible I’ve made the classic mistake of premature optimization, but I onto my adventure.

Initially I drew my objects in 3D in Blender, set up several carefully placed cameras around my objects at various angles, save the render output, and carefully translate various locations on the object.  Since the ground presented to the user looks square, I also needed to distort the object …

Continue Reading

Continue Reading