Friday, November 20, 2009

What you should know Whenever you see STL containers or string.

We all know that stl is great. It has fantastic daily-used data structures, algorithms and string. We've learned that we should use it instead of array or char*. Yeah, it enables us to avoid reinventing the wheel! and save lots of lots of time.

So what's the problem?

It's allocating memory.

It does NOT mean stl sucks because it needs heap memory. There is no problem as long as we know what we're doing. It's allocating memory when you use them and this could be an issue when you find your program is not fast enough and the reason for that is memory fragmentation, you know enough memory space but fragmented as hell.

For example, [BAD one, never do this.]

void Render()
{
string fps = string("FPS : ") + GetFPS();
DrawText(fps);
}

Now, I'm sure you see the problem. It will create countless small temporary memories and definitely affect overall memory usage. I know some of you use your own "new/delete" or "malloc/free" but that doesn't make big difference since it's going to make your memory pool fragmented and you need time for de-fragmenting to find enough space.

So what should we do?

Well, here are my own tips.

1. Try to reuse stl objects as much as possible.
- Put them into a class as member variables.
- "static" can be one solution if you are free from threads.
- Always "reserve" their space in advance to avoid unnecessary allocations.

2. For temporary local objects, try to use "stack" objects, not heap ones.
- Use array if you know the maximum size.
- Try boost::array if you really don't like to see brackets.
- stl::string is too tempting but for temporary strings, char[] can be much more efficient.

That's it.

I think this is my last post for 2009. I was reading my old postings last night and I really like them. lol. I sometimes learn many things from what I've written. In 2010 (oh wow! cannot believe I will live in 2010!), hope I will be a slightly better programmer than now.

Merry Christmas and Happy New Year!

Sunday, October 25, 2009

Updates are tempting, but are they safe? (about KB971090)

Last week, I had a task for fixing a bug related to a library from outside my company.

First of all, I found that we were using its functions in a wrong way so I made some changes to correct it. Of course, the way I fixed it is from a document of the library. It resolved the issue and worked well in my machine. But, it turned out that a few machines had another problem with my changes.

Luckily, we have source code of the library so I was able to look into it to find my mistake. However, I realized that they made a wrong assumption about some values and it caused the problem. Since I had the source code, I fixed the wrong assumption, compiled it and produced one dll file for our project. It was working just fine on my test machine as well as my own pc. Yeap, I have two machines and three monitors at work. :)

Anyway, the happy moment didn't last long though. Our build machine reported that it failed to test its final build with my newly produced dll. Our game couldn't even start with it but just showed a very simple system error dialog with a strange hexadecimal address.

From my programming experience, I know that this kind of problems could take forever if I just try to solve it by myself. I quickly noticed that I needed someone. Someone knows our project very well and understands my task. Yeah, I asked my lead programmer to help me.

We agreed that the changes I made is the proper way to do my task. The problem was why the dll working in my pc didn't work in our build machine. We found that the dll didn't work on his machine either. He was for sure that my machine had something different and it produced the dll having incorrect dependency for the other machines. So, what is it?

It took almost four hours us to find the reason. It was not because my machine is using 64 bits Windows and the build machine is using 32 bits one. It was not because of the project setting for the library. It was not even because I used their static version of project to produce dll. (Another good example why naming is so important. They named the project "static something" but it actually created a dll, "dynamic" linked library.)

When my lead and I almost gave up, I found that my Visual Studio 2005 had all the latest updates and the one in build machine didn't. It's just my habit that I runs "Windows Updates" or "Microsoft Updates" every day when I have a short break. This habit had never made any problems until this one happened.

It turned out that one of the security updates for VS2005, KB971090, made the problem. From google, I found that dlls compiled with the security update (KB971090) are not compatible with exe files compiled without it, if the machine which runs the exe doesn't have the update. To solve this problem, I simply uninstalled it instead of following the long solution which you might want to take if you have the same problem. I should mention that you need to check "View installed updates" in control panel to uninstall it. Yeah, it sucks.

Okay, here is what I've learned.

Keep the exactly same build environment with the other programmers including a build machine. Don't blindly get all updates without checking them.

Sunday, October 11, 2009

What are you assuming?

Last week, I was reading src code and found that it used zero as an initial value for a handle.

MY_HANDLE handle = 0;

But, it also used INVALID_HANDLE for the same purporse.
class A
{
public:
A() : m_handle(INVALID_HANDLE) {}

private:
MY_HANDLE m_handle;
};
Well, I thought that INVALID_HANDLE was zero. However, it turned out that it's not. INVALID_HANDLE was defined with some weird value. Anyway, the exact value is not important. The importatnt thing is how I know what should be an initial value for MY_HANDLE?

Suprisingly, I'm told that some code use INVALID_HANDLE as a VALID value and there is a legitimate situation that a handle of an object is INVALID_HANDLE. Wow. Okay, so the real invalid value which is supposed to be used as an initial value is zero, not INVALID_HANDLE.

Yeah, I know this kind of things always happens in real world as we always see this comment;"Fix me!". But, before we fix this, I'd like to ask this question.

How can we communicate with other programmers who will work with the code we write in future? More specifically, how can we show our assumption in the code? Or, do we even need to do it? why?

Why?

Because we are all different humans. All of us have an unique appearance, personality and assumption. It's perfectly fine with having your own assumption like your own habits. But, there is no guarantee that your assumption makes sense to others. That's why we should say it very loudly whenever we assume something.

How?

First of all, name it correctly. If it is a function returning a size of array, name it "GetSizeOfArray()". If it's a value containing your grade, name it "myGrade". If it's a constant value for an invalid handle, name it "INVALID_HANDLE" and use it as it is called. You can follow your "common" sense but don't hesitate to spend enough time naming something.

Second, use assertion whenever you can. It can correct your assumption quickly if it is wrong, it is crystal clear for other programmers and you can turn it off easily so that it doesn't cost anything in your retail build. Yeah, it's cheap (almost free) but powerful enough to save your project.

One thing I should mention about assersion is that you should not mix assertions with error handling. If there is an error and you need to handle it, just handle it without writing asserion.
See the below code.
assert(pRect != NULL);
if(pRect != NULL)
pRect->Draw();
The code says two things at the same time and they conflict with each other. It says "pRect must not be NULL." and "Call Draw() if pRect is not NULL". The latter one implicitly assumes that pRect might be NULL but the assertion says that pRect should never be NULL.

As Scott Meyers said that a female is either pregnant or she's not (in Effective C++), you should choose only one of them. Is it a part of program flow? or should it never happen? It's not possible to be partially pregnant.

Wednesday, September 23, 2009

Why small mistakes are disastrous?

I made a stupid mistake. very stupid one!
if(!IsOK())
OkDoIt();
else
NoWait();
Do you see the problem?
Yes, only one character ruined the whole process.

It should be like this:
if(IsOK())  // if(!IsOK())
OkDoIt();
else
NoWait();
If the function containing this problem is rarely called, it's a time bomb inside a briefcase. Even after you recognize something is wrong, it's very hard to find this kind of mistakes because it's such a small one like off-by-one error. almost invisible. That's why small mistakes can be much more disastrous than big ones which are obviously more visible.

Since code like the above is usually written very quickly and unconsciously without thinking, if you don't have right habits, you will make a mistake. It brings me the idea I loved but, apparently, forgot.
Good programmers have good programming habits.
I will never use ! in if statement. ever.

One more thing to remember.
Test every changes you made.Every single line.
Of course, I tested my changes before I checked in it. However, there were many changes and I just quickly checked a normal flow without checking all the changes I made. I was focusing on bigger and more complicated changes. I should have kept my changes small and checked in them more frequently.

Anyway, it's absolutely my fault and I will never forget it.
I really don't think anything I do is a mistake. It could be if I didn't learn from it.
- Fiona Apple

Thursday, September 3, 2009

Did you know you can change wingdi.h ?

I was having a weird problem with compiling src files for a few days.

I couldn't remember when it started but the compiler kept saying it could not find "ERROR" identifier. "ERROR" is supposed to be in wingdi.h like this.

#define ERROR 0

So I checked my wingdi.h file and it was like it.

#define LOG 0

It didn't take too much time to realize that wingdi.h was modified recently and all the other header files in the same folder had not been changed at all ever since the visual studio was installed.

I thought it was because I installed some other SDK or programs and I tried to figure out what made this situation. I had never imagined that I changed it. But, yes, I DID IT. OOPS!

I did "replace all" ERROR with LOG for my own project and wingdi.h was open at that moment. Visual Studio modified it and did not say anything when I saved and compiled it. There was no single error because I did not use ERROR in that project.

First of all, wingdi.h is NOT read-only so if you accidentally modify and save it, you won't see any warnning dialogs. Second, Visual Studio applies "replace all" for all opened files which are not in your solution even though you choose "Entire solution". Like the below picture.


So be careful otherwise you could waste hours even days like someone. =+=

Monday, August 24, 2009

Games for Windows Live.

Okay, I'm not going to tell you how bad it is since there are many articles about it. If you have nerver heard about its notorious features, check it out.

This was meant to be a Fallout 3 DLC review. or
Fallout 3 New Content, Adventures In GFWL

From those articles, I can easily imagine that user expereicens from GFWL are horrilbe, shameful and pity.

Actually, as a developer, I was okay with GFWL until I needed to deal with bugs from its newly updated 3.0 version. It's okay since debugging is just one of daily tasks we are doing.

However, I'd like to remember the lesson I learned from this experience.
Don't use an outside technology if its provider just distributes a new version and forces users to use it wihtout telling a single word to partner developers.
That's it.

Sunday, August 16, 2009

Network Programming with IOCP and Thread Pool - Intro

These days, I'm playing with network programming with IOCP and Thread Pool just for pure fun. :) After several days of reading MSDN, articles and writing experimental codes, I've realized that there are pretty big changes I need to catch up.

If you still use IOCP with GetQueuedCompletionStatus() and your custom threads (like me before), you might want to follow this series of postings I will update. I will provide sample code to clarify the right way to use them.

Also, I will benchmark techniques to each other so that hopefully I can give you some guidelines about When we need to use Which technique, or, at least, help you to avoid making the same mistakes I would make while I write this series.


First of all, let's see how many ways we can choose for using IOCP.

If we use custom threads to get I/O completion notification,

1. CreateIoCompletionPort() and GetQueuedCompletionStatus()

- Windows 2000 (Pro, Server) or later.

2. CreateIoCompletionPort() and GetQueuedCompletionStatusEx()
- Windows Vista and Server 2008 or later.



If we use Windows Thread Pool to get I/O completion notification,

3. BindIoCompletionCallback()

- Windows 2000 (Pro, Server) or later.

4. CreateThreadpoolIo(), StartThreadpoolIo() and etc

- Windows Vista and Server 2008 or later.

There also some APIs related to Thread Pool like QueueUserWorkItem(). Unfortunately but in a good way, Thread Pool system has been completely re-written for Windows Vista and we need to use those new and richer APIs to maximize our server performance.

If it's not confusing enough, I can tell you that there are also special socket functions which are Microsoft-specific extensions to the Windows Sockets specification. For example, ConnectEx(), AcceptEx() and etc. These functions are to fully utilize IOCP power for all IO operations including receive (read) and send (write).

Yes, it's gonna be a long journey but it must be fun! So excited! LOL


Thursday, June 11, 2009

Getting into the Game Industry.


There are many articles saying how hard getting into the video game industry is for recent grads. I thought it was not my case since I already worked for over 4 years in Korea as a game programmer.

I know most of Korean game companies are "nobody" here in America but I was lucky to have work experience at a company which is globally famous for its microtransaction model. Also, I was confident of my programming skills by seeing the other students in my graduate school. All those things made me think like "It shouldn't be a problem to get a job from one of my favorite game companies in America even before I graduate".


Well, it turned out that I was not an exception. It took me over one year to get an offer from one of the game companies I want to work for. I applied for over 40 programmer postions, had about 12 phone interviews, took 8 programming tests and had 1 onsite interview. Finally, I got 2 full time offers and accepted one from Canada, today morning. I'm not going to write all the details about how I got the offers but I'd like to tell you a few things which might be helpful.


1. Have a Long Term Plan

You should have a long term plan. a very long one. It is mainly because of a global recession in these days. I just saw the news that Crystal Dynamics (one of companies I applied to) is reducing 25 more staffers. In a bad economy, this kind of news is not surprising at all. I was very lucky since I was in a school while I was looking for a job. Getting a job would take much (very much) longer time than your estimation.

Find a part time job or volunteer positions. If you are an international student like me, you should do work to keep your OPT status. Do some independent projects by yourself or with your friends. Some of my friends are planning to start a startup for developing IPhone games. You can also consider about attending an education program. The bottom line is that it's important to have a clear answer to the question : "So, what have you been up to after you graduate?"


2. Keep Practicing & Studying

Most questions
asked during a phone or an onsite interview are NOT random. You can easily google them, prepare answers and practice by yourself. I found one great article in Gamasutra and it was very helpful for the onsite interview I had. If you were a programmer, you also need to check this article from Joel. Surprisingly, two interviewers actually asked the question from the article: "How many gas stations are in Los Angeles?". Prepare for it.

Don't forget to study basic things of your field. For programmers, some academic questions (yes,
Computer Science) are very popular even they are not directly related to how good your programming skills are. Math problems are also frequently asked if you are applying for a gameplay or graphics programmer. I had to solve two math problems on a white board in front of interviewers. This book was very useful for me to study math for game programming.

3. Never Stop Applying.

You don't need to rush but you shouldn't stop applying. Make a list of companies you'd like to work for and keep updating it. Check Gamasutra and CreativeHeads everyday and ask your friends about open positions at their work place. That's how I found over 40 positions.

Don't wait for a result of the interview you already had. Instead you should search more positions and apply for them. Don't stop until you actually sign on an offer letter. One of the companies told me that I passed all the tests & interviews and they were willing to hire me. But they just kept delaying giving me an official offer letter. Don't think you're hired before you really are.

That's all. It was a long and hard time but all of difficulties I've faced improved me a lot. Don't give up. Never stop.

Sunday, May 31, 2009

A call to action.


There was one time when I was hooked by all kinds of Software Development Methodology books. I was looking for "answers" to escape my stressful daily life as a programmer in Korea. Ironically (and obviously), the answer I found and liked was


Well, it's very easy to misread the line so please check the full article. By the way, the important thing was not the answer I found. I got it from the book "Professional Software Development" - Steve McConnell and there was the other article whose title was


Simply, it blew my mind. I had never thought about that I was one of those who were supposed to write "answers" which I had been searching for. This drove me to start my Korean blog. It's not very often updated but it seems some of articles helped other programmers and myself as well.

I've been thinking of starting my English blog since I came over here in the U.S. Finally, I have a bit long break time to do my personal stuff. This is my first post and I will try to fill this blog with articles "braced by labor and invention". Yes, I'm the programmer writing. Are you? :)