So here’s a couple of pics of the scheme that I devised…

An

A blury pic of the external battery

We took the next 12V battery we could get, and cellotaped some wires to it. We then twisted the other ends of the wires around the battery contacts of the remote, and wedged the old battery in to make it snug. Voila, one working car remote with external power-supply.

So, on to timers and clocks in DirectX.

Timing is everything

Clearly, animation, physics and many other calculations need to be based on some measure of time. Ideally we’d like to know how long since the last frame. We’d probably also like to know how long we’ve been running for, and we’d also like to know the elapsed time versus “game” time (wall-clock versus time actually spent playing).

So, the first order of business is finding out the current time. Windows has the Performance Timer, and it measures in counts. We can find out how many counts there are per second and thus convert all our timings to seconds. The following functions are of use to us:

        QueryPerformanceCounter( LARGE_INTEGER* currentTime ); // Writes the current time in counts into the address pointed to by currentTime
        QueryPerformanceFrequency( LARGE_INTEGER* countsPerSec ); // Get how many seconds per count there are

So, we can quite easily get the current time in seconds (not entirely sure since when, but hey it doesn’t really matter). If we store this value, and then get a new value some time from now we can easily find out a measure of the time between this. So our class will have a private member which stores the last time value we queried, and also the last delta we worked out. We’ll then have a tick member function to refresh this. On might like to call this every frame or something.

So, how about total time? We’ll store the time when we start the timer, and then we can get a delta between the very first time and now. To allow us to pause the clock, we’ll keep track of the time whenever we pause it, and whenever we unpause the clock we’ll increment a counter of the time spent paused with the delta between pausing and unpausing - then, if we want to ignore time spent paused we simply subtract that from the overall elapsed time since we started. We’ll also store the current time every time we tick. I can’t see much point from the way the clock is implemented in the Luna book, but I’m going to use the current time member in all the other methods, rather than re-querying the current time. My reason for this is so that we truly quantise time, rather than have slight differences part way through the frame. In all likelihood the timer is not accurate enough for this to be an issue, but we’ll be perfectionist.

It’d be nice to be able to reset our timer as well.

Text

Oddly enough, DirectX has built in text functionality, so why XNA uses sprite-sheet based text drawing is a mystery to me. I guess maybe the xbox does not have a comparable font engine to windows, and as such all xbox code needs to use sprite-based fonts. Makes sense I guess.

Anyhow, to do text you need to describe the font that you want, and then get DirectX to create it and return a pointer to it for you. Then you simply draw the text. I’m going to stick the code in my initialiseDirect3d() member function. The code you need to describe the font is the following:

        D3DX10_FONT_DESC font;
	font.Height = 24;
	font.Width = 0;
	font.Weight = 0;
	font.MipLevels = 1;
	font.Italic = false;
	font.CharSet = DEFAULT_CHARSET;
	font.OutputPrecision = OUT_DEFAULT_PRECIS;
	font.Quality = DEFAULT_QUALITY;
	font.PitchAndFamily = DEFAULT_PITCH | FF_DONTCARE;
	wcscpy(font.FaceName, L"Times New Roman");

	D3DX10CreateFontIndirect(this->device, &font, &( this->defaultFont ) );

Finally I’ll draw the text in my draw method, outputting the frame rate and last frame time, using the following method:

INT ID3DX10Font::DrawText(
    LPD3DX10SPRITE pSprite,  // Can be null
    LPCSTR pString,
    INT Count, // -1 seems to output the whole string
    LPRECT pRect, // can just use a zero width/height to position text if
    UINT Format, // you use DT_NOCLIP here
    D3DXCOLOR Color
);

• A swap chain (at least two areas of memory, one for drawing into, one for displaying to the screen).
• A RenderTargetView (a reference to the area of memory from the swap chain for drawing into).
• A Depth/Stencil buffer, and a view onto it. (Used to help decided whether any given pixel should be drawn).
• Bind the RT (RenderTarget) and Depth/Stencil views to an Output Merger stage.
• Set the Viewport (a sub-rectangle of the BackBuffer that we will draw to).

Naturally after we have set up this infrastructure we have repeatedly draw some sort of scene; we will get to that after we have discussed the topics above.

The Swap Chain

The Swap Chain is an object which manages a number of frame buffers for us, typically two or more. One of the frame buffers (that is, an area of memory which can contain an image we generate) is for us to draw into, another is what is currently displayed on screen, and if needed, one can introduce more frame buffers, but we won’t look at that for now. We’re going to create a Swap Chain with two frame buffers in it, and it will allow us to “swap” them, so that after we have finished drawing, we can display what we have just drawn on the screen and begin drawing the next frame in the frame buffer that was just on screen.

What I have done, is added a couple of pointers, and a member function to the protected section of my Form class:

                // We do our directX initialisation in here
		virtual bool initialiseDirect3d();

                ID3D10Device	*device;
		IDXGISwapChain	*swapChain;

The definition of the initialiseDirect3d() method is as follows:

	DXGI_SWAP_CHAIN_DESC scDesc;
	scDesc.BufferDesc.Width = this->width;
	scDesc.BufferDesc.Height = this->height;
	scDesc.BufferDesc.RefreshRate.Numerator = 60;
	scDesc.BufferDesc.RefreshRate.Denominator = 1;
	scDesc.BufferDesc.Format = DXGI_FORMAT_R8G8B8A8_UNORM;
	scDesc.BufferDesc.ScanlineOrdering = DXGI_MODE_SCANLINE_ORDER_UNSPECIFIED;
	scDesc.BufferDesc.Scaling = DXGI_MODE_SCALING_UNSPECIFIED;

	// Set it up so there is no multi-sampling on the back-buffer
	scDesc.SampleDesc.Count = 1;
	scDesc.SampleDesc.Quality = 0;

	scDesc.BufferUsage = DXGI_USAGE_RENDER_TARGET_OUTPUT;
	scDesc.BufferCount = 1;
	scDesc.OutputWindow = this->formWindowHandle;
	scDesc.Windowed = true;
	scDesc.SwapEffect = DXGI_SWAP_EFFECT_DISCARD;
	scDesc.Flags = 0;

	UINT createDeviceFlags = 0;
#if defined(DEBUG)  || defined(_DEBUG)
	createDeviceFlags |= D3D10_CREATE_DEVICE_DEBUG;
#endif
	HRESULT createSuccess = D3D10CreateDeviceAndSwapChain(0, D3D10_DRIVER_TYPE_HARDWARE, 0, createDeviceFlags, D3D10_SDK_VERSION, &scDesc, &(this->swapChain), &(this->device));

	if ( FAILED( createSuccess ) )
	{
		MessageBox(0, L"CreateDeviceAndSwapChain FAILED", 0, 0);
		return false;
	}

	return true;

Finally I have added a call to initialiseDirect3d from our Run member function, just after the calls to ShowWindow() and UpdateWindow().

The Render Target View

In DirectX, resources (such as the backbuffer) are bound to pipeline stages (such as the output merge stage), but not directly. First we must create a View of that resource, and that view will be bound to the pipeline stage. The backbuffer was created when we created the D3D10 Device and the Swap Chain, now we need to create a view of it that we can bind to pipeline stages.

In order to do this, we must get a pointer to the backbuffer as an ID3D10Texture2D instance, and then create an ID3D10RenderTargetView. We do not need to keep the ID3D10Texture2D pointer after we have used it, but we do need to keep our pointer to the ID3D10RenderTargetView, so we’ll make it a member of our class, in the protected section.

		ID3D10RenderTargetView	*renderTargetView;

To our initialiseDirect3d() member function we add a few lines of code to get the back buffer, create the render target view, and release the reference to the backbuffer afterwards:

	// Get a reference to the back buffer
        ID3D10Texture2D *backBuffer;
	this->swapChain->GetBuffer(0, __uuidof(ID3D10Texture2D), reinterpret_cast(&backBuffer));

        // Create the RT View
	this->device->CreateRenderTargetView(backBuffer, 0, &(this->renderTargetView));

	// Release the reference to the backbuffer.
        if ( backBuffer )
	{
		backBuffer->Release();
	}
	backBuffer = NULL;

Just a few more steps to go…

The Depth/Stencil Buffer

The Depth/Stencil buffer is another area of memory, which is used to inform the Depth and Stencil tests respectively. These tests help the GPU know whether or not to overwrite a given pixel in the back buffer. We’ll probably talk about them in more detail later. We’ll need to add two more pointers as members to our Form class: one for the actual memory buffer (we’ll add it as a ID3D10Texture2D), and one for the view onto that buffer (we’ll add it as an ID3D10DepthStencilView).

		ID3D10Texture2D			*depthStencilBuffer;
		ID3D10DepthStencilView	*depthStencilView;

Next we add some code to our initialiseDirect3d member function to create the buffer and the view.
First we describe the buffer:

	D3D10_TEXTURE2D_DESC depthStencilDesc;
	depthStencilDesc.Width = this->width;
	depthStencilDesc.Height = this->height;
	depthStencilDesc.MipLevels = 1;
	depthStencilDesc.ArraySize = 1;
	depthStencilDesc.Format = DXGI_FORMAT_D24_UNORM_S8_UINT;
	depthStencilDesc.SampleDesc.Count = 1;
	depthStencilDesc.SampleDesc.Quality = 0;
	depthStencilDesc.Usage = D3D10_USAGE_DEFAULT;
	depthStencilDesc.BindFlags = D3D10_BIND_DEPTH_STENCIL;
	depthStencilDesc.CPUAccessFlags = 0;
	depthStencilDesc.MiscFlags = 0;

Note that the SampleDesc field values must be the same as for the render target.

Next we create the buffer and view:

	createSuccess = this->device->CreateTexture2D(&depthStencilDesc, 0, &(this->depthStencilBuffer));
	if ( FAILED( createSuccess ) )
	{
		MessageBox(0, L"CreateTexture2D FAILED", 0, 0);
		return false;
	}

	createSuccess = this->device->CreateDepthStencilView(this->depthStencilBuffer, 0, &(this->depthStencilView));
	if ( FAILED( createSuccess ) )
	{
		MessageBox(0, L"CreateDepthStencilView FAILED", 0, 0);
		return false;
	}

Finally, we need to bind both the RT view and the Depth/Stencil view to the Output Merger pipeline stage. Effectively this tells the GPU which render target, and which depth/stencil buffer to use for now.

	this->device->OMSetRenderTargets(1, &(this->renderTargetView), &(this->depthStencilView));

The Viewport

The last bit of infrastructure we must set up is the Viewport. This is effectively a window within our back buffer, to which drawing is constrained. We’ll use the whole backbuffer for now. But you could use a smaller viewport for effects like picture-in-picture, etc. Simply, we describe the viewport, and then set it; we do not need to keep it around or anything, as it is really part of the state of the GPU.

	D3D10_VIEWPORT viewPort;
	viewPort.TopLeftX = 0;
	viewPort.TopLeftY = 0;
	viewPort.Width = this->width;
	viewPort.Height = this->height;
	viewPort.MinDepth = 0.0f;
	viewPort.MaxDepth = 1.0f;

	this->device->RSSetViewports(1, &vp);

Let’s do something with it all…

Right, now that we’ve done all this hard work, let’s do something with it… how about painting the window blue you ask? Great, that’s just what I was thinking. We’ll introduce a new member function to our class called Draw, and we’ll call it from the message handler, in the part of the if statement that we have set aside for consuming the time that we don’t spend handing messages.

All we do is clear the render target with a specific colour, clear the depth and stencil buffers, and then tell the swap chain to Present, which makes it swap the back buffer with the one currently displayed on screen.

In the protected section:

		virtual void draw();

And the method definition:

void Form::draw()
{
	float color[4] = { 0.0f, 0.125f, 0.6f, 1.0f };
	this->device->ClearRenderTargetView(this->renderTargetView, color );

	this->device->ClearDepthStencilView( this->depthStencilView, D3D10_CLEAR_DEPTH|D3D10_CLEAR_STENCIL, 1.0f, 0 );

	this->swapChain->Present(0, 0);
}

And that’s really all there is to it. Once again, I’ve uploaded the code, as a zip file this time. Also, don’t forget to link against d3d10.lib and d3dx10.lib.

I’ve bought some books on C++ and DirectX and have started working through them. The book I am working through at the moment Introduction to 3D Game Programming with DirectX 10, has based its demos on a small, bespoke application framework. Whilst this is all well and good, I find that I learn by doing, by writing the programs myself, rather than reviewing demo code. So, I’ll be starting from scratch, writing my own, similar application framework, following the lessons in the book, and blogging about it here. So, onto “Step one, create a window”.

Creating the Visual Studio Project

To start with, create a new Win32 project in Visual C++. Do this by selecting File -> New -> New Project, then by selecting Win32 in the Project Types pane, and Win32 in the Project Templates pane. Give it a name, and a location, and click OK. You’ll then be presented with a wizard. Click Next, then tick the box which says “Empty project”. You should now have a solution with a single project in it. The project should contain three folders “Header Files”, “Resource Files” and “Source Files”.

Figure 1: Creating a new Win32 project in Visual C++

Now we can start coding. We’ll start by making a flat, single-file program which throws up a window, and then we’ll go about abstracting the window functionality into a class. We could have got Visual Studio to create a whole bunch of code that creates the window for us, but that skips the learning process, and gives us over-complicated code.

Create Your C++ File

I’ve uploaded the code for the first stage of our lesson here.

I’ll go through it section by section, although I’ve stripped out the comments because I’m giving an explanation here.

#include <windows.h>

This tells the C++ compiler to include the headers for the Win32 API. This gives us all the declarations we need to write code against the Win32 API. Angle brackets indicate that the file is in one of the include path directories. Alternatively we could use speech marks, and give a file name relative to our project folder.

HWND MainWindowHandle = 0;

This declares our window handle. It’s a variable which will hold an unique id for our window when we get windows to create it.

bool InitWindow(HINSTANCE hInstance, int showCmd);
int Run();
LRESULT CALLBACK WndProc(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam);

We declare the prototypes for some functions:

• InitWindow will be the function which initialises our window and throws it onto the screen.
• Run will handle the message queue.
• WndProc is called while handling the message queue, and actually handles the messages we want to handle (like when the window closes)

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR pCmdLine, int nShowCmd)
{
    if ( !InitWindow( hInstance, nShowCmd ) )
        return 0;

    return Run();
}

This is our entry-point. WinMain, is the windows equivalent of main(). All we do here is initialise our window and, if it was successful, start handling messages.

bool InitWindow(HINSTANCE instanceHandle, int showCmd)
{
	WNDCLASS wc;
	wc.style			= CS_HREDRAW | CS_VREDRAW;
	wc.lpfnWndProc			= WndProc;
	wc.cbClsExtra			= 0;
	wc.cbWndExtra			= 0;
	wc.hInstance			= instanceHandle;
	wc.hIcon			= LoadIcon(0, IDI_APPLICATION);
	wc.hCursor			= LoadCursor(0, IDC_ARROW);
	wc.hbrBackground		= (HBRUSH)GetStockObject(WHITE_BRUSH);
	wc.lpszMenuName		        = 0;
	wc.lpszClassName		= L"BasicWndClass";			

	if(!RegisterClass(&wc))
	{
		MessageBox(0, L"RegisterClass FAILED", 0, 0);
		return false;
	}

	MainWindowHandle = CreateWindow(
		L"BasicWndClass",
		L"Basic Win32 Window",
		WS_OVERLAPPEDWINDOW,
		CW_USEDEFAULT,
		CW_USEDEFAULT,
		CW_USEDEFAULT,
		CW_USEDEFAULT,
		0,
		0,
		instanceHandle,
		0);						

	if ( MainWindowHandle == 0 )
	{
		MessageBox(0, L"CreateWindow FAILED", 0, 0);
		return false;
	}

	ShowWindow(MainWindowHandle, showCmd);
	UpdateWindow(MainWindowHandle);

	return true;
}

This is where a bunch of the magic happens. In the first “paragraph” we create a structure and fill it out. This structure defines a class. If you think of the window you see on screen as a class, we’re defining that class here. (see the cpp file for the specifics, its got comments in). The next part registers the class with windows, effectively we’re saying “hey Windows, here’s a window class definition that I want to be able to make instances (windows) of.” After we’ve registered the class we can create a window from it with our call to CreateWindow. The parameters are the class name, the window name, the window style, the x, y, width and height, the handle of the parent, the handle of the menu, the handle of the windows application instance, and potential extra parameters. If that worked we continue onwards to show, and update the window. Simple.

int Run()
{
	MSG msg = {0};

	while ( msg.message != WM_QUIT )
	{
		if ( PeekMessage( &msg, NULL, 0, 0, PM_REMOVE ) )
		{
			TranslateMessage(&msg);
			DispatchMessage(&msg);
		}
		else
		{

		}

	}

	return (int)msg.wParam;

}

This method effectively loops until we get a WM_QUIT message. Some people like to do it slightly differently and use GetMessage instead of PeekMessage. GetMessage blocks if there are no messages, which is not particularly useful if you want to use the time not spent handling messages to update your game, or draw your scene. If you’re implementing a renderer that runs in a separate thread, you would probably want to use GetMessage. The calls to TranslateMessage and DispatchMessage do some processing on the messages (like converting key values), and dispatch the message to your WndProc respectively. We’ll eventually expand the else bit to draw a scene and stuff.

LRESULT CALLBACK WndProc(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam)
{

	switch ( msg )
	{
		case WM_DESTROY:
			PostQuitMessage(0);
			return 0;
	}

	return DefWindowProc(hWnd, msg, wParam, lParam);
}

Here we handle the messages, in this case if we get a WM_DESTROY (from someone going ALT+F4, or clicking the X), then we post a WM_QUIT (which will end the loop in Run) and return.

This code should run and you should get a window with a white background, and the title “Basic Win32 Window”.

It’s Refactoring Time

What we have is all well and good, some simple code to create a Win32 window. What we have, however, does not represent particularly good design; it would be far better if we abstracted this code into a class which we could instantiate from WinMain, and call Start, or Run or something. So what we’ll do is cover the process of abstracting our code into a class - we’ll call it Form. I’ve uploaded the following files which, once again, give you the full source: stage2.cpp, form.cpp, form.h.

Lets talk through Form.h: First we include a few things like the Win32 API, and the string and exception classes from the STL (Standard Template Library, the primary C++ framework).

#include
#include
#include

Next we declare our class, that is we write down a skeleton of the class, with all the member variables, and prototypes of all the member functions:

        class Form
	{
	public:

	protected:

	};

Inside “public:” we have:

                Form(HINSTANCE appInstanceHandle);
		virtual ~Form(void);

		int Run(int showCmd);

		void SetCaption( std::wstring windowCaption );

		void SetWidth( int windowWidth );
		void SetHeight( int windowHeight );

And inside “protected:” we have:

		virtual bool initialiseWindow(HINSTANCE appInstanceHandle);

		virtual LRESULT WndProc(HWND windowHandle, UINT message, WPARAM wParam, LPARAM lParam);
		static LRESULT CALLBACK MainWndProc(HWND windowHandle, UINT message, WPARAM wParam, LPARAM lParam);

		HWND formWindowHandle;
		HINSTANCE appInstanceHandle;

		int width;
		int height;
		std::wstring windowCaption;

I won’t put the full code for Form.cpp in here because it’s very similar to what I’ve talked about already. Rather I’ll talk about the changes I made. The first funny thing that you’ll notice is that we have to member functions which look like they deal with messages. One is MainWndProc, and it is static. The other is WndProc, and it is an instance member. You’ll see in Form.cpp that when we define our window, we pass a pointer to MainWndProc, instead of WndProc (like we did earlier). MainWndProc then handles the WM_CREATE message, gets a pointer to the class instance, and forever more delegates message handling to the instance member WndProc.

        wc.lpfnWndProc			= &Form::MainWndProc;

and the code for MainWndProc:

LRESULT CALLBACK Form::MainWndProc(HWND windowHandle, UINT message, WPARAM wParam, LPARAM lParam)
{
	static Form* me = 0;

	switch ( message )
	{
		case WM_CREATE:
		{
			CREATESTRUCT* createStruct = (CREATESTRUCT*)lParam;
			me = (Form*)createStruct->lpCreateParams;
			return 0;
		}
	}

	if ( me )
	{
		return me->WndProc(windowHandle, message, wParam, lParam);
	}
	else
	{
		return DefWindowProc(windowHandle, message, wParam, lParam);
	}
}

I’ve also moved the CreateWindow call (as well as ShowWindow and UpdateWindow) to the start of the Run member function - meaning that the window doesn’t show until we actually want to start handling messages for it.

You’ll notice in Form.h that I’ve added some members for width, height and windowCaption so that we can customise these aspects of our window. There are setter functions for these:

void Form::SetCaption(std::wstring windowCaption)
{
	this->windowCaption = windowCaption;
}

void Form::SetWidth(int windowWidth)
{
	this->width = windowWidth;
}

void Form::SetHeight(int windowHeight)
{
	this->height = windowHeight;
}

And you can work out how I’ve changed the call to CreateWindow.

That really just leaves our constructor, and empty destructor:

Form::Form(HINSTANCE appInstanceHandle)
{
	windowCaption = L"Abstracted Win32 Window";
	width = 800;
	height = 600;

	this->appInstanceHandle = appInstanceHandle;

	if ( !this->initialiseWindow(appInstanceHandle) )
		throw std::exception("Could not initialise window.");
}

Form::~Form(void)
{
}

You’ll also find that stage2.cpp is far simpler because now all we have to do is create our Form, set its properties, and then run it.

Conclusion

We’ve learned how to create a Win32 window, and also how to wrap that up in a class. The implementation I’ve show here isn’t at all fancy, but it works and it illustrates the principal. I’ll be working on it in the future as I work my way through learning DirectX. That said, having written this article I’m not too sure whether I’ll keep up with writing detailed articles for the rest of my journey, probably just short notes on what I’ve learned - I really don’t have time for more.

Please leave any comments below :).

http://quazen.com/arts/visual-arts/gundam-mecha-monument-towers-over-tokyo/

1. Select / Cut / Copy / Paste - Tap and drag in notes and mail, and you immediately start selecting text, Tap and hold in safari and it selects an entire block of text for you. When you have a selection, a little context ballon comes up to give you options like, Copy, Paste, etc.
2. Advanced audio controls - it used to be hard to scrub through a track, especially if it was long because the precision on the slider was not very good. Now, if you start scrubbing, but move your finger down (away from the slider itself) it makes your scrubbing more precise. Also, in audio books there is a little button which lets you back up by 30 seconds, and a speed control, so that you can slow the audio book down.
3. Landscape keyboard in notes - very nice for those of us with larger fingers / thumbs, who like a bit more spacing between our keys.

Overall my impression of iPhone OS is that it is catching up quickly, in terms of general features that Windows Mobile has had for a while, but as it does, it revolutionises the usability of the feature - selecting text, and positioning the cursor are two such examples, where Apple have really thought about the issues inherent with controlling a small device with a blunt instrument like your thumb.

Here endeth the fanboyesque rhetoric.

As it turns out it needed a bit of work, but boy did they do a good job! The scooter used to struggle to hit 55km/h on the flat, now it exceeds 60km/h with ease; there is a lot more power up in the top end so that I can power up hills a lot faster, and down hill I can push the speedo as far round as it will go (~70km/h, but I can’t be sure because the numbers only go up to 60). The brakes have also been replaced and tightened, so they work a lot better, and don’t jam on any more, and with a new rear tyre I have more confidence in the wet and around corners. It is like riding a new scooter and it has definitely been a highlight of my week.