Now I'm following the tutorials in the DirectX SDK. Since I have a WinXP on my PC, I started with DirectX9. The tutorials are generally well designed, I would like to say, for beginners. But there are some small problems in the document such as typos, etc. Reading the code may resolve these kind of problems.
However, if you want to really understand how the programme works, you'd better to type the write the programme by your self instead of just open the tutorial project and compile and run it or to copy the code into your project. That is because there are quite a few details when you miss it the programme will simple not work, and the worst thing is it is hard for the beginners to know where is going wrong as you generally can not run the programme step by step as usual to find it out: you simply see the final, bad, result on the screen. For example, when I modified you code to use a zbuffer, I fogot to give an additional flag to the Clear method, as a result, I got a quite strange result on the screen, I checked my code again and again and found the problem finally. I'm not aware of any way to debug this kind of problem, please tell me if you know.
I have just completed the first four tutorials which cover the basic topics such as initialize the D3D device, render the vertices, use matrices and lights. There is one thing that I do not understand, the programme runs fine when it is visible, but it consumes 100% of CPU time whenever the client rectangle is invisble: when it is covered by another window or when the window is minimized. I'm not happy with this but I can not explain why, I'm still investigating.
Basically, D3D9 programming is quite demanding.
Here you find my experiences and tips on programming C++ for Windows and Linux that I got from software projects I've been involved in.
Monday, January 25, 2010
Friday, January 22, 2010
Starting DirectX Programming
Purely as a hobby because DirectX makes you really fatastic visual effects. There is only one thing makes me unhappy: I have to work on a Windows and Visual C++.
I installed a vi, although it looks terreble under Window as compared with a native Linux vi, the editing is all the same efficient. This makes my life a little better.
The first objective is to master basic DirectX programming skills. It may take weeks to build my first "Hello World" DirectX application.
I installed a vi, although it looks terreble under Window as compared with a native Linux vi, the editing is all the same efficient. This makes my life a little better.
The first objective is to master basic DirectX programming skills. It may take weeks to build my first "Hello World" DirectX application.
Tuesday, January 19, 2010
A reallife story about return value
Today we detected a random failure in some of our regression scenarios. After an investigation in the traces, we found the problem actually came from a component we are using, which parses a string into tokens. The parser fails randomly when processing certain tokens.
As usual, the first suspect is a memory issue, but after a detailed inspection with gdb, we found nothing really harmful. Fortunately, the parser leaves a detailed error message when it stops and it seems that the function used to retrieve the token from the buffer encounters some problems.
Finally, after reading the user guide of the parser, we noticed that the function has to return a bool value indicating the parser if there is an error or not and it turned out this particular function does not have a return actually even it is defined to return a bool value.
In this case, the return value is a random value in the register. Actually, this is warned by the gcc.
Lesson learned here, always remember to return something for every branch in a function that is supposed to return something. Pay attention to compiler warnings.
-----------------------------------------------------------------------
Yet another story.
This time our soft encountered a failure. After investigation, the problem is caused by a misuse of the string::find(), similar to the following:
aPos = aStr.find(' ', 0);
if(aPos == string::npos)...
the aPos is declared as 32 bits unsigned integer, as the string::npos has value -1 but a special type string::size_type which is usually size_t, so the exact type depends on how size_t is defined by the compiler, the comparison will never succeed even if no space is found in the string on 64-bit systems, for example.
So the lesson is always use string::size_type for string positions.
As usual, the first suspect is a memory issue, but after a detailed inspection with gdb, we found nothing really harmful. Fortunately, the parser leaves a detailed error message when it stops and it seems that the function used to retrieve the token from the buffer encounters some problems.
Finally, after reading the user guide of the parser, we noticed that the function has to return a bool value indicating the parser if there is an error or not and it turned out this particular function does not have a return actually even it is defined to return a bool value.
In this case, the return value is a random value in the register. Actually, this is warned by the gcc.
Lesson learned here, always remember to return something for every branch in a function that is supposed to return something. Pay attention to compiler warnings.
-----------------------------------------------------------------------
Yet another story.
This time our soft encountered a failure. After investigation, the problem is caused by a misuse of the string::find(), similar to the following:
aPos = aStr.find(' ', 0);
if(aPos == string::npos)...
the aPos is declared as 32 bits unsigned integer, as the string::npos has value -1 but a special type string::size_type which is usually size_t, so the exact type depends on how size_t is defined by the compiler, the comparison will never succeed even if no space is found in the string on 64-bit systems, for example.
So the lesson is always use string::size_type for string positions.
Wednesday, January 13, 2010
A Programmer's Nice Day
For many years, I consider myself a programmer. But until recently, I found a job as a programmer. Things are going to be interesting, because as a programmer, you never stop learning.
This blog will be dedicated to the subjects related to my life as a programmer from now on.
This blog will be dedicated to the subjects related to my life as a programmer from now on.