Feal87's Blog

Just another programming weblog.

Archive for May, 2009

Scrapping out the ID3DX10Sprite / ID3DXSprite interface

Posted by feal87 on May 31, 2009

One of the first things I’ve thought useful for my engine to have and ironically one of the last I’ve actually implemented is a remake of the default interfaces given by the extra DirectX library D3DX for drawing sprites. (2D images over quads in an orthogonal projection basically)

The reason driving me to remake these classes was about improving speed and increasing flexibility. While the default classes had the basic functionality to draw 2D images, it lacks support for custom shaders and other functionality needed in my domain. Another particular note that influenced my decision was the fact that the two classes for DirectX9 and DirectX10 had different behaviour and contract and I wanted an unified behaviour and contract for my applications.

The first thing I’ve done when I decide to start developing the classes was brainstorming. I suggest anyone that is starting a big change in their own code to think and write down what exactly do you want and how you want to make it. I figured out several ideas about how to organize the new classes :

1) Using a dynamic vertexbuffer and index buffer. Inside them adding new values each time a call is performed. Then executing several draw with different vertex offsets. (Basically the same thing that the default class does)
2) Using a dynamic vertexbuffer and index buffer and a special automanaging texture that contained all the textures to draw. When the end function is called it calls a single draw to draw everything.
3) Using a static vertexbuffer with a quad inside (trianglestrip to save memory) and draw multiple time with different world coordinates each time a call is maked.

I personally thought the first choice was quite inefficient, updating a lot of times the vertex/index buffers was not my style so I skipped thinking about this implementation.
The second choice was quite alluring, but automanaging a special texture was a quite difficult task and I didn’t know if there were any gains in speed. (I think I’ll give it a shot anyway in the near future ;))
The third choice, the one i choose, was the most simple and “effective” in my opinion. I only needed to update the world matrix and the texture each time I drawed a new quad.

Sprite Alternative Class

Sprite Alternative Class

 The contract given by the class is quite straightforward. Let’s analyze it (I’ll skip the Begin/Draw/End that I’ll analyze after) :

1) The Buffer property is the static vertex buffer containing the quad that has the protected modifier to allow the derived class to modify it.
2) The ProjectionMatrix and ViewMatrix properties allow the user to choose which transforms to use for a particular rendering.
3) The Dispose method that release all the resources used by the class. (VertexBuffer and Effect basically)
4) The LoadContent and UnloadContent that load and unload the resources used by the class in the various circumstances. (Lost Devices, Resets etc..)
5) The constructor.

Sprite Alternative Process

Sprite Alternative Process

Using the new class is quite straightforward.

1) The call to SpriteAlternative.Begin() initialize all the states/effects needed for the draws to occur.
2) The calls to SpriteAlternative.Draw() change the WorldMatrix and Texture and actually make the Draw call.
3) The call to SpriteAlternative.End() closed the effect. (Only needed in DX9 while in DX10 just does nothing)

While i did not gain a lot of frames in the process (almost 0,779 ms each frame on a 3,6 ms application and -10% on the CPU utilization on the same application), I did learn a lot from this experience and now I have a solid base on which to base various personalization (deriving from the SpriteAlternative class and giving out personalized shaders and other features…).
I suggest anyone reading this article to have a shot to recreate their own Sprite class, it is a nice experience.

I hope this has been a helpful reading for you all,
The next topic I’ll talk about is the remake of the ID3DX10Font/ID3DXFont classes,

See you later. 😉

Posted in General | Tagged: , , , , | Leave a Comment »

Game Loop – A little story

Posted by feal87 on May 29, 2009

When I look back at the almost three months spent on the game engine I’ve developed, I remind of the various problems and trials I had to resolve at each stage. One of the most interesting thing I think I’ve worked on was the designing of the game loop.
Well the design at first was “quick and dirty” and slowly evolved into something more advanced. Let’s go back and see the steps that have taken the game engine to what it is now and while at it, let’s look at the various type of game loops I’ve used. (I will NOT delve into the depth of programming, but leave it as a simple theorical reading)

When i first started tinkering with SlimDX, I started by using a slightly modified version of their Sample Framework. It is basically a simple framework that imitate the behaviour of XNA. Their game loop was a very simple single-threaded one.
The thing that i didn’t like of it was that it was based over the Application_Idle event to trigger the drawing of the frame, making the engine quite unreliable and generating useless trash work over the Game Clock. I quickly worked over it making it look like a classical game loop of old days…

Simple Game Loop

Simple Framework Gameloop

The game loop repeated until the game ended its execution, updating the game logic and drawing frames as fast as it can. (if not blocked by the VSync)
While this kind of game loop was ok for demos and simple app, it was quite unefficient for games that needed correct timing and performance.

However I remained stuck to this kind of game loop for quite a while, until one day i received a mail from the Intel Visual Adrenaline newsletter containing a paper over multithreaded game engines.
I thought it would be nice to implement a multithreaded game engine, especially in these days of multicores CPUs. (While I’ve not followed any of the guidelines of the paper :D)
I started working on the Multithreaded game engine and after a day or two…

The new game loop contained several blocks. Let’s examine them all :

Multithreaded Game Loop

Multithreaded Game Loop

1 ) Just like the old game loop the first things it does is to process all the windows messages still in the queue.
2 ) Check if the engine is still active and if not, just sleep for 20 ms. This part of the engine was quite necessary because i felt that using CPU cycles while the application was minimized or paused was quite useless.
3 ) The third step is “Reset the devices if needed“. This is a needed feature if the user try to change resolution or the device is lost. (As we know Reset must occur in the same thread of the message pump and of the creation of the device)
4 ) Update the engine clock to have a correct timing inside the game.
5 ) The “Process all internal messages” phase is a particular one. I thought it would be needed to execute some operations serially so i gave the opportunity to queue inside a personal message pump some delegates to be executed at the next frame.
6 ) Finally we are at the most important step of the game loop, “Schedule all the tasks available for the engine“. 
Before examining this step let’s see what is a task. A task in my engine, is a class that execute a particular objective (be it Draw the frame, update the game logic, calculate physics, etc…) at a certain rate calculated in ticks in a personal thread. For example we could have a Draw task that runs as fast as it can, and an Update task that runs maximum 60 times per second. The engine at this phase contained 3 basic always-active tasks that were the Draw Task, Update Task and the Audio Task.
As you can now imagine, this step schedule inside a particular Task manager class all the default tasks and all the tasks defined for the specific application. (for example an user can create a Physics task if needed for its app).
7 ) In the seven step we “wait for all the tasks to be completed“. (This is called lock-step mode in a game engine)
8 ) Synchronize data between tasks. In this step the Synchronization manager send notices of data changed to the various subscriber tasks.
9 ) Finally we go to the last step when we check if the game is ended or not.











As you can see, this kind of game loop was quite a step forward permitting control over timing and performance and on a side note allowed the game to scale over multiple processors easily.

One problem remained in my mind…what if the application needs more than one device? (like a level editor program with inside a character editor in another window)
There was two ways to resolve the issue :

1) Use multiple swapchains on the same device.
2) Reorganize the game loop to support multiple instances of the game engine.

I decided for the latter and started reorganizing the game loop to handle this new situation and I finally got to the actual form of the game loop :

Final form of the Game Loop

Final form of the Game Loop

What’s changed here? Well we basically abstracted the game engine by creating an engines manager that allow multiple instances of them to run in a lock-step mode. The rest of the game loop is basically the same.
Here’s an image of an example application running two engines at the same time with the final engine :
Multi Engine Example

Multi Engine Example

I hope, this reading has been useful, I’ve still not decided what the next post will talk about, but I think it will hopefully be about code practices so look forward to it.

See you later. 😉

Posted in General | Tagged: , , , , | 1 Comment »

Walkway to a MultiAPI Engine (Automatic Build System)

Posted by feal87 on May 28, 2009

When I decided that the game engine I was about to create would support multiple APIs, I had a few ideas about how to structure the game engine and its build management, all with pros and contros. This post will analyze the possible choices that I had without showing actual code, but examining the ideas behind it and their reasoning.

I identified while thinking three possible way to manage the game engine and its build management in simplicity :

1) Have single class with one codepath for each API.
2) Have multiple class, one for each API. (Device9, Device10, DeviceGL, Texture9, Texture10, TextureGL, etc…)
3) Have single class with preprocessor directives for conditional compiling. (#define DX9, #if DX9…#else…#endif, etc…)

The first one while permitting the use and switch between multiple engines from even ingame, it added useless checks every operation to know what engine are we using. Imagine an if…then…else each operation, it would have added a very big and useless overhead to the game engine.

Example of a Type 1 Engine Function

Example of a Type 1 Engine Function

The second one had no overhead by useless checks, but losed the real meaning of a transparent MultiAPI engine, because i would have to write multiple code for using each API in the various games while the objective is to write less code as possible.

The third one, the one I choose, was perfect for a transparent game engine. With conditional compiling I would have a slim DLL for each of the APIs, and all these DLL’s would have the same identical behaviour making them interchangeable.
However I encountered some problems while designing the solution.
The question was, how to actually use different DLL from inside C# in a simple and straightforward way? How to distribute all these different DLL’s and executables with an automatic system?
After a bit of tinkering I found out the solution I’m still using even today.

Engine example solution

Engine Type 3 Example solution

Basically the Visual Studio Solution is divided in multiple project and each project has multiple build configuration, one for each API. Each of this configuration have a preprocessor symbol to identify what needs to be compiled. When the game is build Visual Studio run the PostBuild event that merge the game engine library compiled (depending of the configuration) with the game executable and copy/rename the generated executable in the bin directory.
This has been possible thanks to a very nice tools created by Microsoft Research called ILMerge. ILMerge is an utility that can be used to merge multiple .NET assemblies into a single assembly.

Here it is an example PostBuild script that copies the SlimDX DLL and use ILMerge to create a single assembly with everything in it. (Only for Release DX9, but adding the others is just a work of copy&paste)

mkdir .\Build\Eseguibili\$(ProjectName)\
copy .\Library\SlimDX.dll .\Build\$(ProjectName)
IF "$(ConfigurationName)" == "Release DirectX9"
   (.\BuildTools\ILMerge.exe /out:.\Build\$(ProjectName)\$(ProjectName)DX9.exe
   "$(TargetDir)$(ProjectName).exe" "$(TargetDir)gamelibrary.dll")
IF "$(ConfigurationName)" == "Release DirectX9"
   (del .\Build\$(ProjectName)\$(ProjectName)DX9.pdb)

This way using the example solution I posted above we would have as result of the compilation two executables, PongDX9.Exe and PongDX10.Exe. Each one containing everything needed to be run, game engine dll included, inside the executable. (Except the game assets obviously)

I hope to have covered enough ground to let you make a general idea behind the managing of a MultiAPI engine.
The next article will be more technical. We’ll talk about the structure of the game engine i’m developing, its gameloop and lots more.

See you later. 😉

Posted in General | Tagged: , , , , | Leave a Comment »

Interoperability between DirectX9 and DirectX10

Posted by feal87 on May 27, 2009

One of the first things i’ve looked up when I was starting to write my game engine was to check what the actual APIs had to offer and if a MultiAPI engine was a reasonable or useful idea. (I’ll make a separate post to explain how I designed the engine)

After some searching, I decided that for compatibility sake I had to support not only the latest bleeding edge technology DirectX10, but also DirectX9. This because DirectX10 for several reason was not available on Windows XP systems.

Well, the dice was thrown and the developing began at steady rate, after a week or two I stumbled on a particular situation that I want to share with everyone hoping that it may help someone who is going through the same problem.

At that time I was developing a test game, the classical remake of Arkanoid in 2D that I think everyone do as first test project. While the main engine was working, I had to choose what and how to draw the objects on the screen. The classical arkanoid is divided basically in 3 distinct areas. The player, the ball and the bricks. 

Pong2D Screenshot
Pong2D Screenshot

While the first two posed no problem and could be drawed stand-alone, the bricks posed some problems.
DirectX is an API built to take advantage of large stacks of objects drawn together with a single Draw call. Doing 120 different draw call for the bricks (the level area is 15 bricks as width and 8 bricks as height) was quite overkill and would have damaged the performance of a, otherwise, so simple game. The idea I developed was to have a big texture to contains all the bricks and update the texture each time the status of the bricks changed. (updating obviously only the part changed)

Well, the surprise (and the reason of this post) come after developing everything and starting the test phase.
While in DirectX9 mode the game worked fine, in DirectX10 mode something strange occurred. After the first update of the texture, the color of the bricks changed completely while maintaining their structure… (The blue become red and some other changes)

After some debugging I found out that DirectX10 DOES NOT support ANY raw format supported by DirectX9 for texture. While DirectX9 used a format ARGB, DirectX10 (or well, DXGI) supported only RGBA. Also, the System.Drawing.Bitmap class (based over GDI+) i was using to update the texture was no more good as it support only ARGB too.

How to go around this problem? There was three way to go around this problem :

1) Convert (swirl) the data on the CPU before launching the update of the texture and retaining this way all the old code.
2) Convert (swirl) the data before drawing on the GPU via pixel shader.
2) Create a new class that import and manages the textures differently between DirectX9 and DirectX10 while maintaining a common face to the framework.

While the first idea was quite fast to develop it was tremendously SLOW (to update a 720×400 image it took 5 ms using unsafe pointers and over 12 ms with Marshalling) so it was discarded right away.
The second idea was discarded right away too because at that time I was still using the default Sprite interface that does not allow personal shaders instead of a textured-quad solution. (I’ll return on this on another post)

Leaved with no choice I programmed the third choice and the BitmapAlternative class born anew.

BitmapAlternative class diagram
BitmapAlternative class diagram

The BitmapAlternative class is basically a class that permits draw and management of images in either ARGB or RGBA format. The main point of making this class was to offer a single abstract way to get the texture data and update safely and I think it is the best solution to cover this kind of problem. 

Here is is a short peek at the actual code of the class (only the contructor and the members)

public class BitmapAlternative
    public Int32 Width { get; set; }
    public Int32 Height { get; set; }
    public Int32 Stride { get { return Width * 4; } }
    public byte[] Data;
    public BitmapAlternative(Bitmap source)
        Width = source.Width;
        Height = source.Height;
        #if DX10
           Data = ImageFunctions.ARGB32ToABGR32(source);
           Data = ImageFunctions.GetBytes(source);

The moral of this story? Well, there is no moral. 😀 
I just wanted to tell a story and hopefully save some people time figuring out and trying various ways to interoperate  DirectX9 and DirectX10 while using textures.

Ferreri Alessio

P.S. I heard that in the next DXGI 1.1 there will be support in DirectX10 for the plain old DirectX9 texture format. Maybe they found out about their error? 😉

Posted in General | Tagged: , , , , | 1 Comment »

Welcome to my blog

Posted by feal87 on May 27, 2009

Hi all,

First post of this blog…mhn…what can i say for introductions? Well, I’m Alessio, a software developer in Italy…wait, that’s exactly the same thing i’ve written in the about page. 😀

Well, to cut the long (?!) story short, look forward to some technical post about some features or problem i encounter while programming. 😀

I think i’ll close with this post here and start the first real post of the blog that will be titled “Interoperability between DirectX9 and DirectX10”.

See you later. 😉

Posted in Uncategorized | Tagged: | Leave a Comment »