Pages

May 21, 2013

I haven't used the PIMPL pattern so far. I remember reading about it once long time ago, but was just not convinced it's something I want.

And now I'm working in a codebase where PIMPL patters are abundant. My verdict? Yeah I don't like it. I just don't see the benefit of it in game programming. So what are the benefits of the PIMPL pattern? I can only guess these two:

clear separation between API design and implementation: for example, the grand master designer designs API and minion programmers implement those in hidden places

less header file interdependency = faster compilation time

I don't think #1 means a lot for game programming. Just like in any entertainment business, our requirements keep changing, so are a lot of APIs. Also hiding implementation from other programmers sounds just weird in this industry. We usually have the full access to any source code. After all, we are not library vendors.

I think the main reason why game developers are using the PIMPL pattern is because of #2. C++ sucks with compilation time blaa blaa... But there are other way to make the build faster and PIMPL is definitely not the fastest one I have seen. Then is it incredibuild, which is pretty expensive? No the fastest one(I have seen) is Unity builds, which is completely free.(duh)

So I don't see benefits of PIMPL at all. Instead, I see more disadvantages:

Code is harder to read: who likes to jump around different classes to see actual implementations? Maybe you do, but I don't.

Discrete memory allocation: you need an extra memory allocation to instantiate the pimpl object. I'd much prefer to have all my members in a class, so that there's only one memory allocation and it's straight-forward to find out the size of an object.

Another pointer dereferencoing = slower: sure. some people might say "it's not that slow." but I'm just nazi about it. one additional pointer dereferencing is probably about 4 cycles extra... but with the separate memory allocation for the pimpl object, there's more chance it would trash cache lines. You can probably avoid it by carefully controlling the allocation order, but it sounds like very tedious work that I don't want to deal with.

May 18, 2013

some random thought I had while sitting on a bench at a rainy park today....

I finally watched James Cameron's Avatar the other day on DVD. It was a good movie, but the DVD quality was not that great on my 1080p display. It's after all 480P right? Now people are used to 1080P, so DVD quality wouldn't cut it. (even youtube video looks better than DVD, jesus!)

So then what's next? will we need anything over 1080p? I believe the common belief was that our eyes can't process more than a few million pixels so going over 1080p would be waste.(1080P is about 2 million pixels) But apparently we can perceive way more than that.... So we will need more than 1080P.

But one day TV resolutions will overcome our eyes' capabilities right? Then can we stop adding more pixels on the TV? I don't think our eyes are the limit.. the manufacturing cost would be the deciding factor.. Say our eyes can only process 1,000 million pixels. But if we are given a TV with 4,000 million pixels, our eyes will see 4 pixels as one pixel. right? So it would be same as blending those 4 pixels into 1. Oh sweet! it's a 4X super sampling antialiasing! If it's gets 16,000 million pixels it's 16x SSAA.. I can't say no to this.. :)

But as I said, it might become too expensive to add that many pixels one day... but price of LEDs are going down everyday and smart people are making LEDs use less power. so that might not be a problem.... or it might become physically impossible to add more pixels one day? just like how we coudln't make single-core CPUs faster anymore? Maybe.... but still 576 Million pixels are long way to go....