GUI for fxc

by Dimi 12. August 2010 03:14

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)

Tags:

development | game development

RetroSnake

by Dimi 24. June 2010 08:35

I posted earlier today about the text console library which can be found on John Romero’s blog at www.planetromero.com and started playing around a bit. In fact I started playing around with it and I was surprised how fun it can be writing games like I did long long time ago. Now all of you know WinSnake of course (the WinSnake which can be found on this blog ;)) and I thought it would be a cool idea to make a retro version out of it. Not that WinSnake would be worth but because it is fun. After trying a bit I took the sounds I used in WinSnake and put together a small game with 6 mazes.

John Romero is talking about a pac-man game and using FMOD to enhance everything. So I did. I downloaded the FMOD library and to be honest I’m very happy with the result. The complete game was finished within few hours. I never worked with FMOD before but it was so easy thanks to the documentation and the samples. Maybe I shouldn’t invest to much time in developing the sound system for D+ but using fmod instead (we will see…).

So enough talking, download RetroSnake and play. Be sure to visit John Romeros Blog on www.planetromero.com it's very interesting.

I developed RetroSnake with Visual Studio 2010 so most probably you will need the VC 2010 runtime which can be downloaded at Microsoft or with the link below.

RetroSnake.zip (1,82 mb)

vcredist_x86.exe (4,84 mb)

maze1 maze2

maze3 maze4 maze5 maze6

Tags: ,

game development | games

Text console library

by Dimi 24. June 2010 08:24

Wow I stepped over this post on John Romero’s Blog and I’m fascinated. I loved retro games and I still do. The text console library, which can be found on that blog, allows you to do funny things with colors and stuff. Check it out, it’s worth. I imagine the days where I started coding on a Amstrad CPC 464. The first three games have been text adventures…

I already started playing around with this library and I love it. Bye bye conio.h don’t need you any more :)

Tags:

game development

D+ I did it my way

by Dimi 23. April 2010 02:00

logo_dplus  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.

Tags: ,

game development

Open source projects – till death

by Dimi 8. February 2010 17:45

There are so many great projects out there and there are so many skilled persons keeping them alive. Sadly not everyone has the breath to work on his project until the end and that doesn’t matter. There are often more important things in life than games and development (really ;)).

I wont bother you again with the reasons why many projects fail like I did in the past. But what I notice again and again is that people start a cool software project and talk it to death. I was involved in a very cool discussion lately on www.gamedev.net on using STL in a game engine with performance issues. While I did some research on the above topic, I noticed that many developers (like me no pro) lead endless discussions on std::list<> vs. std::vector<>. Wow There was really a topic where a guy needed 9 months to develop his texture manager because he didn’t know which container to use. The discussion was held on a high level so not the integration was the problem but the performance and the accessibility. It was an quite interesting discussion and a very technical too but are we serious? I mean this guy lost 9 months on a texture manager how much time will he loose when he integrates a sprite manager?!? I met this guy again lately on ICQ and he told me he stopped the project due to missing motivation. I had the chance to discuss with him some minutes and he pointed out that he was focused on having a texture/material manager with good performance. Yeah, I stated, but was it worth loosing so much time on a texture manager? You usually load textures on level startup and don’t need to reload the levels while game play, so you could have used a std::vector<> container with sequential access and preventing of loading same textures more than once which would have costs him some days.

It was a very interesting discussion. People (non-pros) are often so focused on shaving of some seconds on routines that they loose the real focus —> the project. So it’s understandable if you loose your motivation. Saving some ms in this routine and some in another is good and you should also profile your code to detect weak points and application critical paths but please stop with endless discussions between vector and list. 3 frames more are a small advantage compared to 9 months of development and sure not worth.

My advice: stop talking and start coding. Do you think your game engine will get better if you talk about it? No one will be interested in if you used a vector or a list in your texture manager. No one will notice it and no one will ask for it. So stop enhancing the wrong parts of your engine.

Tags: , ,

game development

Source code please

by Dimi 8. February 2010 17:27

Why do you visit forums? Ok the answer might depend on what you are interested in and on what you are looking for but let’s take me for example. I’m a software developer and when I visit a forum a try to exchange information with people who share the same interests and/or are involved in similar projects and/or try to find a solution for a specific problem. Now I noticed on many forums and blog posts that there are people who cannot evaluate their own skills. You often step over posts with the following title: “I’m new to game programming and I started developing my own game engine to produce a game like Doom3”.

Bump!

Bump!

Bump!

Ok there is nothing against a challenge but hey be serious. Do you really think you would be able to develop a first person shooter with latest features without ever drawn a single triangle on the screen? I usually avoid commenting such posts but here is one which made me go mad. On a forum a guy opened a new thread like the title above. He asked people to help him get started. One posted a link to beginner tutorials on OpenGL another posted beginner tutorials on DirectX, some other guys pointed him to a C++ reference and so on.

Now after some days this guy answered to all the comments that he doesn’t need tutorials but source code. Again people tried to help him with posting some code snippets on how to create a DirectX device or how to get started with OpenGL’s glut library. Now some days later I stepped over some blogs where I was looking for some tutorials myself. The same guy (I suppose it was the same since the username was the same and this username was so unique that it would hurt if someone else would use it) posted on a tutorial, which was fairly enhanced with explanations and pseudo-code, that he would need the source code for the example.

This was the point where I went mad. Why people think they could copy and paste tutorial code and build an game engine out of it. I like sites with source code very much but to help you learn a topic sites with pseudo-code are more than enough. You will never learn the essence of octree rendering if you copy and paste the source code of a tutorial into your own application. You should read carefully through the tutorial and work it out for yourself. I suppose only 5% of the tutorial codes are usable for your engine and a benefit is visible.

Think about it.

Tags: ,

development | game development

Scripting in game development

by Dimi 13. November 2009 13:20

No this won’t be another of those Lua posts. I did some research to decide which scripting language I will integrate into a project. Of course the number one stop for me was the Lua website. Since everyone is talking about Lua when it comes to scripting it was clear that I had to check this out. Lua was also mentioned by Jonathan S. Harbour in his book Advanced 2D game programming(the DirectX.DevPak was published in this book so check it out) so I read carefully through that chapter and tried the examples. Lua is very good, I thought first. Using just the globals through my C++ application worked very well. After that I thought how it would be extend it to let the Lua scripts calculate NPC movement. This worked also very well. Everything was just fine. It took me some time to get it working with my application but it worked well. There was just one point which was not what I expected. In Lua it’s possible to pass parameters from C++ to the Lua functions and receive the function result back in C++. It’s also possible to access C++ functions through Lua. These have to be registered first but that’s no problem. It works vice versa. But integration is sometimes very time consuming. I accidently stepped over GameMonkeyand this scripting language changed everything. Why? Watch the example below:

   1: #include "gmThread.h" // game monkey script
   2:  
   3: int main(int argc, char* argv[])
   4: {
   5:   gmMachine machine;
   6:   machine.ExecuteString("print(`Hello world`);");
   7:   return 0;
   8: }

This is the simplest script ever. You just need to include the GameMonkey header files and you are done. Simple isn’t it? Further examples showed that it’s more simple to integrate into existing applications compared to Lua, and that’s an important point for me since I don’t want to loose too much time on integration. You will argue now that in most cases you do integration only once but if you take a closer look at GameMonkey and the examples shipped with the SDK you soon will realize that nearly everything is a bit easier than in Lua.

There is a simple explanation for this. If you read carefully the introduction on the GameMonkey website you will notice that the developers of GameMonkey worked intensively with Lua and decided to make some things better so GameMonkey was born. I’m currently way too busy with my game project and my daily job so maybe in near future some GameMonkey tutorials will follow up. Stay tuned.

Here are some useful resources:

Great articles on how to get started with GameMonkey on www.gamedev.net:

http://www.gamedev.net/reference/programming/features/gmscript1/

http://www.gamedev.net/reference/programming/features/gmscript2/

A comparison between JScript and GameMonkey:

http://www.chriscowherd.com/2006/08/microsoft-jscript-vs-gamemonkey.html

Tags: , ,

game development

We are hiring…

by Dimi 14. September 2009 10:37

As you may know, I’m close to finish my new game engine. As a by-product a small 2d sprite game engine was developed and since I’m only a developer I’m looking for some skilled people who want to contribute to this. If you are an experienced texture artist or someone who knows how to use Photoshop, Paint Shop Pro or other graphic applications please contact me. At current I have three design documents for 2d games. One of them maybe the most provocative one will be published online here on this blog to let it grow with comments and suggestions from YOU.

Another design document is at work covering a fully driven 3d game, but here is still work to be done on the engine. Branded from experiences while working on the blueEngine I won’t just form a team to get this finished. The engine is a spare time project of mine just to stay fit in C++ and DirectX development. There will be soon released  a features list on this. Just one thing to say: the engine is a complete shader driven engine.

Interested? Just comment here and I’ll contact you.

Tags:

game development

Newton Game Dynamics with DirectX mesh files

by Dimi 12. August 2009 23:42

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)

Tags: , ,

game development

It’s all about game design

by Dimi 25. May 2009 22:30

I don’t want to start the discussion again whether design or technology should be law when developing a game. I posted my thoughts in the post The rise and fall of game projects so don’t worry. You won’t find a theoretical discussion about game development ethics dos and dont’s.

What I want to show here is a guy (I’m sorry if it’s a team and I don’t know) named Johan Peitz. If you love good games you should check out his site Free Lunch Design. This guy is awesome and in my opinion the only guy out there who understood what’s all about game development. Check out his site. His game Icy Tower is an award-winning blockbuster he wrote. What did this guy do? He takes game engines like allegro and concentrates on what he can do best. Developing games. And hell yeah he is a real game developer. Alex the Allegator, Harold’s Hills or the incredible Happyland Adventures are only few to mention here. This games are so addicting.

But he also understands to try new ways for his games. Check out Frog Hunt. Senseless? Yes and No. Both answers are right. There are only two possibilities. You understood the sense or you didn’t.

Why so much advertising for guy I don’t know? Because he is at moment the only one who deserves the title game developer. Instead of sticking with game engines, trying to bring groundbreaking graphics or new rendering techniques to public he is programming games with only one thing in mind. Play!!! And damn yeah you play the games and they are fun.

If you still haven’t visited his site you should now do and if you are an amateur game developer or want to be one you should consider what he did. Concentrating on gameplay. As long as you don’t work for id Software which is the only game company where we expect the technical progress to be law you should do it like Johan Peitz where design is not only law but maybe (and thank god for this) the only word this guy has in mind. Many commercial and professional game studios should take him as example for great game design.

Tags: ,

game development

Powered by BlogEngine.NET 1.6.1.0
Theme adopted by Dimi with portions of Mads Kristensen and portions of Rtur.net

RecentPosts