GameDevBlog

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.

 

sixty second shooter alpha version update day!

It's my goal to make Mondays the day on which I update sixty second shooter - and to reset the leaderboards, so we can all play king of the mountain each week. Last week the winner, hands down, by far, was Tomo, and he wins ... me implementing some of his features. Soon.

I've gotten some great feedback on the game already, but haven't been able to respond to that feedback yet, because I've been busy adapting to Chrome 15 and getting sixty second shooter into the Chrome Web Store.

This means it's easier to run! You just need to install and run Chrome 15, install sixty second shooter in the store and run it from there - you don't need to set environment variables or command line parameters.

Sort of.

But.

Actually.

You kind of do still need to set environment variables because the text rendering is still in development, which means to see, like, your score you still have to put NACL_ENABLE_PPAPI_DEV=1 in your environment variables.

For me, that's Control Panel->System and Security->System->Advanced System Settings->Environment Variables...->New... and then type in NACL_ENABLE_PPAPI_DEV and 1.

Sorry about that. I didn't realize font rendering was going to lag behind the rest of 3D - in the interim I'll put score information, etc, in the browser. I'll have that in by next week, if you want to wait.

This is supposed to be a developer blog, but so far I don't really have much to say other than to try it out and follow the instructions - so...does anyone have any questions about developing for NaCl?

Whoops

If you jumped through all the hoops to get sixty second shooter running, and it still didn't run, it could be because I provided the wrong link: I linked to the dev channel of Chrome, not the beta channel. The link is fixed now.

It could also be becuase you're running Windows XP, which doesn't do GL stuff unless you force it. If you're brave, you can pass --ignore-gpu-blacklist into the Chrome command line and WebGL and sixty second shooter may start working. You may also get a blue screen of death.

 

sixty second shooter alpha version launch day!

It is with a racing heart that I'm revealing an alpha build of the native client game I've been working on - to the world!  If the world is willing to jump through all the hoops one has to jump through to get it to run.

It just so happens that the current build in the Chrome Beta channel can run it, so I thought, hey, why not.

I'm eager to hear your feedback - if you're able to play it. In theory, it should run on any x86 machine that supports WebGL.  In practice, I've only seen it run on 64-bit Windows 7 machines.

The game is here: sixty second shooter test.

The hoops you have to jump through to actually play it are here: sixty second shooter support.

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.

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.

More Chrome Native Client Productivity Tips

I have a cross-platform build - since there's no debugger for Native Client yet, I made sure to keep the program I'm porting still running under windows, so I can still debug the bulk of my code.

Logging, logging, logging. Printf debugging is nigh-intolerable, but that's what I've got right now. When faced with a bug, I add instrumentation until it's narrowed down. Crash bugs are the worst, because they'll likely crash my logger, too, before all of the old logging messages have flushed - there I often find myself commenting out more and more code until the crash bug goes away...

I haven't figured out the voodoo that makes Chrome decide whether it's going to use the .nexe from the cache or a new one. So the first thing my program logs is __DATE__ and __TIME__, so I can make sure the program it's running is indeed the one I just built. And if it's not I clear the cache.

Version control. If I introduce a bug that has me tearing my hair out, I can go back to a previous version. I have to remember to check in often!

Using --jobs # with Scons. That cut my build time by 25%. (Trying to get precompiled headers to work actually slowed down my build enormously ... I'm considering metafiles at this point.)

Native Client Productivity Tip

During development, you obviously don't need to build every target every time - so why make your build 4x longer?

There's probably a better way to turn off the other targets - some scons magic, a Remove command maybe, you could put in build.scons - but the way I found was to go edit build_tools/nacl_sdk_scons/site_tools/nacl_tools.py and comment out the builds I didn't want, like so: Download nacl_tools.py (9.2K)

If anyone knows the scons magic, could you tell me what it is? Then I'll update this post.