Console coding is hard

There’s a very interesting interview with Tim Sweeney at Team Xbox. It’s quite old, so chances are you already read it, if not - do it now. The part that caught my eye is where Tim says that programming for multicore architectures is, just, hard. What’s more, from their experience it seems that in this generation, writing an engine system designed for multicores takes about double the effort as single threaded.

Know your assembly, part 2

It’s interesting to examine code generated by C++ compilers, if only for nostalgia value. It turns out that compiler (well, MSVC) is pretty smart usually and employs same tricks we used when squeezing cycles out of software renderers years ago. For example it’ll almost always use _xor reg, reg _instead of mov reg, 0. Eons ago, on 8086 it was one cycle faster IIRC (sadly, cant find great Agner Fog’s instruction sheet anymore).

Breakpoint 2008

BP 2008 finished. Visit the official page for results and releases. The most interesting from gamedev perspective was probably a PS3 demo sponsored by Sony - Linger in Shadows. It was done by fellow Polish demosceners and judging by screenshots looks might impressive. Good job! [Edit] Movie links already at Pouet.

Know your assembly

Consider this simple code snippet, where we call copy constructor on an uninitialized piece of memory:void CopyConstruct0(int* mem, int orig) { new (mem) int(orig); } I didnt really bother with creating special version of this routine for fundamental types, after all this version: void CopyConstruct1(int* mem, int orig) { *mem = orig; } should result in same code as the one above, right? WRONG. In the first case compiler (MSVC) tests memory against null first.

RDE STL - fixed vector, first draft

Uploaded first draft of fixed_vector class to RDESTL (well, right now it’s just a different storage type, to increase code reuse). It needs some cleaning up and I’m not really satisfied with the shape of final interface for the moment, but the general idea seems to work. Basically, it’s exact equivalent of vector class, but all the memory is allocated statically on the stack. Capacity is generally fixed and shouldnt really grow (TODO: add methods to record watermarks).

Debugging heap corruptions

If I would have to choose family of bugs I hate the most (I would have to be under the gun obviously, as it’s a little bit like choosing your favourite illness) I would be inclined to go with heap corruptions. They’re silent, random, hard to reproduce and track down. Today I’ll describe my small collection of simple tips that helped me to stay sane during debugging sessions. First of all, let’s list the most obvious heap problems:

GDC 2008 notes

If you werent lucky enough to visit GDC this year, dont despair. There are already first notes from various sessions appearing. Make sure to visit Xemu’s (Rob Fermier’s) site, he has notes from most of the most interesting presentations up. Hopefully soon full proceedings will appear at GDC site. PS. Assassin’s Creed team numbers are crazy… 50 coders at the peak, 15-20 for AI alone. That’s more or less size of our entire team :) [Edit] More GDC goodies from Adam Martin (MMO focused).

Debugging file leaks - the easy way

Ever had problems with opening file that surely is present at given path? It most probably is the case of “too many open handles” problem. First of all, make sure it really is the reason, it should be easy enough with our new friend – pseudoregisters, just examine error code. The most common reason for this are file leaks (file is opened, but never closed). Files are “normal” Windows resources so you can use tools like htrace for analysis.

Pseudoregisters in MSVC - spreading the word

Very interesting article at CodeProject. Shame to admit, but I’ve been working with Visual Studio for years and it’s new to me. Good way to track down MSVC hardcore freaks in your company – see who knows about it. Old comments ed 2008-02-18 22:19:16 looks like undocumented feature to me :) fyi: recently I’ve also discovered a nice feature in debugger called “automatically expanding data”. You can edit file “autoexp.

More new/delete overriding fun.

Consider the following code snippet: struct Foo { void* operator new(size_t bytes); void operator delete(void* ptr); }; struct Bar : public Foo { void* operator new(size_t bytes); void operator delete(void* ptr); }; [...] Foo* b = new Bar(); delete b; Can you see a problem here? Yes, there’s no virtual destructor. It will not manifest itself (at least under Visual Studio) in an obvious way if you do not do anything in derived class’ destructor.

Advanced Windows Debugging - review

I bought Advanced Windows Debugging book last week. Shortest review would be: if you’re serious about developing big applications for Windows platform - just get it. There are chapters that were of less interest for me (yet?) - security or interprocess communication, but everyone will find chapters that justify every price. I found parts about heap/stack corruption, resource leaks and Vista especially valuable (visit http://advancedwindowsdebugging.com/ - I think there’s a sample available for download).

Links

Links for today: Geoff Keighley - Behind the Games - every episode feels a little bit like Dreaming in Code, just it’s set in the gamedev industry. My favourite article is about Trilobyte, but all of them are definitelly worth reading. Foxit Reader - PDF reader that basically can do everything that Acrobat can, only it takes 3MB instead of 60 and is like 100x quicker. First thing I do at every new machine is to uninstall Acrobat and get this one.

Demoscene tribute - Tran

This note is easier, because Tran has his own Wikipedia entry. I still consider him to be one of the most hardcore PC coders. My friends had a chance to meet him at Mekka/Symposium copy-party, and he actually visited Poland afterwards (he was travelling the world at that time and he had Polish roots). It felt a little weird, as he actually was one of my scene idols in times when I was only starting.

How to Damage the Morale of Your Staff

This note is a collection of posts from certain gamedev forum. I tried to select some of the more reasonable examples, so hopefully lonely manager who wanders here one day can learn something (if you’re from management - read carefully and sin no more). It’s a little sad, because most points look obvious and I didnt even put most of the creepy ones (ie, buy a new shiny Ferrari based on the royalties, the day you fire 50% of the crew) as people guilty of those: a) dont read, b) are beyond hope.

Insomniac's secret... and Dunbar's number

There’s an interesting thread at NeoGAF where folks wonder what’s the secret behind Insomniac releasing high quality product every year. It’s a very interesting read in itself (if you filter out some typical gaming forums posts), but I was especially intrugued by reference to the “magical number of 150” aka Dunbar’s number. Basically, it’s the highest number of individuals with which one can maintain stable social relationships with. More than that and you’ll most likely require more restricted rules, laws and formal structures.

Dell XPS M1530 Review

When I think of notebooks I always recall my first GDC visit. I guess it was in 2005, I went there with another programmer from CDPR. One thing we both noticed after 2 days was that we seemed like the only people there without notebooks. A little bit like poor relatives at the family dinner. It was funny at times, like watching a table with 5 Japanese folks, all typing furiously, not paying any attention to each other.

Protothreads in pure C

Now that’s some smart code. K& R would be proud.

Demoscene tribute - State of the Art

Yeah, I know, I know, I was supposed not to write about famous demos, in some cases, however, I cant help myself. State of the Art/Spaceballs is one of my favourite productions and maybe the best demo ever made. I appreciate it even more now than I used to in my scene days. I was graphics freak back then and preferred productions with hardcore code (like Rage demos mentioned previously). Problem with most of them is that they age quickly.

Walking the stack - one more way

Recently I’ve been trying to move MemTracer from experiment category to something that’s actually usable in real world scenario. It requires more work than I expected, but it’s slowly moving forward. One of the first problems I encountered was StackWalk64 function. It works nicely, but when called very often it can cause noticeable slowdowns. Walking the stack can be done manually by ESP/EBP traversing, but on Windows XP/Vista platforms it’s actually easier to use undocumented RtlCaptureStackBackTrace function.

Optimistic note

Two links for a good beginning of the week: Where The Hell is Matt? - site of Matt Harding, aka “that guy who dances”. Matt is fellow game developer, who one day decided to travel the world and… dance. He made the first video and it became popular enough to grant sponsorship for the second trip. Watch both, they’re very simple, yet amazing. You just cant help, but think that world’s a beautiful place after all.