I am experimenting with ANN(Artificial Neuron Networks) for my game Sumerian Blood.
ANN is a type of AI that requires a learning process in order to find the desired behavior. In my case, I use ANN to control a character in the battle field.
I wished for the learning process to take as little time as possible, but I found I need to sometime leave my computer working the whole night to figure out things. However, I wasn’t able to do so because my application would run out of memory. It seems there was a memory leak(allocating RAM without releasing).
To keep it short, I wasn’t able to find memory leaks in my application, but I eventually realized that DirectX9 was causing the memory leaks.
It is not unheard of for DX9 to cause problems, especially when misusing it. DX9 with C++ does have all the limitations of a C++ program and it can’t protect the user from passing bad pointers, for instance.
So what was it? It turns out that when the computer turned off the display(as I was leaving it for the night), the Direct3D Device was in a non operational state or “The device was lost”. This in turn made DirectX9 silently fail. It didn’t crash, and it was returning Ok from all the API calls. I didn’t know anything was failing with DX9(The silent failure is documented by the way).
Another “nice” side effect of this was that DirectX9 was generating a lot of memory leaks. I don’t know why, but when I kept calling API methods while the device was lost, it did that.
The solution was to simply reset and restore the device, as mentioned in the documents. Even if I didn’t reset the device, if I tested for the device’s state(with TestCooperativeLevel) and stopped calling draw calls when the device was lost, it didn’t cause the massive memory leaks.
What is the lesson here?
It’s good to know that misusing DirectX9 or any other API, even in a non apparent way, may have severe implications on our program.
So we should read the documentation and follow the guidelines.
It sound obvious, but we sometime assume we know what we are doing when we actually don’t.