Perhaps last entry, part #1: PPX, trailer and more

Due to various near-deadline circumstances, I had to postpone blogging in order to finish the game. Therefore I’ve decided to split this major update into two; the first being a standard blog post with content that should be dated a couple of weeks back, and the second being some pre-GGC, GGC and post-GGC talk (GGC = Gotland Game Conference, if you haven’t read previous posts). So without further ado:

 PPX (Post-Processing Effects) and multiple Cameras

We had this problem where effect occurring on one camera did not occur on other cameras (and ultimately the final render texture/screen image). Generally this is not a problem as you can just apply your PPX on the last camera in the chain, which was in fact the method we used throughout most of the development with out bloom and tonemapping effects. However the problem occurs when you need to access depth as render texture output by one camera is not passed to the next; instead, apparently, each camera operates on the original render texture, which means that only the effects of the final camera in the render chain is applied, all other being unnecessary computation. It appear to be a bug and I am not sure if it is just prominent in deferred rendering, but it was a problem as the depth fog we used required the depth of a former camera along with other specifications.

After some searching I found an elegant solution; browsing the Unity3D Forums I found a thread describing the same problem and a post for a fix (courtesy of Andy2222, post here). The poster explain in good detail what the problem and solution is, as well as a script file to fix it. Many thanks to Andy2222!

Dxtory (+ trailer)

While browsing around on TotalBiscuit’s YouTube channel and his about page, I notice that he listed his recording software and the entry was a program called Dxtory. I had never heard of Dxtory and I decided to check it out which turned out to be quite helpful. Dxtory is a video capture/recording software for PC with features and pricing similar to Fraps. I would consider Fraps to be the more “industry” standard when it comes to recording quality game footage but Dxtory in my opinion is way better. It is my understanding that traditional recording software like Fraps takes “screenshots” at a rapid rate to compose video, while Dxtory directly accesses the memory buffer. The result is that I can sustain higher framerate with Dxtory than with Fraps. Dxtory also has some sweet features such as splitting the recording to different drives so that write speed is not the limiting factor when recording. Dxtory however tends to produce higher file sizes but in return quality is somewhat better and for most high-quality recordings quality is more important than file size.

I used Dxtory to record footage for the Mechropolis trailer which can be seen below (or with this link).

The tough last weeks

We realized that we were not exactly on track with our intended progress after the beta. Already before the beta I had felt the vibes of lacking motivation running through the air and we had a few hard weeks before us. The work that awaited us were mostly bug fixes, balancing, touch-ups and general completeness. The game in a sense was already done, it just needed that extra sparkle to stand out. There was more than a few last-minute bugs though. More about this in part #2.

About Kenth Ljung

2012 Programming