Device Reset in Direct X 9

So, an issue that I have been battling for about a week involved resetting devices in Direct X. I wanted to cover how to do this and the possible downfalls you might run into while performing something that should be fairly straight forward to accomplish.

Q. When would you need to reset the device?
A. Anytime the device becomes "lost", this could occur when you resize the viewport, minimize the window, switch between fullscreen and windowed modes, and when in fullscreen, giving focus to another window other than the application which is running direct x.

Q. Why is this so difficult?
A. That is a great question, I am not sure. It seems like the Direct X interface should be smart enough to recover itself in the event that the device is lost. This is not the case. Not only is it not able to recover itself, it requires quite a bit of tender loving care when resetting occurs.

Q. What is required to reset a device.
A. After you have set up the code to create a device, your application loop must regularly check to see if the device is still active. This can be performed by calling the Device.TestCooperativeLevel() function. This function tests the device to determine if it is in a state ready to render. The possible outcomes of this function call are D3D_OK, in which case you may proceed to render your scene, D3DERR_DRIVERINTERNALERROR, in which case the device is in a bad state or the drivers are unable to process commands for some reason. The other two states are the important ones, these are D3DERR_DEVICELOST and D3DERR_DEVICENOTRESET. These indicate that the device is lost and needs to be reset.

Once either of the Device Lost or Device Not Reset errors are identified, code must be written to reset the device. The important thing to understand is that the device is very stupid about how it handles passing out resources. As such, you must ensure that the device reset occurs on the same thread as it was created. Additionally, Microsoft documentation indicates that the device releases all explicit render targets, depth stencil surfaces, additional swap chains, state blocks and default resources associated with the device. This means that any resource that is returned from the Device "Get" functions that return pointers to resources, must have their resource.release() function called on them to notify the device that the resource is no longer required. The down side to this is that any of these resources that will be required again once the device is reacquired, must be recreated before they can be used again.

The most frustrating thing here is that the Microsoft documentation states that these resources SHOULD be released, however, it is my experience that failure to release these resources causes the reset to fail, returning an D3DERR_INVALIDCALL. As a result, it really isn't just recommended, but a must, to ensure that all modules that request resources from the device have both a OnLostDevice and OnResetDevice functions that handle freeing and recreating these resources.

Another note, it is also a good idea to call the Device.EvictManagedResources function. This function removes any additional resources that were allocated using the managed resource pool. See this article for more information on the managed resource pool. Using the managed resource pool can also help prevent the need for the OnLostDevice and OnResetDevice functions for your modules, however there is a cost/benefit trade off here that must be understood and should be researched before choosing either method of resource management.

Once all resources have been released, we can reset the device. To do so, we must first build a set of Present Parameters similar to what we created when first creating the Direct X Device. This is the tricky part as there are many options here to set and any bad combination of these will cause the device to fail to reset. The important thing to note here is that you need some way for your application to know if it is in windowed mode or fullscreen mode when it resets (assuming that you want your application to have both a fullscreen and windowed modes). The reason for this is that depending on the mode, different settings require different values. For example, in fullscreen mode, you need to specify BackBufferWidth and BackBufferHeight values that equal a value that is equivalent to a supported display resolution. These can be retrieved using the EnumAdapterModes function. If the application is a windowed application, these values need to be set to the dimensions of the HWND object that is stored in the hDeviceWindow of the Present Parameters. Also, importantly, FullScreen_RefreshRateInHz should be set to the window resolution selected from the EnumAdaptersModes function in fullscreen mode, but should always be set to 0 in windowed mode, otherwise the reset will fail.

The rest of the parameters can be referenced here. Rules for setting each of them are listed. Be sure to verify that each of them are set accordingly depending on what mode your device is in.

Finally, reset the device by calling the device.reset(presentParameters) function. This will attempt to reset the device. If it was successful, it will return a D3D_OK and you should proceed with recreating all of your required resources by calling the OnResetDevice functions of your applications modules. If it does not, this is where the difficulty comes in. In most failure events the function will return D3DERR_INVALIDCALL, if this occurs then check your parameters to make sure they are correct. Otherwise, it is most likely due to a non-released resource.  Running your application using the debug version of the Direct X dll will improve the quality of the error message received from the Direct X driver. This may not be an option for you if your application is already pushing the limits of available frame rates.

I hope that this tutorial has been helpful. I know that when I went looking for information on how this stuff works, the tutorials were brief, mostly directed at solving specific problems and less about the actual theory behind the information. I cannot claim to be a Direct X expert and if any of the information in this article is false, as always feel free to correct me and I will update the tutorial.

Game Review - Enslaved Odyssey to the West : Ninja Theory : PS3

I purchased Enslaved without knowing much about the title. Mostly that it was made by Ninja Theory and that it would have the same motion capture and voice acting work as Heavenly Sword. I was impressed by the level of cinematography in Heavenly Sword and with my love for action/adventure platformers such as the God of War series, Dante's Inferno, Darksiders, and Prince of Persia, I thought that I would really enjoy this game. The screen shots and cover art seemed interesting enough and the premise was something different as far as I could tell from the run of the mill "You are the hero, and you will go defeat the bad guy".

In Enslaved you play as Monkey, a man who lost his parents when he was young and has lived in the post apocalyptic USA about 200 years after nature has reclaimed the city. You meet Monkey while he is trapped on a slave ship, something the game never reveals how this comes about. You witness the other main character in the game, Trip, escape from her pod and start the slave ship on a collision course into New York city.

After escaping the ship you find yourself enslaved by Trip, forced to act to her every command, otherwise she will kill you. If she dies, you die. This leads to an interesting dynamic, but one that is actually quite glossed over in the game. Monkey and Trip become fast friends, only infrequently having dialog in the vein of Monkey's dislike for becoming enslaved. Maybe he just finds Trip so attractive (which she is) that he is willing to be her slave, hoping for some sexual torture as a reward.

Regardless of this, the dialog between Monkey and Trip reminded me heavily of the Ubisoft reboot of Prince of Persia. Interlaced humor and witty banter is quite prevalent. As both a pro and a con, you do not however have to perform an action button press to hear this witty banter, it is just interlaced throughout the level game play.

This leads into the second important aspect of the game, the game play. This I also found to be very similar to the Prince of Persia reboot, except that the parkour aspects of the environment were too easy to traverse. There was no chance of falling in most cases and it seemed to that pressing a direction and rapidly pressing the x button was effective enough in avoiding any potentially hazardous ledges that may fall. Combat was somewhat unique in that you use a staff much like Beyond Good and Evil, but that there was also combined areas of over the shoulder firing from your staff's plasma cannon. Overall, playing on normal difficulty, combat was very easy for the most part. There were very few times that I found myself in a situation that I was worried that I was going to die. Even less of those times did I actually die. I believe my death count throughout the course of the game was about 10. Most of these were due to miss understanding of the levels layout or a lack of cover when being fired on by ranged bots. This could have probably been avoided had I used Trip's distract action more often.

Graphically, I can not praise this game enough on the level design and artwork that really brings this post apocalyptic environment to life. I am however, a bit disappointed in the amount of texture popping that occurs during the cut scenes. The game was developed on the Unreal III engine and the age of the tech shows. However, I have played quite a few games on the Unreal III tech that didn't have this problem quite as bad. Perhaps it was an issue over texture quality and loading time. I would have rather opted for a longer load time and waiting for cleaner cut scenes than to see textures pop during the middle of a cut scene camera transition.

Overall, I was very pleased with the game. The witty dialog made for an enjoyable play through. It was far too easy as I had stated, probably good for someone who is new to the action/adventure platforming titles. The title is a bit short, however, there is a bit of re-playability as you can return to previous chapters to collect tech orbs and masks as well as re-attempt to beat some of the speed based missions for achievements or trophies. I would have to give the game a 7.5/10 though for the issues stated above.

Tower Assault! Curse of Zombie Island

Working with Rogue Pirate Ninja Interactive LLC, we have completed our IPhone title, "Tower Assault! Curse of Zombie Island". We are very proud and excited to bring this game to the app store for purchase. You can purchase it here or from your IPhone or IPod Touch device.

Tower Assault! Curse of Zombie Island is a reverse TD style game where you control a horde of zombie pirates against the forces of an Evil Witch Doctor who has stolen your pirate loot and cursed your crew. You control them by firing brains out of a cannon.

The goal of the game was to provide small bite sized levels that varied in the goals and difficulty as the game progressed. We didn't want to make a simple puzzle style game though and have weaved a story of revenge into the over all game play.

I hope that you try Tower Assault! Curse of Zombie Island and enjoy it. I should have more time to start posting again now that the work on this title is complete, so look forward to that as well.