Happion Labs GameDevBlog

Google Analytics is cool

Google Analytics is something Erik Erwitt set up for me that I knew nothing about.  

Just realized it let me find out this:

All of the machines I have access to happen to be running at least 1600 width resolution - the game looks good with them.  Little did I know a quarter of the visitors don't run that wide, and aren't seeing the logo / instructions / leaderboards off the bottom of the screen.

Okay, escalating the priority of screen resizing.

Antialiasing with Native Client

I could just as easily call this article "how to antialias with OpenGL ES" - I was fairly surprised to find that there was no out-of-the-box support for antialiasing in ES. It took me back to the early Playstation 2 days, before people figured out how to antialias cheaply there, and the early slew of games for it that had that jaggy Babylon 5 look.

Fullscreen antialiasing - where we render to a frame buffer twice the width and height of the screen and then downsample, killed the framerate.

It was suggested that I use FXAA. Unfortunately, FXAA seems to require sRGB color space, which isn't supported out-of-the-box with ES either. 

I thought to myself, man, this must be a solved problem, with all those iOS developers out there. So I googled a bit, and discovered that they fake it - either by putting alpha into the mesh or the texture.

Well, turns out I'm not even using textures in sixty second shooter (for the most part), so it was fairly trivial for me to put white textures in with alpha'd out edges for a lot of my meshes. And, on my machines, anyway, the cost was nothing - I guess becuase one texture lookup was free since I was also doing a color calculation in the fragment shader. So, win!  Looks like AA with no cost to framerate.  

Before:

After:

In other news, sixty second shooter hit 200 installs today, and I've gotten a few "conversions" - people actually signing in! If it maintains that conversion rate once Chrome 15 launches, I'll call it a success.

Features vs Framerate

Something I've been deliberating lately - I've done console development for so long I've never had to worry about different performance characteristics on different machines.

One nice thing about web development is I can keep track of statistics about the games that are being played and what framerate they're seeing.  Good news - seems like most people so far are playing with better machines than my laptop. (Though that may be an early adopter thing.)

So, for them, I'd like to turn on some of the cooler features I've worked on - in particular post-process glow and blur. On my machine, it makes things run just a little too slow - when most of your frames are <33ms but once or twice a second you get a 66ms zinger it's worse than running at a consistent 50ms.

So...assuming I don't come up with any genius optimizations...people with machines like mine should have post-processing turned off.  Or play in a smaller window.  It would be really nice if the game could detect that and adapt appropriately - "Am I running below 30?  Turn these features off!" - but what would that look like to the player?  Some players would be playing along with the effects on, and then they'd get a bad frame or series of frames in some gnarly stretch of game, and then suddenly the effects would turn off.  It would look like it broke, like a bug...

Games back in the early days of hardware acceleration used to do things like that, but I think these days PC games have mostly moved away from that - these days they make a best guess and stick with it and let you adjust settings if you want.

So, for now, I guess that's what I'm going to do - I'll run with the full suite of effects and let the players turn them off if they want better framerate. But that's putting a lot of responsibility in the hands of the player - they'll probably have a better time if they turn off the glow and play at 60, but will they realize that?

So, I don't know. What do you guys think?

Native Client really works

Reports are in - sixty second shooter runs on Windows, Mac, and Linux. The same cpp code, all platforms. It really does what it says on the tin. I don't even have access to Mac or Linux machines here, so I'm pretty ecstatic that it runs on systems that I haven't even tested. Back in the day, it was a rule of thumb: if you haven't tested your code on that platform, it doesn't work. Times have changed!

One note, though: for now, don't use clock() to do precision timing, there are currently bugs with it.  gettimeofday() seems fine.

 

Knuth for Programmers: Sums and Products

(Here's an article I started writing but never finished. I'm never going to finish it, most likely - I've returned the book to the library, but I thought it still might have some value for someone.)

A friend recommended I read Knuth. As I slog through it I discover a lot of it is written in "math" - a language I haven't spoken in over twenty years. When I look at code, I can understand it fairly easily - but when I look at summation notation, it takes a while to parse.

So, that's weird. "The Art of Programming" is written for mathematicians, not programmers.

I discovered the best way to parse it to make sure I really grok it is to rewrite it in code. And I figured others might benefit from the results of my exercises. So, without further ado, the figures from Art of Computer Programming Section 1.2.3 - Sums and Produts.

In this C#-like pseudocode, I'll use 'integer' for an honest-to-God integer that could approach infinity and be well beyond the capacity for a computer to store, 'real' for an honest-to-God real of infinite precision.

No guarantee any of this is 'right', btw. And the true value for me was in doing the work myself - not in being able to look at and understand this code later. 

(1)

delegate real aFn(integer j);
// here we're expected to pass a function for a that simply indexes into an
// array

real sum( aFn a, integer n ) // sum elements of a from 0 to n
{
    real accumulator=0;
    for( int j=1; j<=n; j++ )  // Knuth's a array starts at 1
    {
        accumulator+=j;
    }
    return accumulator;
} 

It's no wonder Knuth wrote in math - it's much more compact. For the next one, we have to imagine our magic computer that can store an infinite real can also iterate infinitely and return.

(2)

delegate real aFn(int j); // pass a function that indexes into array
delegate bool RFn(int j);  // R predicate

// here a is a function that returns an element of an array
real sum( aFn a, RFn R )
{
    real accumulator=0;
    for( integer j=0;;j++ )    // magic computer that iterates infinitely
    {
        if( R(j) )
            accumulator+= a(j);
    }

    for( integer j=-1;;j-- )    // don't forget the negative integers
    {
        if( R(j) )
            accumulator+= a(j);
    }
    return accumulator;
}

To make sure my code was correct, I wrote it using floats and ints to iterate from int.MinValue to int.MaxValue. Took a long time to execute.

Hey, and I just realized that (1) could also be written:

delegate real AFn(integer j);
real sum( AFn a, integer n )
{
    return sum( a, delegate bool one_to_n(integer j) { return 1<=j && j<=n; });
} 

(2.5)

sum( a, delegate(int j) { return j>=1; } )  // == a[1] + a[2] + a[3] ...

(3)

// function prototype for limit
delegate real aFn( integer j );
delegate real RFn( integer j );
delegate real sumFn( aFn a, RFn r );
real limit( real nApproaches, sumFn summed, int lowJ, int highJ );

sum( a, R ) == limit( INFINITY, sum( a, R, 0, n )) +
    limit( INFINITY, sum( a, R, -n, -1));

(4)

delegate real a(integer); // index into array a
delegate real b(integer); // index into array b
delegate bool R(integer); // is this element of a one we want to sum?
delegate bool S(integer); // is this element of b one we want to sum?

sum( a, R ) * sum( b, S) == 
    sum( delegate( int i ) 
        { 
            return sum( delegate( int j ) 
                { return a(i)*b(j); },
                S );
        }, R ); 

is true

(5)

The first bit of (5) is trivial - the second ... "the reader should study this example carefully."

// sum of permutation of range
delegate real aFn(int j); // pass a function that indexes into array
delegate bool RFn(int j);  // R predicate
delegate int pFn(int j);  // p permutation 

real sum( aFn a, RFn R, pFn p )
{

    real accumulator=0;
    for( integer j=0;;j++ )    // magic computer that iterates infinitely
    {
        if( R( p(j) ) )
            accumulator+= a( p(j) );
    }

    for( integer j=-1;;j-- )    // don't forget the negative integers
    {
        if( R( p(j) ) )
            accumulator+= a( p(j) );
    }
    return accumulator;
}

sum( a, R ) == sum( a, R, p );

It's obvious once you can read it.

(6)

sum( a, n ) == sum( a, delegate(int) { return (1<=(j-1)) && ((j-1)<=n);} ) 
  == sum( a, delegate(int) { return (2<=j) &&(j<=(n+1);},
        delegate(int) { return j-1; })

An example helps me grok 6.

aFn a = delegate(integer j) { return j; }
n = 2

(1+2) == ((1+1-1)+(2+1-1)) == (2-1)+(3-1)

Makes perfect sense. I hope that's going to be as important as Knuth makes it out to be.

(7) Yikes. After taking a stab I realized I don't know if a sub-i sub-j means a two-dimensional array or if we're supposed to multiply i and j together or what. Guess I'll google 'interchanging order of summation'.  Ah. Two-dimensional array.

delegate real a2dFn(integer i, integer j);

sum( delegate(integer i) 
    { return sum( a, S, delegate(integer j) { return a2dFn( i, j ); } ); }, R ) ==

sum( delegate(integer j)
    { return sum( a, R, delegate(integer i) { return a2dFn( i, j ); } ); }, S );

And, how about another example...the notation's a tad different here, but...
http://people.revoledu.com/kardi/tutorial/BasicMath/Sum/Double%20summation.htm

And I'm going to punt on 8 (which seems obvious), 9 (which seems like a worm can), and 10 - I may come back later.

(11)

sum( a, R ) + sum( a, S ) ==

sum( a, delegate(integer j) { return R(j) || S(j); }) +
sum( a, delegate(integer j) { return R(j) && S(j); });

I'm starting to think Knuth has Asperger's, by the way.

 And, well, there it is. That's all I finished. 

Tip for working with cutting-edge Chrome features (such as Native Client openGL)

So, that was weird. Suddenly, out of nowhere, the opengl sample I was working on for native client stopped working. So I backed out of my code. Still didn't work. Checked my other samples. They didn't work either. Looked at Assaf's Ogre3D sample. Even it didn't work. Started checking my flags and browser settings. Everything looked hunky dory.

Turns out that when you're subscribed to the Chrome developer channel, your version of Chrome will auto-update to whatever the latest offering in the channel is. And it turns out that to keep up with changes in the API, Chrome changed. Normally useful and good for security, but a problem when I'm developing - if Chrome silently updates itself behind the scenes, with breaking changes, I'm going to assume it was something I did.

So - is there a way to turn it off? No.

BUT - I can use Chromium, the open-source sibling of Chrome - its build history is kept on line here. The version I wanted was here - the file I was looking for was chrome-win32.zip. After unzipping that into a Chromium directory in my root I was able to work again. So I'm going to stick with Chromium builds from here out, until I'm done working with Google classes that have the "_dev" suffix.

Hey, you web developers: where do I start?

So I'm thinking about doing a small game in Native Client. To be able to support leaderboards and some social whatever and monetization I'm going to have to do some server-side stuff. But I've been a console programmer most of my life: I've never done server-side stuff. So I've been looking at various options until my eyes glazed over. Google's App Engine makes OpenID authentication easy ... Amazon EC2 is easily scalable ... taking my own web-site and bumping up the account type is cheap ... there are lots of samples in php, but I don't know php ... I do know a little python ... and I'm fluent in C# ...

And ... start on my Windows machine?  Run a different OS with VMWare? Or just start coding on my hosted box or cloud instance?

What do y'all think?

Text Rendering in Native Client

This "simple_font.cc" under-development example of using fonts is in the Chrome sources. I'm lucky I found it. It was surprisngly easy to take the image data and make it into a gl texture and continue to do everything with the 3d client - I'm guessing a 2d client and 3d client wouldn't play well together, but didn't actually try it. So far it's slow, though - I seem to be spending about ~20 msec on text alone - not sure how much of that is drawing the text and how much is uploading the texture - I'll do some profiling soon - and I haven't tried glMapTexSubImage2D() yet, from these tips.

http://src.chromium.org/viewvc/chrome/trunk/src/ppapi/examples/font/

 

Another Chrome Native Client Crash Tip

Sometimes I'll write some code that crashes my game in Native Client and changing the code back doesn't help.

It seems that Chrome can be made somehow unstable when a crash occurs - I'm not sure exactly what the voodoo is, but shutting down Chrome and then going into the Windows task manager and ending the GoogleCrashHandler process makes things all better. 

(FYI - I'm doing all my development under Vista.)

 

Chrome Native Client Game Loop

It wasn't immediately obvious how to get my game running at a real framerate - the main thread needs to handle messages from the browser, and it does this by overriding a handle message call in the Instance class - unlike a good old Petzold-style windows app which can process the message queue on its own terms. Bottom line, you need to give up control of the main thread so the Pepper API can do its thing. 

So, I should put my game on another thread, right? Well, so far, the Pepper API isn't happy about being called from other threads. And the GL stuff doesn't seem to support moving the gl context from one thread to another a la wGLMakeCurrent yet. 

To get up-and-running, quick and dirty, I had the javascript regularly call the native client with a "tick" command. That was as slow as I expected.

What people seem to be doing for now is putting their game tick on a callback from the page flip, something like this:

void GameFrame(void* data, int32_t result)
{
    // ... update logic ...
    // ... render ...
    renderSurface.SwapBuffers(pp::CompletionCallback(&GameFrame, data));
} 

And now we've got some speed going!

A little work, and you could start logic updating before the swap is finished, for more more speed.