Posts Tagged ‘C++’

DirectX 12

January 17th, 2016 No comments

It seems appropriate to start with a ‘Hello world’-style triangle:


Ever since details of DirectX 12 began to surface, I became interested in learning about it as most of my recent programming has been done through C# rather than C++, and the last time I worked with DirectX was very briefly with version 11 which had more of an emphasis of creating an abstraction layer above OpenGL/DirectX than an actual engine and prior to that, DirectX 9.

My main problem was hardware capability as my 2009-released AMD 5870 was simply not compatible with DirectX 12, but after purchasing a GTX 970 the opportunity arose, bundled with a two week holiday off work which was particularly motivating as already doing 40 hours of full-time programming a week reduces my appetite for after-hour hobby code projects. Fortunately it’s now been two weeks since I’m back at work and I’m still going.


This is the current state of the project. Visually it’s not very exciting and if anything makes me look awfully novice at any rate. Right now I’m putting most of my effort into developing a solid back-end that is capable of dynamically allocating resources when I request them, taking advantage of DirectX 12’s parallel capabilities where possible.

The latest feature implemented is the text renderer, which has the ability to either render to screen space or to world space. When rendered in screen space, it remains the same size when resizing the window and any transformations applied are done consistently through a Transform class object which is overridden for 2D positioning.

Buffers are particularly unique in this case, where I try to pool as much data as possible for a low frame overhead. In the above image there are three objects – 2 “squares” and 2 text objects. All are combined into a single index buffer, single vertex buffer and have each reserved a single constant buffer slot.

At the risk of overextending this post and allowing for future updates I’ll leave it at that, and rather than just posting about any progress I might go into further detail on some in-depth rendering techniques in the future as well.

Categories: Me, Programming Tags: , ,

DNS Switcher

January 1st, 2014 No comments

I had a bit of play with streaming services today and was interested in getting Netflix working on a media server I’ve got set up. After some confusion, tinkering and satisfaction everything was eventually working. The only problem was that now Australian based streaming services were no longer available.

A workaround was to manually edit the DNS address on the device, but doing this with a TV remote isn’t the most sophisticated of methods. The next idea was to simply point the DNS address to the router and have that changed, much faster on a computer. There was still the repetition and problematic approach of having to log in and fetch one of the two DNS addresses aside from trying to memorise them.


The solution ended up being a little C# utility, which would log into the router automatically and perform the necessary changes using the built in features of the WebBrowser class using a very simple 2 button interface. All I got to do now is fire up the program, hit the show I want to watch and after the router resets I’m good to go!

It’s interesting to program something that not only works but actually solves a real-world practical problem to make life easier. Here’s hoping there’s more where that came from.

Categories: Programming Tags: , , ,


November 6th, 2013 No comments

The next topic is path finding. It’s a tricky subject with an RTS as I’ve found, as ultimately it’s the most complex system each individual unit must perform, therefore it is directly affecting how many RTS units the game can have at a time. The faster the algorithm, the higher the theoretical unit count on the same system. I’m pretty lenient here with my unit count since I’m not asking for a huge Planetary Annihilation /  Supreme Commander style RTS, neither am I asking for the precision systems of the Men of War series. I’m going to go with a target count of 100, so I’ should have plenty of CPU utilization room for pathfinding, assuming of course I don’t create a horrible algorithm.

Technical talk aside, I’ve recorded two videos that demonstrate two different versions of pathfinding. Both use Unity’s inbuilt nav-mesh to an extent, which from what I’ve read is a very fast pathfinding system. It didn’t take me long to figure out why, considering there is absolutely no collision avoidance built in which makes it a little less useful. The actual pathfinding itself however is good, and the agent system isn’t bad. The videos will be from a week old built, but it was a good time to record them as I was phasing out the old temporary system.

The only thing I didn’t like about the nav agents is the fact they rotate and move on the spot, giving a very weird sliding behaviour if your agent is meant to be a vehicle, so I’ve designed vehicle units to stop and rotate to a 15 degree zone of their target direction giving it a more natural approach.

Of course, the more important aspect was collision avoidance. RTS buildings can be placed at any time, in addition there’s lots of potential units all moving in different directions. My initial approach was to create a simply temporary system that paths around objects using cross products. This worked alright for pathing around single objects, but with multiple objects, the generated pathing started to become undesirable. I would simply set a temporary destination 90 degrees off a cross product from the unit position and the obstacle position.

The second method, a little less temporary was to implement an A* grid, and use this on top of the nav mesh. The avoidance path is currently not pathed all the way to the destination, meaning that after one obstacle a unit may have to figure a way past another in the distance. It makes sense to a degree as the pathing a long distance may be very processor intensive and may be wasteful considering obstacles can appear, disappear as well as move around.

At the moment the pathfinding works quite well with the avoidance system actually being more complete than the rest. The immediate change I can think of is sending a group move order without the units trying to pass around each other at the destination – setting a group destination pattern based on the relative position of other group units. At the moment, ordering a dozer to construct a building will set the destination to one of the four sides of the building – whichever is closest, after which construction begins.

There’s been quite a few nice additions since the videos, a big one being fog of war which will be fun to talk about, as well as a refinery/harvester/gold combination, of course relying heavily on the pathfinding. Another one being buildings now require a bulldozer to built them!

Categories: Me, Programming Tags: , , , , ,

Data Driven System

October 30th, 2013 No comments

Time for another update!

In this post I’ll be talking a little bit about the back-end of the game itself, so any pictures that are in the post won’t actually be showing the game this time. I’ve still included some to keep things interesting.

While planning for the project was minimal, I did think over the essentials around the time I started, and one of these decisions was to make the game somewhat data driven. This has multiple benefits, both for me and potential end users.

  • Game data is easy to add and remove as items are handled modularly
  • If something goes wrong it’s easy to track it down from the fail-safe importing methods
  • RTS units and buildings are much more dynamic – I’ll come back to that in a moment
  • Custom content (think mods!) is really easy to add
  • Code is much cleaner and structured

So let’s talk about a few of those points. I’ve decided that game content is handled from three different sources.

  1. Core game content (.NET Assemblies, code, core assets, etc.)
  2. Game Data (Units, levels, buildings that I created, etc.)
  3. Mod Data (Custom user created content)

A visual demonstration of the importation process is shown in the picture on the right. Core game files are loaded as per usual, then the data folder is unencrypted and uncompressed. Compression and encryption are here just to keep my own assets in check, and should I be outsourcing any 3D assets then you’d need to go through a bit of effort to actually obtain them.

The mod folder is actually loaded first, and therefore is able to override original content. Original content data is available in help files, so as an example, a player is able to replace the construction yard to use custom models or use the original buildings for tech references. The data and mod folder are actually the exact same format, it’s just that the former is simply packaged with the game in a less accessible way.

buildingFiles that provide the game with information are standard XML format which then point to any additional resources that the entity is made of. Currently there are only two formats, one for buildings and one for units. A level format might be added in the future, but it seems more appropriate to leave that as a binary file.

As part of the data structure, I have designed units and buildings to be somewhat in reverse order. Typically, a building may have a list of units it can create, or a building may have a list of new buildings that can be built after it. Instead, units refer to the string ID which they spawn from, as well as any tech requirements before they become available. Buildings are similar, in that they also have tech requirements.

As an example I have attached an image of the current barracks building. Note that the XML structure is very likely to change as there are some essential gameplay items that need to be provided, such as view distance, fire rate, damage, and what not. It wouldn’t be much of a fun RTS without combat would it? You can see that the building ID is listed at the top of the file, with basic properties below, tech properties then data files. Of course the order doesn’t actually matter, but that’s how I’ve structured it. You’ll also notice that the tech requirement of the BARRACKS building is the CONSTRUCTION_YARD, which means that it can only be built after the construction yard has been built. What isn’t visible is the upgrade XML nodes, but as these haven’t actually been implemented in-game they wouldn’t be much use yet anyway.

Upgrades can of course also serve as tech requirements for a building as they have their own string ID. It is currently planned to allow upgrades to replace the mesh of the unit or building, or even add to it if it’s a building, depending on if performance isn’t a concern (seeing as shadows would greatly increment the vertex count with all kinds of upgrades on screen). At this point the default texture formats of PNG/JPG are supported and OBJ models, but seeing as the asset loading is written in a modular way I’ll probably add a few more formats in the future such as TGA and 3DS.


Categories: Me, Programming Tags: , , ,

The Command Interface

October 25th, 2013 No comments

I figured a progress update every 3 days would be a fair update interval, giving me an excuse to slack off for a day (which thanks to some determination hasn’t been necessary yet) as well as give some headway in case I get stuck on a module that I plan to discuss, which shouldn’t happen for a bit as I should have enough content for two weeks already, assuming I don’t go off and make a huge post for some reason.

Either way, I figured the next topic I’d mention is the command interface – the bar somewhere on the screen that gives you pretty much half the control of an RTS game, probably a bit more so in a strategy game. There isn’t a huge choice where to put the interface, there’s basically three options.

  1. Put the bar on the left or right side of the screen, turning the play area into what’s more of a square but allowing a more equal area of visibility.
  2. Put the bar on the bottom (or the top?) of the screen, turning the play area into a more wide field of view, but depending on the camera angle this can limit visibility depending on the size of the interface. (Notice the “depending on” going on)
  3. Use a minimal interface which some of the newer C&C games have done, having essentially a transparent panel

While I’ve played a variety of RTS games including the C&C series, Age of Empires series, Company of Heroes, Men of War (more on that later), and a few more (trying to keep the list short!), my main influence are the old C&C games so I figured I’d put the bar on the right side of the screen.

 In the image below, the left is the Red Alert 2 ‘Allied’ command interface, the right is my current version. There’s a few design changes here which haven’t really been finalized. The style is very bland but it allows me to work with the core features of the interface. There are no tabs, and the power bar on the side has been changed into a numerical display. Buttons will only display items that the selected building can produce rather than at all times. Pages can be cycled left and right to remove the restriction of a limited number of buttons being active for a building. The green arrow button at the bottom will essentially be the ‘upgrade’ menu, which at the moment I’m still deciding if it will open a secondary dialog or if it will simply show upgrades in place of buttons.


The next specific item is the minimap itself. Initially, the minimap was rendered in real-time with a constant Camera feed rendering to a Render Texture in the corner. Adding on to that, I was rendering actual 3D geometry on a hidden minimap layer directly above objects, and objects controlled their own “icons”. This would, more or less render it on the minimap. Fortunately, after being somewhat happy with the other systems I was simultaneously working on, I decided to refine the minimap. I added dedicated classes – one to handle the command interface, which would handle the minimap, which would handle icons. The minimap now contains a list of active icons which are now only loosely controlled by entities, in the sense of creating, destroying and selection. Thanks to some helper functions I added, I’ve made it a lot easier to convert a position on the world to the minimap, and vice versa. These handy helpers lead me to add clicking on the minimap to move the camera, which through the class was only a single line of code.

Icons themselves are no longer 3D geometry either, and are now properly drawn quads, with the camera direction using the OpenGL line drawing functionality. The minimap render texture is now only rendered with a camera once in the first frame of the scene after which it is destroyed and stored. There is essentially no performance loss using this method over using static imagery and it allows me to modify the terrain without having to keep track of minimap layouts.

The new render method no longer keeps the camera in the loop.

The new rendering method no longer keeps the camera in the loop.

I also wanted to go into detail a little bit about the complexity and goals of the project. I’ve made somewhat of a lazy decision not to plan and document anything with fancy UML diagrams, which has lead to some moments of confusion when developing essential systems that worked together, but it has also allowed me to head astray and work on odd little features that appeal to me on the way. The fact it’s a hobby project prevents this very decision from being a recipe for disaster, but it also makes project scope a blurred outlook. In terms of set goals, I do at least want to get base building in with units pathfinding and essentially killing enemies. Whether the enemy is going to be an AI controlled commander or a human opponent with networking isn’t really something I’m focusing on at all yet. Should I design the ‘team’ component correctly then interchanging the two scenarios may actually allow both with very little code change. However, I’ll leave this to be determined from a few more hours of late night pondering, and ultimately another post!