1/20/2009

01-20-09 - Tuesday Random

You shouldn't put flags in the top bits of pointers any more, because there are things like /3GB and others that make your address space be top-down. *However* you can usually still put flags in the bottom bits of your pointers. If all allocations are 8 or 16 byte aligned you've got 3 or 4 bits of flags in the bottom of your pointers. I like to make a little class called PointerAndFlags that lets you get at the pointer part and the flag parts cleanly.

It occurred to me this morning that we almost have a "Game STL" at RAD. Jeff has a really good sort, and I wrapped it up in templates. I have my old vector (pretty trivial, really), and I recently screwed around with hash tables for Oodle which I could easily wrap in templates. Sort, vector and hash_map are 90% of the good stuff that I use in the STL. I could easily build my hash table on top of my vector, which means that there is only one type of object that does allocations, which is pretty cute.

Unfortunately I don't have time to really do that right, and there's not much motivation for RAD to do it. We couldn't sell it; nobody would buy it (even though they should - it's one of those things that actually has a ton of value, but everybody thinks they can write their own, and producers who do the funding don't understand the value even if the programmers do). It's also one of those things where people are foolishly unwilling to settle for compromises. If there's a very good available solution which doesn't make exactly the trade-offs that you would have chosen, many programmers go off and roll their own. And anyway, even if we could sell it, we shouldn't ; library code is kind of thing that really needs to be open source, so that a concensus can be formed and everyone's fixes can be integrated, etc.

There's something I've written about previously in regards to poker, but I've been thinking about it a lot recently in other contexts. It's that "tough decisions" don't matter. Basically if a decision is really hard and complex and interesting - then it's probably irrelevant. If the EV of both ways is roughly equal, you don't need to sweat over which choice to take, just flip a coin and take one.

I thought about this the other day watching some interview on the Daily Show where someone was saying how Bill Clinton would sit down with you for hours and talk about policy with you, and how he was a policy nerd and just loved to get into the details. Okay, that's awesome, it's way better than someone who doesn't want to learn or study or think at all, but it's not actually the crucial thing in a president. That is, you don't need a president who gets the really tough issues right. All that really matters is having a president that doesn't *grossly* botch the *easy* decisions.

I think I've written about this in game development and production meetings and such too. I've been in lots of design meetings where we'll get sucked into some long argument about some irrelevant detail where the designers and artists will go over and over for hours about whether the health indicator should be orange or red. The fact is, getting those details right is super irrelevant. There are so many other issues that you're completely screwing up that you don't need to get those little things right.

I was thinking about it just now in terms of evaluating algorithms and STL's and such like. For example with hash tables there are a lot of different implementation choices, you can trade off code complexity vs. speed vs. memory use vs. flexibility. The truth is, almost any reasonable point on that curve would be fine. The only thing that actually matters is that you avoid implementations that are *grossly bad*. That is, they're way off the curve of where the good choices are. Whether you choose something that's slightly faster or not is pretty irrelevant in the scheme of things. (like all of these points, obviously this is dependent on context - decisions that are usually irrelevant can become crucial in some conditions).

3 comments:

MH said...

Yeah, I see this useless quibbling all the time with newbies on game programming forums asking about spatial subdivision algos.

Just slap things into a grid (or 2 level grid-of-grids) and call it good. Cheap and easy to code.

Though, this is all just a subset of decide-now-refactor-later for me.

Bret said...

Not really the same, but related: it reminds me of painting the bike shed.

cbloom said...

Yeah, "painting the bike shed" is a good one, but it's actually something different. Actually that's a good trick in game dev and business meetings in general - producers and management types will latch on to the little nontechnical details because they can understand them, and it's good to let them contribute to that and feel like they're giving you brilliant ideas.

Like maybe you've come up with an awesome fur renderer so you pitch it in a meeting, but you leave it open for the management types to come with what character to actually do. Then they can get in a big debate about cheetas vs lions and feel all excited about it, then on of them can decide that you should make some kind of bad-ass monkey-man.

old rants