I love console applications. They give you the good old DOS feeling and I’m a nostalgic guy. Now while developing a DirectX application I found it more useful to use a GUI frontend with Microsoft's shader compiler fxc.exe, the compiler which ships with the DirectX SDK. And since I’m a good guy, I share it with you. I know that many developers love console applications like me and the handling and using of fxc is quite good. No complicated syntax, no complicated anything. But I also know that newbies in game programming would most probably prefer a GUI for this. I was trying to compile about 10 shaders yesterday evening and I was too lazy to type the filenames so I took the time to create a GUI app with C# so I could “click” me through.

The app might contain bugs. If you find some please drop me a note. It was created in short time and quick and dirty. It’s only intend was to help me compile some hlsl files without having to type that much.

How to use it: There is not much to say. To compile or preprocess your hlsl files follow these steps:

1. select input file in dialog
2. select target profile in output file section
3. select compile options in the options section
4. click compile and watch the debug output

All messages by fxc are written to the textbox on the bottom of the application. Note that output files will be written to the same directory where the input file resides, not to the application directory.

As I said, I developed the GUI using C# and instead of making a click-once application I thought it would be a good idea of using InstallShield Limited Edition project which ships with VS 2010. Sorry for that but I haven’t used it yet and wanted to see how it feels :)

You will need at least .NET framework 2.0 and DirectX redist runtime installed on your system. Those components are not included with the installer.

setup.exe (1.56 mb)

  No this is not a new code language in Visual Studio 2012 but our new game engine. After endless attempts of finishing an engine (or what is usually called to be one) I started a 2d game project lately and stopped due to the lack of time (sadly). Now while working on a commercial project for a friend of mine I put my work and much of additional effort and formed D+ which is a complete game engine and should be the follow up (it’s not really a successor) to the blueEngine which was started some years ago and never finished.

I won’t pop up here with ground-breaking features since D+ will not be available for public. If you are looking for good game engines try Irrlicht or similar projects. D+ is a framework just for me and DTI Entertainment (my branch of game development).

Why do I post this? Because soon some games will follow up.

To make on thing clear. I’m realistic and I know I’m not a John Carmack and I will never be. I won’t make advertisement on this blog about great games which in fact will never be released. I’m someone who has some ideas and thinks they will be entertaining. Why did I develop D+ instead of using Irrlicht or something which already exists? I could have used Irrlicht instead but 1. I wanted to develop my own game engine (again the emphasis is not graphic engine but game engine) and 2. Irrlicht did not meet my needs.

Enough talking now let’s get some engine details:

• engine written in C++ using DirectX 9.0c
• completely scripted using LUA as script system
• shader driven engine using HLSL
• shader library contains predefined materials and effects like normal mapping, parallax mapping, specular mapping etc.
• particle engine with predefined effects like smoke, rain, blood, snow, sparks etc.
• sound engine with positional sound (3d positioning) using XACT and DirectSound
• basic path finding algorithms using A* path finding
• static and dynamic geometry using destruction models
• skinned mesh models
• real time physics using Newton Game Dynamics
• currently using Microsoft x file format for static level geometry, static models and skinned meshes
• frustum culling, occlusion culling and octree used for efficient level geometry rendering
• Dynamic LOD for all elements in game engine using progressive meshes

That are only the main features to mention. Please don’t start a discussion why we are using the x file format. It’s more than easy to implement, easy to use and with the already available progressive meshes it’s very performing. It saved us a lot of time at integration level and it works perfectly with Newton Game Dynamics which allows us to integrate it for level geometry and for all the objects.

I think we did a great job with this game engine. It’s a very nice framework to work with and the test stages showed us that with few lines of code we were able to directly start developing a game. To avoid the mistakes made when developing the blueEngine (which was in fact more an API wrapper of DirectX functions, not really what is called a game engine) the intension this time was to build something which allows the developer to do what he is intented to do. To code his game. Not to try messing with different Draw calls. We used the technique of dynamic DLL binding described here which means that maybe this game engine could make it as a stand alone product and of course will be extended with a DirectX 10 Or DirectX 11 render interface and/or additional features.

That’s enough for now. As soon as I have some time I will follow up with some screenshots and videos to show what we have. The main focus is to start with our first game project so this has of course priority. Thanks for reading this.

If you are a game developer and need a very powerful physics engine why not choose Newton? Newton Game Dynamics is a very scalable real time physics engine capable of most of today's must-haves for games. I started playing with Newton Game Dynamics while I was developing the blueEngine in early G-Productions days. It’s no secret that I started to develop a game engine again. This time a full shader driven engine but back to the topic.

I want to point out that I did not develop the source myself. Credits go to the team who released the Newton Game Dynamics SDK. I simply changed it to work with the DirectX objects so users have some help when integrating Newton into their DirectX game engine. Most of the code found here was taken directly from the NewtonSDK samples or from the DirectX SDK samples.

In this post we will learn how to use Newton with DirectX mesh files. You will see how easy it is to integrate Newton with a DirectX based game. I assume you are already familiar with C++, DirectX and have a basic knowledge how to use a compiler. If you don’t already have go and download the latest Newton version at Newton Game Dynamics. At the time this post was written the latest version was 2.07. I will still use the version 1.53 but the code is the same and we will talk about the differences. For simplicity reasons we will build upon the mesh tutorial shipped with the DirectX SDK.

1. Initialize Newton in our app

To initialize Newton Game Dynamics you only need four functions. After having set the correct include and library paths within your application let’s start. The complete code for the physics stuff can be found in the physics.cpp and physics.h of the NewtonTutorial1 project which you can download here. Let’s take a look what those functions do.

   1:  

   2: DWORD           g_dwNumBytes;

   3: // our pointer to the Newtonworld. Here is all the action :)

   4: NewtonWorld*    nWorld;

   5:  

   6: //-----------------------------------------------------------------------------

   7: // PhysicsMemAlloc feeds the Newtonworld with all the memory needed 

   8: // PhysicsMemFree releases the memory again. These functions can 

   9: // easily be changed to meet the needs of your own memory manager so 

  10: // your game engine can easily take control of this.

  11: //-----------------------------------------------------------------------------

  12: void* PhysicsMemAlloc( int sizeInBytes )

  13: {

  14:     g_dwNumBytes += sizeInBytes;

  15:  

  16:     return malloc (sizeInBytes);

  17: }

  18:  

  19: void PhysicsMemFree( void *ptr, int sizeInBytes )

  20: {

  21:     g_dwNumBytes -= sizeInBytes;

  22:  

  23:     free (ptr);

  24: }

  25: //-----------------------------------------------------------------------------

  26: // InitPhysics is our main entry point. If we want physics we have 

  27: // to call the the function NewtonCreate. As parameters the memory 

  28: // allocation/deallocation methods are accepted. We also need to tell 

  29: // Newton how "big" our world is so the function accepts as parameters 

  30: // the bounding box of our world 

  31: //-----------------------------------------------------------------------------

  32: HRESULT InitPhysics(D3DXVECTOR3 vMin, D3DXVECTOR3 vMax)

  33: {

  34:     HRESULT hr= S_OK;

  35:  

  36:  

  37:     nWorld = NewtonCreate (PhysicsMemAlloc, PhysicsMemFree);

  38:  

  39:     NewtonSetWorldSize( nWorld, (float*)&vMin, (float*)&vMax );

  40:  

  41:     return hr;

  42: }

  43: //-----------------------------------------------------------------------------

  44: // Just release everything and destroy our physics world :(

  45: //-----------------------------------------------------------------------------

  46: void CleanUpPhysics()

  47: {

  48:     NewtonDestroyAllBodies( nWorld );

  49:     

  50:     NewtonDestroy (nWorld);

  51: }

As you can see the whole magic is within InitPhysics and CleanUpPhysics. The piece of code should be self-explanatory so I won’t go into detail. If you have questions please refer to the samples shipped with the NewtonSDK. Most of the code is explained there in detail.

2. Create a simple mesh

Now that we know how to set up our physics world let’s start with adding some action to our scene. Take a look at the class CD3DXMesh. This is a simple mesh class which creates box, sphere or cylinder meshes with the D3DX library. We will use this for starting. Let’s take a look into the method CD3DXMesh->Init

   1: if( m_type == BOX )

   2: {

   3:     hr = D3DXCreateBox(g_pd3dDevice, m_vecSize.x, 

   4:                                     m_vecSize.y, 

   5:                                     m_vecSize.z, 

   6:                                     &pMeshSys, NULL);

   7: }

   8: else if( m_type == SPHERE )

   9: {

  10:     hr = D3DXCreateSphere( g_pd3dDevice, 

  11:                             m_vecSize.x,

  12:                             50, 50,

  13:                             &pMeshSys, NULL);

  14: }

  15: else if( m_type == CYLINDER )

  16: {

  17:     hr = D3DXCreateCylinder( g_pd3dDevice, 

  18:                             m_vecSize.x, 

  19:                             m_vecSize.z, 

  20:                             m_vecSize.y, 

  21:                             50, 50, 

  22:                             &pMeshSys, NULL);

  23: }

  24: else

  25:     return E_FAIL;

As you can see depending on the parameter we are creating our desired mesh and saving it. The method Init does some cloning of the mesh to get it into the right format for texturing. Now where is all the physics? Here is the method in our file physics.cpp.

   1: HRESULT CreatePhysicsBody( CD3DXMesh* pMesh )

   2: {

   3:     NewtonCollision*     collision;

   4:     NewtonBody*            body;

   5:     D3DXVECTOR3            vSize;

   6:  

   7:     vSize = pMesh->GetSize();

   8:  

   9:     switch( pMesh->GetMeshType())

  10:     {

  11:     case BOX:

  12:         collision = NewtonCreateBox( nWorld, 

  13:                                     vSize.x, 

  14:                                     vSize.y, 

  15:                                     vSize.z, 

  16:                                     NULL );

  17:         body = CreateRigidBody( pMesh, collision );

  18:         break;

  19:     case SPHERE:

  20:         collision = NewtonCreateSphere( nWorld, 

  21:                                         vSize.x, 

  22:                                         vSize.x, 

  23:                                         vSize.x, 

  24:                                         NULL );

  25:         body = CreateRigidBody( pMesh, collision);

  26:         break;

  27:     default:

  28:         break;

  29:     };

  30:  

  31:     NewtonReleaseCollision( nWorld, collision );

  32:  

  33:     return S_OK;

  34: }

After successfully creating a mesh and applying the physics properties we call this method so Newton Game Dynamics is able to do something useful with the data provided. Watch the lines 9-29. They are nearly identical with our DirectX function above for creating the graphical object. You see how easy it is? NewtonCreateSphere and NewtonCreateBox are methods of the Newton Game Dynamics library which create the collision shape of the desired body. Of course same sizes should be used like the graphical object so that it looks realistic.

The method CreateRigidBody is the important call in this code. Let’s take a look what it does:

   1: NewtonBody*    CreateRigidBody( CD3DXMesh* pObject, NewtonCollision* collision )

   2: {

   3:     D3DXVECTOR3 minBox;

   4:     D3DXVECTOR3 maxBox;

   5:     D3DXVECTOR3 origin;

   6:     D3DXVECTOR3 inertia;

   7:     NewtonBody* body;

   8:     float mass;

   9:  

  10:     mass = pObject->GetMass();

  11:  

  12:     body = NewtonCreateBody (nWorld, collision);

  13:  

  14:     NewtonBodySetDestructorCallback (body, PhysicsBodyDestructor);

  15:  

  16:     NewtonBodySetUserData (body, pObject);

  17:  

  18:     D3DXMATRIX matrix = pObject->GetMatrix();

  19:     NewtonBodySetMatrix (body, (float*)&matrix);

  20:  

  21:     NewtonConvexCollisionCalculateInertialMatrix (collision, 

  22:                                 (float*)&inertia, (float*)&origin);    

  23:  

  24:     NewtonBodySetMassMatrix (body, mass, mass * inertia.x, 

  25:                                             mass * inertia.y, 

  26:                                             mass * inertia.z);

  27:  

  28:     NewtonBodySetCentreOfMass (body, (float*)&origin);

  29:  

  30:     NewtonBodySetForceAndTorqueCallback (body, PhysicsApplyForceAndTorque);

  31:  

  32:     NewtonBodySetTransformCallback (body, PhysicsSetTransform);

  33:  

  34:     return body;

  35: }

Very simple. It creates the rigid body in physics world and sets the various parameters like mass, matrices and callbacks. As you see there are three callbacks set. These callbacks control the behavior of the physic bodies. Let’s take a closer look.

PhysicsBodyDestructor:

   1: void PhysicsBodyDestructor ( const NewtonBody* body )

   2: {

   3:     CD3DXMesh* primitive;

   4:  

   5:     primitive = (CD3DXMesh*) NewtonBodyGetUserData (body);

   6:     SAFE_DELETE( primitive );

   7: }

This method is called to destroy our object.

PhysicsSetTransform:

   1: void PhysicsSetTransform( const NewtonBody* body, const float* matrix )

   2: {

   3:     CD3DXMesh* primitive;

   4:     D3DXMATRIX mat;

   5:     memcpy(mat.m, matrix, sizeof(float)*16);

   6:  

   7:     // get the graphic object form the rigid body

   8:     primitive = (CD3DXMesh*) NewtonBodyGetUserData (body);

   9:  

  10:     // set the transformation matrix for this rigid body

  11:     primitive->SetMatrix ( mat );

  12: }

This method is called every time to set the new matrix to our models. Every time the matrix of the body changes (transformation, translation etc.) this function is called to update the matrix so that the graphical part knows what happened and is able to render the transformed graphical object.

PhysicsApplyForceAndTorque

   1: void PhysicsApplyForceAndTorque (const NewtonBody* body)

   2: {

   3:     float mass;

   4:     float Ixx;

   5:     float Iyy;

   6:     float Izz;

   7:  

   8:     NewtonBodyGetMassMatrix (body, &mass, &Ixx, &Iyy, &Izz);

   9:     D3DXVECTOR3 force (0.0f, mass * NEWTON_GRAVITY, 0.0f);

  10:     NewtonBodySetForce (body, (float*)&force);

  11: }

This method simply applies gravity force to the rigid body.

Note: All the methods of the Newton Game Dynamics library accept float pointers for accessing data. If you use your own vector or matrix class make sure you include a float* casting to your vector/matrix class. If you store your members in an array of floats for example float m[3] you could simply pass &vec.m[0] to Newton. If you use the DirectX D3DXVECTOR3 and/or D3DXMATRIX classes make sure you cast the parameter with a float pointer like

   1: D3DXVECTOR3 vecForce;

   2: NewtonBodySetForce( body, (float*)&vecForce);

For detailed reference refer to the DirectX SDK documentation.

That’s all. We simply have to do a call to update the physics world with the current passed time and voila we have some action. What did we do here? We just created with DirectX internal functions some basic meshes to render and create rigid bodies out of them to simulate physics. The result should look like this:

3. Using DirectX mesh for level geometry

What did we learn so far? We learned how easily it is to integrate Newton to any type of DirectX based game engine and we learned how easy it is to create rigid bodies with simple primitives using the DirectX D3DX library. Now we want to go a step further. The DirectX mesh file (x mesh) is maybe not the preferred mesh format a developer would choose but it’s easy to handle since D3DX ships with nearly any helper method you could imagine of, what makes work easier. For this example we will choose the x mesh as level geometry and add some more complex meshes to the scene to see if Newton Game Dynamics can handle this.

For this tutorial a new mesh class is used to load meshes from files. For now we will take a look what happens while initializing the mesh object:

   1: m_iNumTriangles = m_pMesh->GetNumFaces();

   2: m_iNumVertices = m_pMesh->GetNumVertices();

   3:  

   4: m_pVerts = new D3DXVECTOR3[m_iNumVertices * sizeof(D3DXVECTOR3)];

   5: m_pIndices = new WORD[m_iNumTriangles * sizeof(WORD) * 3];

   6:  

   7: MeshVertex2* pVertexBuffer = NULL;

   8: hr = m_pMesh->LockVertexBuffer( 0, (void**) &pVertexBuffer );

   9: if( FAILED(hr) )

  10:     return E_FAIL;

  11:  

  12: for( int iCol = 0; iCol < m_iNumVertices; iCol+=4)

  13: {

  14:     m_pVerts[iCol] = pVertexBuffer->vPos;

  15:        pVertexBuffer++;

  16:        m_pVerts[iCol+1] = pVertexBuffer->vPos;

  17:        pVertexBuffer++;

  18:        m_pVerts[iCol+2] = pVertexBuffer->vPos;

  19:        pVertexBuffer++;

  20:        m_pVerts[iCol+3] = pVertexBuffer->vPos;

  21:        pVertexBuffer++;

  22: }

  23: hr = m_pMesh->UnlockVertexBuffer();

  24: if( FAILED(hr) )

  25:     return E_FAIL;

  26:  

  27: WORD* pIndexBuffer=NULL;

  28: hr = m_pMesh->LockIndexBuffer( D3DLOCK_READONLY , (void**)&pIndexBuffer ); 

  29: if( FAILED( hr ))

  30:     return E_FAIL;

  31:  

  32: for( int i = 0; i < m_iNumTriangles*3; i++)

  33: {

  34:     m_pIndices[i] = pIndexBuffer[i];

  35: }

  36: hr = m_pMesh->UnlockIndexBuffer();

  37: if( FAILED( hr ))

  38:     return E_FAIL;

This should be nothing new for you. After loading your mesh and doing things with it you want to do like optimization and stuff simply load the vertices and indices separate into buffers. We are doing this only once in our example after loading the mesh from file and preparing it for the application. Therefore it is no problem to lock the vertex- and index buffer of the mesh since it’s only done once. Why did we do the things above? you should ask now. Well simply because we will pass this data to Newton Game Dynamics. You will see that this work will pay off later.

Now we are loading a big mesh file (the castle model of the example was taken from the samples of DelEd editor) and want it to behave as our static geometry. Why this? First of all it’s good to go this way since we can now simulate exact collisions with all other objects of the game. Second is we can write a player controller and control it via physics (an example of a character controller ships with Newton Game Dynamics) what means that we don’t have to calculate collisions between player and level geometry separately but let Newton Game Dynamics do this for us. And the third reason is simply because we want to be cool and implement it that way to point out how important the two reasons above are ;)

Now that we loaded the our big mesh we have to tell Newton Game Dynamics to use our vertices and indices to build our world. This is done in the method CreateLevelCollision

   1: HRESULT    CreateLevelCollision( D3DXVECTOR3* vVertexArray, int vertcount, 

   2:                         WORD* vIndexArray, int indexcount, D3DXMATRIX matLevel )

   3: {

   4:     HRESULT hr=S_OK;

   5:     NewtonCollision*    collision;

   6:     D3DXVECTOR3            vArray[3];

   7:     NewtonBody*         m_levelBody;

   8:     int                 m_nLevelID;

   9:  

  10:     collision = NewtonCreateTreeCollision( nWorld, 0);

  11:  

  12:     NewtonTreeCollisionBeginBuild( collision );

  13:  

  14:     for( int i = 0; i < indexcount; i+=3)

  15:     {

  16:         WORD d1 = vIndexArray[i];

  17:         WORD d2 = vIndexArray[i+1];

  18:         WORD d3 = vIndexArray[i+2];

  19:         

  20:         vArray[0] = vVertexArray[d1];

  21:         vArray[1] = vVertexArray[d2];

  22:         vArray[2] = vVertexArray[d3];

  23:         

  24:         D3DXVECTOR3 e0 = vArray[1] - vArray[0];

  25:         D3DXVECTOR3 e1 = vArray[2] - vArray[0];    

  26:         

  27:         NewtonTreeCollisionAddFace( collision, 

  28:                                         3, 

  29:                                         (float*)vArray[0], 

  30:                                         sizeof(D3DXVECTOR3), 

  31:                                         0);

  32:     }

  33:  

  34:     NewtonTreeCollisionEndBuild( collision, 1);

  35:     m_levelBody = NewtonCreateBody( nWorld, collision);

  36:     

  37:     NewtonReleaseCollision ( nWorld, collision);

  38:     NewtonBodySetMatrix( m_levelBody, matLevel);

  39:  

  40:     D3DXVECTOR3 boxP0;

  41:     D3DXVECTOR3 boxP1;

  42:     NewtonCollisionCalculateAABB (collision, matLevel, &boxP0.x, &boxP1.x);

  43:  

  44:     boxP0.x -= 10.0f;

  45:     boxP0.y -= 10.0f;

  46:     boxP0.z -= 10.0f;

  47:     boxP1.x += 10.0f;

  48:     boxP1.y += 100.0f;

  49:     boxP1.z += 10.0f;

  50:  

  51:     // if this mesh is used for level geometry we could increase the 

  52:     // NewtonWorld size by the bounding box of the level geometry. Above some 

  53:     // padding was added. I think a good idea is to add more padding to y since 

  54:     // we might be "outdoor" and might want to let some boxes fall down ;)

  55:     NewtonSetWorldSize ( nWorld, (float*)&boxP0, (float*)&boxP1);

  56:     

  57:     return hr;

  58: }

Wow damn nice function. This is the bread and butter of our game. In line 10 you see that we build an empty collision object. After that we tell Newton that we want to add the polygons to the collision tree. So now we loop through our vertices and the the faces via NewtonTreeCollisionAddFace. On finish we call NewtonTreeCollisionEndBuild, note the second parameter. We passed 1 here telling Newton to optimize our collision tree. After passing our complete mesh geometry to Newton we create the body set the matrix and calculate the bounding box. We did that in order to re-set the world size. Note that we added some padding to the world to make sure even objects at borders behave as they should. That’s all, no callbacks are needed this time since this is our (static) world and we don’t want it to move around ;)

We should test this stuff we did until now but let’s go a step further. Do you have only boxes, spheres and cylinders in your game? No you don’t. I bet 80% of the meshes are of complex geometry. What if you want to have collisions with the real shape they are rendered? Newton Game Dynamics helps us out. Take a look here:

   1: HRESULT CreateComplexPhysicsBody( CMesh *pMesh )

   2: {

   3:     HRESULT hr = S_OK;

   4:     NewtonCollision*     collision;

   5:     NewtonBody*            body;

   6:     float                 Ixx, Iyy, Izz;

   7:     D3DXMATRIX            mat;

   8:  

   9:     mat = pMesh->GetMatrix();

  10:  

  11:     collision = NewtonCreateConvexHull (nWorld, 

  12:                                 pMesh->GetNumVertices(), 

  13:                                 (float*)pMesh->GetVerts(), 

  14:                                 pMesh->GetVertexSize(), 

  15:                                 NULL);

  16:     body = CreateRigidBody( pMesh, collision );

  17:  

  18:     NewtonReleaseCollision( nWorld, collision );

  19:  

  20:     return hr;

  21: }

Sick. Just pass your mesh object to this method. What happens then? Remember the vertex and index buffers which we calculated when initializing the mesh and which we used after that to build level geometry? Just use them here once again to pass the detailed geometry of your graphical object so Newton can build the collision geometry out of it. The method NewtonCreateConvexHull does all the work for us. After having build the collision geometry we continue to create the body like in the examples above where all the callbacks and properties are set. Nothing new here.

So what will the result be? Let’s watch the video:

As you can see it’s quite easy to implement Newton Game Dynamics into your game engine project. The good thing is that Newton accepts the matrix and vertex parameters in major row order what makes it possible for OpenGL and DirectX game engine to use Newton Game Dynamics. There is also a documentation available which ships with the download and there are a couple of great samples and tutorials which are included with the SDK. The forums at www.newtondynamics.com is visited very frequently and should be the place to start. The website has also a new wiki which makes the package complete. I can recommend Newton Game Dynamics. The integration of Newton in any engine is more than easy and developers reach fast and very good results and most important of all: you don’t loose too much time. We could start a discussion whether to use Newton methods for computing a bounding box or use the DirectX integrated functions but that's more than philosophic since the result (in my tests) was the same.

But that’s not all. The Newton Game Dynamics SDK ships with some great methods for ragdoll and more. Check out there website for a full feature list. Thanks for reading this.

Please note: As stated above the source on how to use Newton was taken mainly from the samples which ship with the NewtonSDK. Also the mesh classes contain portions of the DirectX SDK. I just put these together to work. The code is of course not best practice but good enough for the examples above.

Downloads

NewtonTutorial1.zip (4,71 mb)

NewtonTutorial2.zip (5,47 mb)

Some things never change, and as a passionate developer my big love are still games. No not playing them, but developing them. I was cleaning up my harddrive today (I should do this more often) and found a very old project I wanted to start some years ago with my class mates. We did some basic project management and ended up with a design document for a game which we found very cool. So some of the graphic artists put together this very basic screens for a teaser which I’m releasing here. OK the younger guys reading this blog will now be laughing because they are used to Quake 15, Doom 21 and Duke Nukem Never graphics and this is a simple but cool 2d game but that’s ok. Try to develop your own game and you will see what I’m talking about.

Now I found a very basic framework for this game and while browsing the project folder the feeling of then came up in me and I decided that it’s time to get this finished. I will put things together the next days and try to see what I have, what I need and what I’ll get and will try to finish this. Are you excited in a 2d game of an old-school game developer who will use Dev-Cpp and DirectX as API for the complete game? Then watch the video below and tell me what you think.

You are a passionated game developer, graphic artist, sound specialist or simply love contributing anything to a game then contact me. It will be a pleasure to get this done…

[mediaplayer:urban.flv]

June 22nd 2004 the website G-Productions was launched. This site was dedicated to my very own afford to create a game engine using DirectX. I was not a friend of the Visual Studio that time since I could not afford this (it was not that cheap that time), so an alternative compiler had to be found. Soon I stepped over Dev-Cpp. This was a very complete and full functional IDE which uses the MinGW compiler. Cool was my first thought, but the first problems were soon knocking on the door. Those of you who ever tried to use DirectX with the MinGW compiler know what I'm talking about. A bunch of compiler errors say hello if you include a DirectX header file.

Teaching a compiler the Microsoft way

Searching the www I could not find any way how to use the DirectX SDK with the MinGW compiler. A DirectX DevPak was available but it included only the DirectX Graphics component of SDK and it was not very complete (imagine the D3DX functions library). On several forums and bb's people already had posted problems with using MinGW and DirectX SDK (that time people referred to the DX SDK 8.1). Soon I realized that there was the need of an adequate solution. Download the DX SDK and let's get to work I thought and so I did. After downloading the DirectX SDK 9.0 I started reading through the compiler tools documentation. After a short time I got all the DirectX Graphics issues fixed and I had a stable release of the graphics library of the SDK. Most important thing was, that it was full usable and full functional with Dev-Cpp.

Next step: DirectInput

Next task on my list was the DirectInput library. Some fixes here some fixes there and converting the library and here you are with a complete DirectInput library for MinGW. Easy I thought, let's get to the sound stuff.

The audience is listening

That time for audio the DX SDK provided the DirectSound and DirectMusic library. While DirectMusic was easy to convert, DirectSound made some problems because of the use of some defines which were not so easy to work with.

DirectShow

The biggest problem when working with the MinGW compiler tools is also the best feature. The MinGW compiler is an ANSII compliant compiler and allows only ANSII compliant C++. The complete DX SDK contains partial non-ANSII-compliant code. That was the issue most people complaint about. Within the DXSDK a script language (IDL) was used what was also difficult to change that MinGW could work with it. Most work with the DXSDK was changing some parts of the header files, mainly fixing scoping problems and/or rewriting the IDL parts and the header files worked very well with MinGW. But what I faced with the DirectShow part was terrible. Let's say I needed one month of work to make DirectX Graphics, DirectSound, DirectMusic, DirectInput and DirectPlay work with MinGW I needed at least 3 more months to convert the DirectShow stuff. My intention was to release the most complete DirectX.DevPak available so people could use it for their applications. My intention was also that my DevPak should compile out-of-the-box. So I didn't loose a word on my DevPak until the DirectShow part was also converted. The problem was that most tutorials and samples used the BaseClasses, a static library which wrapped many things up and allowed the developer to render videos on textures or for DirectDraw on surfaces. These BaseClasses library was nearly impossible to change for MinGW. Finally with some tweaks DirectShow was usable with MinGW and I included the samples and provided it for download.

Past and future

Four years I spent more time on keeping updated this DirectX.DevPak, which was originally designed to help me and my team developing the blueEngine, than on working on my own game engine (Microsoft loved me so much that they began releasing a monthly update on the DX 9.0 SDK). The DirectX.DevPak became an own single project that took most of my time.

Since the release of the Visual Studio Express Editions especially the XNA Express version I began asking myself if it would make any sense of continue the work on the DevPak and release any further updates. The reason why I started to work with Dev-Cpp and the MinGW compiler was that I didn't have the money to buy a Visual Studio C++ 6.0 version. Now Microsoft introduced the Visual Studio Express editions giving such a great development environment away for free. Why should someone still need an updated DirectX.DevPak? I downloaded the DirectX SDK March 2008 and tried to look how much work it would be to convert it. So many changes, monthly updates, some functions were dropped others were introduced...

There definitely won't be be any more updates on the DirectX.DevPak. The last release is available here. The changes on the DXSDK are too many. I would have to convert the complete DXSDK March 2008 and I simply don't have the time for this. It was great to work on this DevPak you can learn so much about C++ when having to work with compiler and linker issues, different static library formats. I think this also improved the way I'm programming in C++ and of course influenced the way I think about open-source projects a standardized static and dynamic library format etc.

DirectX.DevPak versions here available

Download the DevPak here

So what is that title about? What is intelligent DLL design? When designing a game engine you have to take care of so many things. You have to think of inertial delay times, transmission delays, overheads, buffers and so much more....

Usually you design and develop your game engine, you test it and as soon as it's validated you compile it as a dll. This is in general a good idea because of so much advantages of a dll. Think of the faster cycle times, encapsulation, better design (we will change it to great design in this post) and so much more.

To use the game engine the game programmer would include the main header file of the game engine somewhere in his code and link to the static library when compiling the code. In Visual Basic you call this early binding. In C++ you call it binding on compile time.

I will show you here a more elegant and more efficient way to design a DLL. Instead of providing a "simple" source code for download, you can download the blueTec engine. This is a small 2d mini game engine which I've published on my project site G-Productions. This package contains some examples which will show you the implementation of this engine design. You can download the blueTec Engine directly at the end of this article. You need Dev-Cpp to compile this correctly. 

What is a game engine? In this article when we talk about a game engine we don't only mean the render stuff. A game engine does not only exist of those fun-making render calls and renderstates but also of those less-fun-making stuff like the sound and music api, like the script engine and the network module.... So if we talk about a game engine in this article we talk about all the stuff that makes the visual, the audio, the network game and much more. For simplicity we will use here pseudo code but you can download a complete working project with this article.

Imagine you have finished the development of your game engine and you want to provide it to a team of developers who will use it as base of game. Usually you would now create a DLL (dynamic link library) project, copy your header and source files into this and compile with a pre-processor directive like #define GAME_API __declspec(dllexport). What's wrong with this operation? Nothing! In fact this is ok for many projects but there are more intelligent ways.

Assuming your main game class of your game engine looks like this:

   1: class CEngine 

   2: {

   3: private:

   4:     // private stuff like the IDirect3DDevice9 or the OpenGL stuff go in here

   5: protected:

   6:     HRESULT    InitGraphics();

   7:     HRESULT    InitAudio();

   8:     HRESULT    InitInput();

   9:  

  10:     HRESULT    Destroy();

  11: public:

  12:     CEngine ( HINSTANCE );

  13:     ~CEngine ();

  14:  

  15:     HRESULT    InitEngine();

  16:     HRESULT    ShutdownEngine();

  17:  

  18:     HRESULT    MoveFrame( float );

  19:     HRESULT    BeginRender();

  20:     HRESULT    RenderFrame();

  21:     HRESULT    EndRender();

  22:  

  23:     HRESULT    PlaySound();

  24:     HRESULT    PlayMusic();

  25: };

Listing 1: the main engine class from the dll 

This class is the main exported class of your game engine and would usually look in line 1 like this:

class GAME_API CEngine

what tells the compiler that this class can be used from outside. You would now have to compile the dll (a static library is generated automatically which the developer team will use it to link to it) and provide the complete code/project to the developer team. Now imagine you would detect a bug or optimize some functions within your game engine or the developer team would detect a bug? You would have to fix the bug and the developer team would not be able to continue the work on that point where the bug occured. They would have to find a way around. Then you would have to send again the whole package and the team would have to replace the complete game engine again, all the header and source files, recompile with the new static library provided with the dll etc.

And here comes the cool thing. With our method these steps aren't necessary any more. So let's get to work guys.

1) Create a static library project

First of all create a new static library project like shown in the figure on the right. This static library is the base of our DLL design.

In Dev-Cpp the static libraries have the *.a extension. In Visual Studio or other compilers the static libraries have a *.lib extension. This is nearly the same, except of one point. You will be able to use Visual Studio generated static libraries with Dev-Cpp (in fact the MinGW compiler will use them since Dev-Cpp is only the IDE) but only if they are not so called short-symbol static libs.

Now after creating the project add two new header files like in the picture on the left and one source file. We will now take a closer look what the files contain. Let's start with the header file gameEngineDevice.h

   1: class CGameEngineDevice

   2: {

   3: protected:

   4:     HINSTANCE   m_hDll;

   5:     int         m_iWidth;

   6:     int         m_iHeight;

   7:     int         m_iBpp;

   8:     bool        m_bWindowed;

   9:     HWND        m_hWnd;

  10:  

  11: public:

  12:     CGameEngineDevice(){};

  13:     virtual ~CGameEngineDevice() = 0;

  14:     virtual HRESULT         InitEngine() = 0;

  15:     virtual HRESULT         ShutdownEngine() = 0;

  16:  

  17:     virtual HRESULT         MoveFrame( float ) = 0;

  18:     virtual HRESULT         BeginRender() = 0;

  19:     virtual HRESULT         RenderFrame() = 0;

  20:     virtual HRESULT         EndRender() = 0;

  21:  

  22:     virtual HRESULT         PlaySound() = 0;

  23:     virtual HRESULT         PlayMusic() = 0;

  24: };

  25:  

  26: typedef class CGameEngineDevice *LPENGINEDEVICE;

  27:  

  28: extern "C"

  29: {

  30:     HRESULT CreateEngineDevice( HINSTANCE hDll, CGameEngineDevice **pInterface );

  31:     typedef HRESULT (*CREATEENGINEDEVICE)(HINSTANCE hDll, CGameEngineDevice **pInterface );

  32:  

  33:     HRESULT RelaseEngineDevice( CGameEngineDevice **pInterface );

  34:     typedef HRESULT (*RELEASEENGINEDEVICE)(CGameEngineDevice **pInterface );

  35: }

Listing 2: class CGameEngineDevice from the file gameEngineDevice.h

What did we do here? Compare the class CGameEngineDevice with the original game engine class CGameEngine. What do you see? Yes you are right. All the public functions in our class CGameEngine are defined virtual. Below in line 28 we see an implementation of helper functions which we will need later.

Let's go to the file gameEngine.h. Here is the content:

   1: #include "gameEngineDevice.h"

   2:  

   3: class CGameEngine

   4: {

   5: private:

   6:     CGameEngineDevice    *m_pDevice;

   7:     HINSTANCE            m_hInst;

   8:     HMODULE              m_hDll;

   9: public:

  10:     CGameEngine( HINSTANCE hInst );

  11:     ~CGameEngine( void );

  12:     

  13:     void                Clear();

  14:  

  15:     HRESULT             CreateDevice( void );

  16:     LPENGINEDEVICE      GetDevice( void ) { return m_pDevice; }

  17:     HINSTANCE           GetModule( void ) { return m_hDll; }

  18:     void                Release( void );

  19: };

  20:  

  21: typedef class CGameEngine *LPGAME;

Listing 3: class CGameEngine from the file gameEngine.h

and here is a snapshot only of the most important function of the file gameEngine.cpp

   1: HRESULT CGameEngine::CreateDevice()

   2: {

   3:     HRESULT hr = S_OK;

   4:     char buffer[300];

   5:  

   6:     m_hDll = LoadLibraryEx("gameEngine.dll", NULL, 0);

   7:     if( !m_hDll )

   8:         return E_FAIL;

   9:  

  10:     CREATEENGINEDEVICE _CreateEngineDevice = 0;

  11:  

  12:     _CreateEngineDevice = (CREATEENGINEDEVICE)GetProcAddress( m_hDll, "CreateEngineDevice");

  13:     hr = _CreateEngineDevice( m_hDll, &m_pDevice );

  14:  

  15:     if( FAILED( hr ))

  16:     {

  17:         m_pDevice = NULL;

  18:         return E_FAIL;

  19:     }

  20:     return S_OK;

  21: }

Listing 4: code snippet from the file gameEngine.cpp

Wow, pretty much isn't it? Ok in short, the CreateDevice function is the bread and the butter of this project. LoadLibraryEx in line 6 loads the dynamic link library gameEngine.dll which will contain the game engine. In line 10 you see the the use of _CreateEngineDevice which was defined in the gameEngineDevice.h. The call of GetProcAddress retrieves the address of the exported function CreateEngineDevice from the specified dynamic-link library gameEngine.dll which was loaded before with the call LoadLibraryEx.

The static library project is finished. Save and compile to generate the static library file.

2. The DLL project

Now back to our dll project. The only thing you have to do here is to extend the main engine class CEngine. Take a look at listing 1 and replace the first line from class class CEngine to class CEngine : public CGameEngineDevice and to include the header file gameEngineDevice.h from our previously created static library project.

What did we do? The class CEngine inherits public from CGameEngineDevice. What does this mean for us? This means that all the functions which are declared virtual in the class CGameEngineDevice have to be implemented in the class CEngine.

One last thing is also to do. Remember the line 28 in listing 2. The extern "C" declaration? Where are those functions? Those have to be integrated within the dll so here we go with the code:

   1: extern "C"

   2: {

   3: HRESULT DLLIMPORT CreateEngineDevice( HINSTANCE hDll, CGameEngineDevice** pDevice )

   4: {

   5:     if( !*pDevice )

   6:     {

   7:         *pDevice = new CGameEngineDevice( hDll );

   8:         return S_OK;

   9:     }

  10:     return E_FAIL;

  11: }

  12:  

  13: HRESULT DLLIMPORT ReleaseEngineDevice( CGameEngineDevice** pDevice )

  14: {

  15:     if( !*pDevice )

  16:         return E_FAIL;

  17:  

  18:     delete *pDevice;

  19:     *pDevice = NULL;

  20:     return S_OK;

  21: }

  22: }

Listing 5: implementation of the wrapper functions for allowing the dynamic binding of the dll.

3. Using the dll in a game

How would you use the game engine in your game project?

1. include in your game project the file gameEngine.h of the static library project
2. define two new variables using the objects in our static library project (CGameEngine and CGameEngineDevice)
3. create an instance of CGameEngine and call the function CreateDevice() to create a valid game engine device
4. get a valid pointer into our CGameEngineDevice object using the call CGameEngine->GetDevice()

Here is the sample code:

   1: int WINAPI WinMain (HINSTANCE hThisInstance,

   2:                     HINSTANCE hPrevInstance,

   3:                     LPSTR lpszArgument,

   4:                     int nFunsterStil)

   5:  

   6: {

   7:     HWND hwnd;

   8:     MSG messages;

   9:     WNDCLASSEX wincl;

  10:  

  11:     // our objects from the static library project

  12:     CGameEngine           *m_pEngine;

  13:     CGameEngineDevice     *m_pEngineDevice;

  14:  

  15:     // window dependent stuff goes in here

  16:  

  17:     if (!RegisterClassEx (&wincl))

  18:         return 0;

  19:  

  20:     hwnd = CreateWindowEx ( 0, szClassName, "Windows App", /* window init stuff here */ );

  21:  

  22:     ShowWindow (hwnd, nFunsterStil);

  23:  

  24:     /* we need to save the instance and the window handle because we need them for the engine */

  25:     g_hInst = hThisInstance;

  26:     g_hwnd = hwnd;

  27:  

  28:     m_pEngine = new CGameEngine( g_hInst );

  29:  

  30:     // some simple error handling

  31:     if( !m_pEngine )

  32:         // error handling

  33:  

  34:     // now with calling the CreateDevice function the dll symbol is dynamicaly

  35:     // loaded so it's a real dynamic binding

  36:     if (FAILED( m_pEngine->CreateDevice()))

  37:         // error handling

  38:  

  39:     // the created device is passed over to our engine pointer in order to work with

  40:     m_pEngineDevice = m_pEngine->GetDevice();

  41:  

  42:     if( m_pEngineDevice == NULL )

  43:         // error handling

  44:  

  45:     if( FAILED( m_pEngineDevice->InitEngine() ))

  46:         // error handling

  47:  

  48:     /* ... message que here ... */

  49:     return 0;

  50: }

Listing 6: How to use the game engine in a game project

Just for fun

Open the dll using the tool Dependency Walker which you can find here. This tool scans Windows modules like dll's, exe files and ocx files and builds a hierarchical tree of the dependency. The tool shows also the exportable functions and entry points of the dll.

If you open our blueTec.dll with this tool you will notice only two available/exportable functions: CreateEngineDevice and ReleaseEngineDevice (look at the picture on the right). These are the functions which we have implemented within our dll and declared in our static library. Nothing more nothing less and that's all we need.

Other dll's like shown on the second picture which are compiled with the usual dll design are just exporting the complete class and provide entry points to every single method and property. Do you see the difference?

Resume

Why did we do all that above and why did the author confuse us more than necessary. Where are the benefits and advantages and why should someone go the way above?

Quiet easy. Imagine the problems mentioned at start of this article with bugs and stuff like that.

• This way is a real dynamic implementation. Looking at the code snippets we see that the real game engine class is referenced from the dll itself. The application just receives a pointer at runtime. You could develop and test your complete application without even owning the dll because it is referenced at runtime. Something which wouldn't be possible with the usual method.
• The greatest advantage is that in case of a change, an optimization and/or a bug fix you would recompile the dll and send only the compiled dll to the developer team. The team would replace only one file instead of having to replace many single header and source files and recompile the current milestone with the new created static library which ships with the dll. You safe so much time.
• Another great benefit is that you don't have to provide your very secret code because you only deliver the static library project and the compiled dll. With the traditional way you would have to provide the complete source of the dll project.
• Another very important advantage is that you could develop a game engine using completely the DirectX API and name it gameEngineDX.dll and provide it to a game development team. While the development team is full in progress to create a game using your game engine you could develop a second game engine using the OpenGL API (gameEngineOGL.dll). This game engine should also inherit from the class CGameEngineDevice. Now it would be for the development team very easy to switch between the two render API's and the best is that the team could develop the complete game using only one dll without owning the second and won't have to rewrite any code when receiving the second dll, since the definition of the main game engine class is the same and ignores which API is used. The development team doesn't even need to have the DirectX-SDK installed since the complete game engine code is already compiled and delivered within the dll.

These points are the most important I think and so this article is at the end now. I hope I could provide a "different" look at game engine design or just call it dll programming. There are more ways to design a dll but you should always have in mind that the result should not only be a fast, scalable and efficient dll at runtime but also while development since the most time you and your team will sit in front of the code and if you are able to safe some time for the game developer and make his work more efficient you should spend the time for a good design of your game engine ;)

Downloads:

blueTec_sdk.rar (515,53 kb)

In this article we will learn how to take screenshots using DirectX 9.0 I adapted this article from my tutorial on www.g-productions.net

It is quite easy to take screenshots from DirectX applications, you don't have to take care of too much things. So let's take a closer look.
What we need is a surface to save the image and we also need a function that saves the surface to file. Thanks to Microsoft the DirectX SDK ships with a function which does all the work for us.
Here are the necessary steps:

1. Specify a filename to save the screenshot to.
2. Create a surface which is capable of holding the screen data.
3. Get the screen data and write it to our surface
4. Save our surface to a file

1. Specify a filename to save the screenshot

Here we do only the necessary. Check if a filename exists or step over to the next filename. Here is the code:

   1: FILE* f;

   2: for(int i=0;i<999;i++)

   3: {    

   4:     // build the filename    

   5:     sprintf(filename, "screen%.3d.bmp", i);    

   6:     f = fopen(filename, "r");    

   7:     if( f == NULL)        

   8:         break;    

   9:     else        

  10:         fclose( f );

  11: }

2. Create a surface which is capable of holding the screen data

The only thing we need here is the method CreateOffscreenPlainSurface which awaits the following parameters:

• the screen size (x, y)
• the format of the surface to be created
• the memory in which the surface will be put and finaly
• the surface interface

The desired format could be something like D3DFMT_A8R8G8B8 and so I suggest you to use this format since it creates a 32 bit surface with an alpha channel and 8 bits per each channel.
We should define D3DPOOL_SCRATCH as the memory class which holds our surface, since our resource won't be bound to any device or format restrictions.
Last we pass our surface of type LPDIRECT3DSURFACE9 in.

The code should look something like this:

   1: g_pd3dDevice->CreateOffscreenPlainSurface(x, y, D3DFMT_A8R8G8B8, D3DPOOL_SCRATCH, &frontbuf, NULL);

3. Get the screen data and write it to our surface

That's kind of easy, simply call GetFrontBufferData and the whole front buffer (your rendered scene with effects...) will be copied to your surface

   1: g_pd3dDevice->GetFrontBufferData(NULL, frontbuf);

4) Save our surface to a file

The last step we have to do is to save the surface to a file. The D3DX library contains the following function which we will use: D3DXSaveSurfaceToFile
The parameters are the following: First pass the filename we created earlier. Second pass the desired file format you want to save your image, in our case we decided to save to bmp so we choose D3DXIFF_BMP. The third parameter is the surface which contains the captured screen. We are finished. Fill the last two parameters with NULL since we don't want to use a palette and we want to save the entire screen to the file not only a part.
Here is the complete code. It's copy/paste ready so you can try it out.
In order to use this code you will need to include the apropriate header file and link to the library, so put the next lines somewhere in your code:

   1: #pragma comment(lib, "d3dx9.lib")

   2: #include <d3dx9.h>

assuming that the variables g_bWindowed is of type boolean and determines whether this is a windowed (true) or fullscreen (false) application and g_hWnd is of type HWND and is a valid window handle to our created window, check out the complete code:

   1: HRESULT blTakeScreenShot()

   2: {    

   3:     HRESULT hr = S_OK;    

   4:     LPDIRECT3DSURFACE9 frontbuf;    

   5:     char filename[64];    

   6:     FILE* f;    

   7:     int x, y;    

   8:     RECT rcWindow;     

   9:     

  10:     // look for the next free file    

  11:     for(int i=0;i<999;i++)    

  12:     {        

  13:         // build the filename        

  14:         sprintf(filename, "screen%.3d.bmp", i);        

  15:         f = fopen(filename, "r");        

  16:         if( f == NULL)            

  17:             break;        

  18:         else            

  19:             fclose( f );    

  20:     }     

  21:     // get the screen resolution. If it's a windowed application get the whole    

  22:     // screen size. If it's a fullscreen application you might have somewhere     

  23:     // your defines as: #define SCREEN_WIDTH 800    

  24:     if( !g_bWindowed )    

  25:     {        

  26:         x = SCREEN_WIDTH;        

  27:         y = SCREEN_HEIGHT;    

  28:     }    

  29:     else    

  30:     {        

  31:         x = GetSystemMetrics( SM_CXSCREEN );        

  32:         y = GetSystemMetrics( SM_CYSCREEN );                

  33:         // to get the window sizes        

  34:         GetWindowRect( g_hWnd, &rcWindow );    

  35:     }     

  36:     // here we create an empty Surface. The parameter D3DFMT_A8R8G8B8 creates an 32 bit image with    

  37:     // an alpha channel and 8 bits per channel.    

  38:     if( FAILED( hr = g_pd3dDevice->CreateOffscreenPlainSurface(x, y, D3DFMT_A8R8G8B8, D3DPOOL_SCRATCH, &frontbuf, NULL)))        

  39:         return hr;     

  40:     // now we copy the entire frontbuffer into our new surface. The first parameter is NULL since    

  41:     // we assume we have only one swap chain    

  42:     if( FAILED( hr = g_pd3dDevice->GetFrontBufferData(NULL, frontbuf)))    

  43:     {        

  44:         // if this fails release our surface so we have no memory leak        

  45:         frontbuf->Release();        

  46:         return hr;    

  47:     }     

  48:     // This is the most important functions. The DirectX-SDK provides this handy little function to    

  49:     // save our surface to a file. The first parameter is our specified filename, the second parameter    

  50:     // tells DirectX what kind of file we want to save (in this example we decide to save to BMP)    

  51:     // Note the difference between a fullscreen screenshot and a windowed one. If we have a windowed application    

  52:     // we only want the specified RECT saved from our screen capture    

  53:     if( !g_bWindowed )        

  54:         D3DXSaveSurfaceToFile(filename, D3DXIFF_BMP, frontbuf, NULL, NULL);    

  55:     else        

  56:         D3DXSaveSurfaceToFile(filename, D3DXIFF_BMP, frontbuf, NULL, &rcWindow);     

  57:     

  58:     frontbuf->Release();     

  59:     return hr;

  60: }

About WinSnake 

WinSnake is a nibbles clone created by ZoE from Gringo Productions. Although there are enough nibble clones out there this is kind of different. The most important thing is that WinSnake is configurable. That means that you are able to make custom mazes and provide them to others. Of course this is not the asskickin' feature of all times, but it makes a lot of fun.

WinSnakEd tools
You are able to build custom game packages (game packages are the files containing the edited/custom data) with the WinSnakEd tools. These tools contain a maze editor and a package builder (necessary to build the packages). You are able to change any graphic image of the game (except the special goodies) and to replace any sounds and music with your own. The possibilities of creating new mazes are eternal. Of course you may also specify the design of your maze. Therefore we have created the section WinSnake game packages. If you have build a great maze or even a complete collection and want to provide it to the public contact us. We'll put your package with screenshots and a short description at the game package section. If you want to exchange information with others about WinSnake editing, the WinSnakEd tools or anything related to WinSnake take a look at our message board. Most probably the best questions and answers are there.

Credits
Thanks to DMA for the menu graphic. Since it's very difficult as an amateur programmer to get some graphic artists for the job, I had luck with this guy. Thanks goes also to RIP for not doing what I should do and spending the time over the net. I would also like to say thanks to the guys who did the music. Since I took all the sounds from samplers I don't know your names. If you think a track is from you and your name should appear here please contact me and I will put your name right here.

And now get WinSnake and have fun... 

WinSnake features 
DirectX support (DirectX 8.0 or higher required)
multiplayer support, play against others on the same machine.
editable content. Fully editable with the WinSnakEd tools. You will be able to create custom mazes.
fun, fun, fun...

WinSnake screenshots

WinSnake system requirements 
WinSnake was developed and tested on a AMD K6-2 500 MHz machine. A Trident 3D graphic card and a Terratec DMX sound card completed the system. Due to this low-end system WinSnake should run on every machine. Here we go with the official system requirements:

• IBM compatible pc with at least 400 MHz CPU
• DirectX graphic adapter with at least 4 MB RAM
• a minimum of 32 MB RAM
• at least 15 MByte of free disk space on your hard drive
• a DirectX compliant sound adapter
• Windows 98, Windows 2000 or Windows XP
• DirectX 8.0 or later

WinSnakEd version
The WinSnakEd tools are currently v 1.0.0
That means that these tools are full functional and official released. Errors shouldn't occur but most possibly will. If you encounter any bugs please send us a short bug report and if possible the log file created by WinSnakEd. We will fix the bug as soon as possible.

WinSnakEd information
If you have any suggestions, ideas, enhancements or simply some questions about WinSnakEd don't hesitate to contact us. You can always take a look at the message board, where most answers are to find or simply contact us via email at zoe@g-productions.net

Features 
With WinSnakEd you are able to

• import custom images for background, for the snake and for the maze
• import custom sounds for background music, for eating a goody and for dying
• configure the look of the maze
• create complete game packages with up to 10 mazes per game package
• import media of any size you want as long as you stay within the WinSnake specification. For more details head over the WinSnakEd tec specification

Installing the game packages
After created the game package simply copy the created pkg file into your WinSnakebdata directory. WinSnake will detect the package and provide it in the maze menu. You are now able to select the game package and choose the maze on the left you want to play.

Contributing game packages
You have created game packages and want to provide them to the public? Contact us and we will upload your game package on the WinSnake site. Make some screenshots, include a readme file and you are ready to go.

WinSnakEd tec specification
Here are some important facts, necessary to know for developing

• WinSnake only supports 24 bit bitmaps. You can try 8 bit bitmaps or other image formats as tga, jpg, or anything else. It won't work
• WinSnake only supports uncompressed WAV files for sound and music. While there are currently also midi tracks in the standard game package you won't be able to get them work with WinSnake. Be sure to use uncompressed wav files.

Try the demo: wsnake_demo.exe (1,49 mb)

Download the full version: wsnake_setup.exe (3,53 mb)

Download the editor tools: wsed_setup.exe (3,26 mb)

Enjoy!!!

About

The blueTec Engine is a powerfull game engine providing the developer with an interface to create a drawing, sound and music device in order to create games. The engine is very powerfull and not limited through software so the developer has full control and freedom to design easily games without limitations
About
The blueTec Engine was developed in order to encourage people with less knowledge in graphic programming to create games. Therefore the blueTec Engine is held as easy and simple as possible so that any developer no matter what skills he has in programming can use this engine without having to take care of all that graphic and sound stuff. Since most developers don't take the time to go more into any of the graphic API to realize their ideas, this engine will hopefully be a good starting point and will soon find people to try.
Features
The blueTec Engine currently supports the following features:
- surface loading from 16 and 24 bit bmp files
- sound loading from uncompressed wave files (pcm)
- music loading from wave and midi files
Publish games
As an additional attempt to encourage young developers to develop games we provide the possibility to host their games on our website as long as you want us to do this. You developed a game using the blueTec Engine? You have no webspace to upload it? Drop us some lines in the forum on http://www.g-productions.net and we will provide your game for download.
FAQ
Still any questions? Check out the general FAQ or the developers FAQ below in order to get more information.
Download
Download the blueTec SDK here
Features to come
- surface loading from 8, 16, 24 and 32 bit compressed and uncompressed bmp files
- surface loading from 24, 32 bit tga files
- surface loading from pcx files
- sound loading from ogg files
- music loading from ogg files
- music loading from mp3 files (?)

Developers FAQ

I have the MinGW version x.y.z compiler. Can I use the sdk?
The SDK was developed using MinGW 3.2.2 but should also work with 3.1.x Just try and you will find out. If you encounter any problems try another version or drop us some lines.
I try to execute the samples but a message appears "Could not load game api"
In order to minimize the size of the file the dll was not copied into all the sample dirs. To try out the samples just copy the blueTec.dll from the dll folder of the sdk into the sample folders and everything should work fine
I've created a new project. After compiling a compile error tells me "blueTec.h: no such file or directory"
Go to your project options. Select the directories folder. Within the folder select Include Directories. Within this you should add the path to the Include directory of the SDK. After that everything should compile fine
I created a new project. After compiling a linker error tells me "cannot find -lblueTec"
Do the same as above for the library folder, but then point to the lib folder of the SDK
I took a look into the header and source files of the sdk. Where are the functions?
You won't find any. The blueTec Engine was designed so that you are able to perform a dynamic link to the engine api at runtime. This is also called late binding. Not function or class will really be build within your application since this would be static linking exporting the dll's symbols at compile time. To have dynamic binding we choose the other way like this is done in every modern game engine.

General FAQ

What is the blueTec engine?
The blueTec engine is a game engine supporting a draw device, a sound and a music manager. This engine provides people with less knowledge on graphic and sound programming with some important and usefull tools to create their own games. Now everyone is able to create small little games withouth haveing to take care of all the stuff around a game. You can fully concentrate on your content.
What do I need to use the blueTec engine?
You need to have Dev-Cpp installed or at least the MinGW compiler tools in order to use the blueTec engine. Since it is not necessary to have an IDE installed we recommend you to use Dev-Cpp or MinGW Studio or your favourite IDE. You also need to have a basic knowledge on C++ or at least some general programming skills.
How do I use the blueTec engine?
In order to use the blueTec engine you need to download the blueTec SDK which is available for download on this site. Just download the package and unzip it to your favorite folder. To create a blueTec application (most probably a game) you might want to take a look into the documentation or at least study the example applications which give you a great entry point. We recommend both but beginners should read the documentation in order to understand what they are doing.
I want to create a big, big game, is this possible with the blueTec engine?
The blueTec engine is not limited. You can create any game you want no matter how small or big it will be at least. To make it more clear, the only thing limiting the blueTec engine is the memory available on your machine.
What are surfaces you talk about?
The blueTec engine supports only a 2d device. That means that you will only be able to create 2d games if you have the time and the skills maybe 2.5d is also possible. When talking about surfaces we mean an object which is created from a file or text to represent a drawn area on the screen.
I have a specific questions about develing with blueTec or general questions which is not covered by the FAQ
No problem. Head over to the forums and post it. As soon as possible it will be answered. Or contact us directly via the board or email address.
I just created a game using the blueTec engine. Would you host it?
Sure, contact us. We will upload it and host it for you. Optional you have the possibility to create some kind of story site or just give us a short description to post with the download.
Why are you guys providing a 2d engine and not a 3d engine?
This engine is for all who want to make small games. Not everyone has the time and the skills to create 3d games. Providing this little engine helps people to concentrate on the real work of a game and not on the, often very time consuming, framework to create a game. 2d games can also be very cool. If you have a cool idea you have now the tools to realize it.
Will there be any future updates?
Yes of course. Maybe this is only a small project compared to the blueEngine ( read more ) but that doesn't mean that we won't improve and enhance this project. You are greatly welcome to give your opinion, tips and feature requests.
The blueTec engine is cool but I need the feature xy. Would you implement it?
Most probably yes. The blueTec engine is from developers for developers. So if you use it and miss a specific feature or function head over to the forums and post it. As soon as possible an update will be made.

Updates

.plan update 10.03.2005
Who said we are dead? A lot of resources were put into the blueEngine so the blueTec SDK had to wait the last months for its update. But since the blueEngine is finished now I can concentrate on the SDK again in order to fulfill the needs.
The ogg support is implemented and playing avi files on surfaces also is close to finish, an update will follow soon.
Loading different image formats may be also included but is not my primary goal at current since you have with dds and bmp two powerful file formats you can play with. Future? Of course the features mentioned below will be included but also some other goodies I have in mind so stay tuned.
.plan update 24.12.2004
Introducing the new file formats is the biggest change for the new version. About mp3 file format there has to be decided since mp3 is evil and not our first choice to implement. Therefore the decision to have ogg files supported is great and can be taken from blueEngine (why to use an evil format when you can have a powerful equal format which is free?)
- loading tga of any format file and memory
- loading pcx of any format file and memory
- loading bmp of any format file and memory
- loading ogg file and memory
- loading mp3 file
- playing avi files on surfaces
- providing helper functions for conversion between color values etc
- enable/disable log, html log select since not everyone wants to use log file output. Additionally providing the interface to use the log file functionality for the complete application (not only the engine)

blueTec_sdk.rar (515,53 kb)

Here you are with a DevPak designed for Dev-C++.
This package was build in order to make it easier for you to use DirectX with the MinGW Compiler used in Dev-C++ . A lot of work was done on this package but the results show that it was worth the work As far as we know, it is the most complete DevPak for DirectX available.
The package:
When we started looking for a package we used the distribution of Gorobei and Zero Valintine from www.gamedev.net. Soon we noticed that it was just a build of original DirectX SDK files, not optimized to work completely with the MinGW compiler. After some basic changes on the DirectSound and DirectMusic stuff we got the most modules working. The last big challenge was the DirectShow part of DirectX. Picked with many IDL interfaces maybe this was the most difficult part of the complete package. After getting this to work and after re-building the BaseClasses (Kudos to ToTo who did the most work on this) the final step was done. We added the mmreg.h (for some multimedia registration stuff) to complete the package and provide it to you as is. Work is not finished yet. We continue improving the package to make it the most complete DirectX.DevPak available, so it will (hopefully) be one day a 1:1 copy of the DirectX SDK.
The DevPak includes:

• all header files of the DXSDK (MinGW compatible)
• all libraries of the DXSDK (MinGW compatible)
• some debug and helper libraries (shared dll) of the DXSDK
• some templates to create dx projects within Dev-Cpp from scratch.
• DirectX icon
• the helper classes of the DXSDK

Note:
You don't really need the DirectX9 SDK. What you have to install is the DirectX 9.0 runtime version. You should also be carefull not to have installed the DirectX.DevPak available through the update module of Dev-Cpp. In some cases you might get compiler errors, caused by concurrent versions.
More information:
For more help on DirectX9.DevPak visit our message board. For more information on Dev-C++ visit: the Bloodshed forum
Credits:

• ToTo for contributing some major changes on the libraries and for help on the BaseClasses
• EvilInvader for all that ml-shit I couldn't get rid of.
• NinjaNL for using the DevPak and providing us some usefull information on usage and testing.
• Yeoh for the How_to_make_Devpaks.txt at http://www.yeohhs.com

DirectX9_help.rar (11,42 mb)

DirectX90.DevPak (3,63 mb)

DirectX90b.DevPak (5,07 mb)

DirectX90c.DevPak (6,23 mb)