One obscure trick to dramatically speed up build times under gcc is to set up meta files that include a block of .cpp files.
The time for a fullbuild on my project dropped from 20+ minutes to slightly under 5 minutes.
Of course, it suddenly becomes much easier to shoot yourself in the foot because statics and #defines start to exist outside the scope of a single .cpp file.
This can also work to your advantage with a gcc2.9x series compiler as it tends to create extra copies of template code in each of your object files. (Our binary size dropped significantly)
I am quite happy to announce that my company (or at least my team) is finally giving up Microsoft Visual Source Safe and we're switching to Perforce for source code and Alien Brain for assets.
With a little luck the transition will go smoothly on both the database end and the user end[0].
And if nothing else, perforce has Emacs integration, which goes along well with the fact that I've been teaching myself Emacs for the past month or so (no, I haven’t become a zealot and I haven't had any strange desire to write things in LISP, I still use vim, UltraEdit and MS Dev Studio[1]).
[0] There are artists, programmers, and producers involved. Something will go wrong.
[1] Ok, the only part of Dev Studio I’m still using is the ‘Find in Files’ command which has defaults that I love and seems to do some sort of data caching that makes it run extraordinarily fast. Of course, once we move on to an Xbox port, I’ll be using the compiler and debugger as well.
I've been working on this new project for long enough to explore the codebase. The team that's worked on the project up until now has done a reasonably good job, the primary problem is that the publisher keeps altering what they want from the project and demanding new demos to find out if what they've decided this week is what they really want. While this is their prerogative (that getting paid thing carries a lot of weight with managers) it tends to cause a lot of programmers to make poor short term code changes that never get fixed.
Our lead was going through the frontend/HUD code on Sunday and he found 12 different sets of code to draw crosshairs.
Time to teach some junior programmers how to refactor...
There's a funny line around 3:30am where you start to realize you're not going to get enough sleep, but it's too early to really consider going back into work. There's a funny catch-22 there. If I go to the gym in the morning it helps me sleep at night. But if I can't sleep at night I can't get up early enough in the morning to go to the gym.
Well, I've done my civic duty. I have served on a jury.
I have no respect left for the whole of humanity.
You know that insane desire to strangle someone who's being willfully stupid on a message board? It's much worse when the willfully stupid person is sitting across from you and you've wasted 5 days of your life to get to the point where they're being willfully stupid.
Short answer: hung jury, mistrial. Screw you, taxpayer! You'll have to foot the bill... again!
A while ago I was talking with someone who had observed that artists were much more willing to throw away unpolished work than programmers (e.g. feature X gets yanked because it detracts from gameplay more than it adds). I've developed a couple of theories on this difference:
1. An artist can frequently take screenshots & concept work from a project and use it to pad their resume even if the work wasn't included in the final project, a programmer can mostly wave their hands and say "It would've been so cool if we'd only had 2 more weeks to finish that feature" (note: this can actually work to your advantage very early in your career). If that feature was your most visible contribution to the project it can be particularly hard to let go of it.
2. Different programmers have different priorities. Some programmers are very good at prototyping features and creating the underlying technology. Other programmers are very good at polishing features and getting them ready for the end users. To a programmer who's good at prototyping, having the feature work robustly and quickly might mean that the feature is done. The manager doesn't see the robustness, the manager sees the lack of a slick UI or possible a few random bugs that can be fixed. Communication typically breaks down at this point and the feature gets axed. Note: this is often a failure on both ends. Don't go blaming your manager when you never tried to explain why your feature should be kept.
3. Programmers are highly competitive ornery bastards. We fight over everything. Go look at usenet. The lot of us should probably be in therapy.
I turn 27 today.
All things considered I think that even after having had multiple projects canceled, programming videogames has been a much more satisfying career than my childhood ambition of being an astronaut. Although maybe if I start learning to speak Chineese now I'll be able to go visit the moon before I die.