Welcome to DarkStride
Search  
 Navigation
· Home
· Downloads
· Forums
· Gallery
· Members List
· Private Messages
· Projects
· Your Account

?>
 Google Ads
There isn't content right now for this block.

 
DarkStride Game Engine
Built on DirectX 9.0 / C#




General Description:
More a DirectX wrapper than a game engine, this collection of ~15 classes allows for quick game development by taking the managing DirectX out of the picture.

Features:

  • Full resource management (including restoration and disposing)
  • 3D as well as 2D support
  • Built in particle system
  • A full featured Windows based emulation and menu system
  • Input buffering to allow for smooth mouse movement
  • Network wrapper for easy network interfacing
  • Sound wrapper for easy sound interfacing
  • Helpful collection of rendering methods
  • Full FPS and frame motion tracking
Technical Breakdown:
The DSGameEngine is the primary class for the game engine. It handles the primary game loop and ensures that the correct timing is tracked between rendering and frame movement. This class handles the background management of a game. It has in it instances of the graphics wrapper, the input wrapper and the network wrapper. All of these wrappers are used by demand only, meaning that if you don’t need them they do not increase system overhead. You only have one DSGameEngine instance per game and it is one of the few variables stored at the GUI level of your project.

Example – Creating a minimum DX app
The following project is an example of the bare minmum necessary to start a DX app and use the DSGameEngine class. (Well almost, a floating bananna square has been added to the downloadable version for good luck) A PKZip compressed file is available in the downloads section. A networkable version of Pong is also available in the downloads section. The entire application was written in just under 6 hours. It lacks the polish of a finished game but demonstrates how the game engine can help shave time out of a development schedule.

Step 1.) Creating the project
You start by creating a standard "Visual C# Project" of type "Windows Application". All of your game code will originate from here so make sure to name your form something other than "Form1". Like "Super Power Galactica" or you could be cheezy and just call it "frmMain". Whatever, just make it meaningfull.

Step 2.) References
The references are fairly straight forward and I leave them to you to figure out.
	//This is needed for Vectors to store our bananna locations and speed using Microsoft.DirectX;
	//This is where the game engine is defined using DarkStrideToolbox;

Step 3.) Declaring the game engine
Create a variable for the game engine to live in, this variable should be private to the form. You should also create a public property so that the game engine can be accessed outside of the form. The "Main" call in Step 4 will need this property.

private DSGameEngine m_oGameEngine = null;

Step 4.) The "Main" Function
The "Main" function is fairly important, which is funny since once you've written it you'll likely never see it again. The STAThread at the top makes your project thread safe and is added by the Visual C# wizard. You'll notice that everything is wrapped in a Try/Catch block, and that a special helper function displays our errors when they occor. Because all of our code originates from this function, wrapping it in a Try/Catch block ensures that every error gets handled.
Another key thing to notice is that the "OneTimeSceneInitialization" event is setup before the "Run" call is made. The "Run" function call launches the game, we don't come out of that call until the app is shutting down. If you fail to tap the "OneTimeSceneInitialization" prior to calling "Run", your application will never receive the callback. Or rather it will receive the callback, but before you've setup the function to handle it.
Also notice that the "DarkStrideToolbox.RenderMode.TwoD" being passed into the engine. Right now this only serves to tell the particle system how to render. All of the other functions that are affected by "2D vs. 3D", already know the mode your using, usually by the function called. (for example you call Render2DTexture and Render3DTexture).
	[STAThread]
	static void Main() 
	{
	  try
	  {
	    using( frmMain oApp = new frmMain() )
	    {                
	      oApp.DSGameEngine = new DSGameEngine( oApp,DarkStrideToolbox.RenderMode.TwoD,false );
	      oApp.DSGameEngine.OneTimeSceneInitialization += new EventHandler( oApp.OneTimeSceneInit );
	      oApp.DSGameEngine.Render += new EventHandler( oApp.Render );
	      oApp.DSGameEngine.FrameMove += new EventHandler( oApp.FrameMove );
	      oApp.DSGameEngine.Run();
	    }
	  }
	  catch( System.Exception oEx )
	  {
	    DSMisc.ShowErrors( new System.Exception( "MetalMarines.frmMain.Main Failed.",oEx ) );
	  }
	}

Step 5.) One time initialization of "stuff"
The purpose of this call is to allow the user to define any basic initilization actions. For example this is where you could load in any graphics you need or setup any initial menus. This function is called only once, after the DirectX 3D Device is created and initialized.
	//This call is made once, once the device has been created
	public void OneTimeSceneInitialization(object sender, System.EventArgs e)
	{
	}

Step 6.) Lights, Camera, ACTION!
The "FrameMove" callback is made once per frame. It is used for moving the game forward in time. The event arguments contain the elapsed (Since last "FrameMove" call) as well as application time. This function is where you can apply your velocity to a ship in motion, advance the explosion of its missile or pop new objects into the game world. The very next thing done after a "FrameMove" is a "Render". Why not put all your frame motion code in the "Render" callback you ask? You could, it would have no impact on the game. But this is a more logical breakout... at least in my world.
	private void FrameMove(object sender, System.EventArgs e)
	{
  	  DSGameEngineArgs oArgs = (DSGameEngineArgs)e;
	}

Step 7.) Draw it, draw it all!
This function is called once per frame, the call is the entry point for all rendering. This function sets up render states, clears the viewport, and renders the scene. Just after this callback is made, the mouse is rendered (if the setting to render the mouse is set to true). This ensures the mouse is always drawn on top of all other animation.
	private void Render(object sender, System.EventArgs e)
	{
	  m_oGameEngine.RenderText( 0,0,System.Drawing.Color.White,m_oGameEngine.FrameStats  );
	}









Warstrider (07/07/2006)

Copyright © by DarkStride All Right Reserved.

Published on: 2005-08-03 (4108 reads)

[ Go Back ]
Web site powered by PHP-Nuke

All logos and trademarks in this site are property of their respective owner. The comments are property of their posters, all the rest © 2005 by me.
You can syndicate our news using the file backend.php or ultramode.txt
Web site engine code is Copyright © 2003 by PHP-Nuke. All Rights Reserved. PHP-Nuke is Free Software released under the GNU/GPL license.
Page Generation: 0.07 Seconds