Class StarControl extends CD3DGame.

 


The game's always in one of these states. You'll see that most functions in the implementation contain a switch statement on the appstate that determines its behavior...just a good, clear way to divide up code and know what resources need to be loaded into memory.

   

//---------------------------------------------------------------------------
// Defines
//---------------------------------------------------------------------------
enum{ APPSTATE_BOOT, APPSTATE_SPLASH1, APPSTATE_SPLASH2, APPSTATE_MENU, APPSTATE_MELEE };

 

 

 

m_sprBlack and m_sprWhite are just little quads that I was going to use for fade effects. Adjusting gamma would be a little easier, maybe, but not all video cards support gamma in windowed mode.

   

//-----------------------------------------------------------------------------
// Class StarControl
//-----------------------------------------------------------------------------
class StarControl : public CD3DGame
{
protected:  // Graphics --------------------
    D3DXMATRIX          m_matProj, m_matView;
    dxBillboard2D       m_sprBlack, m_sprWhite;
    dxBillboard2D       m_sprLoading;

    dxLight             m_light;

 

 

 

 

 



The StarView class helps define the viewport. If we do the soccer idea we won't need it, but if we end up needing a finite playing field that wraps around, StarView handles the wrapping, zooming, and the conversion between viewport, full field and screen coordinates. The StarField class draws that parallax starfield you saw in the demo. It loads its parameters from the game.ini file.

   

protected:  // Melee -----------------------
    StarView            m_starView;
    StarField           m_starField;

 

 

 

INI readers for game and network settings, and the current and previous appstates...

   

protected:  // Misc ------------------------
    dxIniReader         m_cfgGame;
    dxIniReader         m_cfgNetwork;

    DWORD               m_dwAppState;
    DWORD               m_dwAppStatePrev;

 

 

 

 

 

Here's the real meat of the game. Not much to talk about - although you'll see I haven't redefined RestoreDeviceObjects(). As long as we register all of our device objects, we won't need to.

   

protected:      
    // Base class redefines
    HRESULT HandleInput();
    HRESULT Update();
    HRESULT PreRender();
    HRESULT Render();
    HRESULT OneTimeInit();

    HRESULT InitGameObjects();
    HRESULT DeleteGameObjects();

    HRESULT FinalCleanup();

    HRESULT SetStateBlock();

 

 

 

 

 

 



PrepareState handles the loading and unloading of game resources. Take a quick look at what the implementatoin does. If you pass TRUE to the boolean param, it'll spawn off a thread to display a loading screen.

A TEX file is an image file format I wrote (inspired by Brian's) that just contains a sequence of uncompressed images. Since the game.dat file will eliminate clutter already, the format is pretty useless to us... In any case, the function just initializes a dxBillboard2D object from an image file, and then registers the object. dxBillboard2D is a pretty lousy class - it's not very efficient, and I load all the images myself when I could've just used DirectX functions and gotten many more filetypes. All it does is draw a textured quad, to scale, in screen coordinates. It'll work nicely for buttons and things, but for a particle system we need something much more efficient.

I think the part of the game we ought to try hardest to optimize is the particle system. Some particle effects can be easily overdone and look tacky, but for things like explosions and fire, you can get amazing effects using shitloads of particles.

   

    // Utility functions
    HRESULT PrepareState( DWORD, BOOL );

    HRESULT LoadBillboard2DFromTEX( dxBillboard2D*, UINT, UINT );
    HRESULT LoadBillboard2DFromTEX( dxBillboard2D*, LPSTR, UINT );
    HRESULT LoadBillboard2DFromTGA( dxBillboard2D*, UINT );
    HRESULT LoadBillboard2DFromTGA( dxBillboard2D*, LPSTR );