I haven’t been doing a lot of C++ in the past few years, and with the arrival of Windows 8 and the new C++11, I decided it is due time to refresh my knowledge! The APIs in particular that I want to use are Direct2D, DirectWrite and WIC.
Since I’m working in a start-up, I get to see (and participate in) the whole process – from planning, to development, to deployment, to support. One thing that’s been hurting us a lot is deploying our software to clients. Every dependency – whether it would be the Kinect Runtime, XNA runtime or the .NET framework – introduces a whole new set of problems.
For example, Microsoft do not provide a silent installer for the Kinect Runtime – so when you want your clients to install your software, they have to install 2 programs instead of one.
In Windows 8, when installers need to restart the computer, users do not get asked whether they want to restart now or later: the PC restarts automatically (even if there is a setting about it, auto-restart seems to be on by default). This means that your installer has to be resilient to this kind of impolite behaviour. And that happens when you make your installer start-up on log-in. Yet programs that require administrator privileges (such as installers) cannot be added to the start-up items. To solve that problem, the happy developer must split the setup in two: one part checks of the state of the installation that launches the second part, and another part that requires administrator privileges to actually do the work. And the list goes on and on…
As you can see, a single dependency in your app adds a long list of problems for your installer. That is why I wanted to try out purely native development on a pet project and thus reduce the dependencies to just the C++ run-time. Also, it would be a nice testbed to see if it is feasible to release future products that are written in C++.
Usually, when I’m learning a new technology, I implement a game of tic-tac-toe. The mechanics are simple, but it does cover the basics:
- loading and drawing textures
- game loop
- basic state machine
Now that we have the rationale, let’s list the things I want to have (and thus test) in the game:
- Full-screen game in release, windowed in debug build
- Intro screen where a simple picture/logo fades out – to test out animations and state machine
- Main menu with options to start a new game or quit
- In-game (gameplay) screen
- Pause screen
- Game over screen
Even a simple game of tic-tac-toe can provide a lot of work, especially if the goal is to have a polished product. Aside from the features, I’ve also taken the following decisions:
- I will avoid C++ exceptions and I will use HRESULT-s/nullptr instead. The code will be ugly, but it will be logical and predictable.
- I will not use a smart COM pointer. There is no reason to include ATL as a dependency, and I do not like the default _com_ptr_t. Plus, this will be a very small game, and most resources’ lifetime is bound either to the game itself or to a state, so they will have to be managed manually anyway (unless I write a content framework, which I won’t).
- I will minimize the use of c++11 pointers. The reasoning is the same as before: the ownership of resources is usually quite well defined, and most pointers will probably be to COM objects anyway.
- I will use C++11 features without backwards compatibility (e.g.
vector<shared_ptr<GameState>>). Compilers aren’t going back in time, and some of the new features do increase productivity. - I will use Microsoft-specific features – e.g.
__uuidofand#pragma once. This project is solely based on Windows APIs, and is never going to be ported to another compiler or platform; if a feature saves me some time – that’s fine by me.