GameDevBlog

Native Client OpenGL Tutorial - Updating to 0.5 / Chrome 14

BREAKING NEWS:  the _dev opengl stuff no longer works with the latest version of Chrome 14. You can read what to do about it here.

So, version 0.5 of Native Client came out yesterday, so I downloaded it and Chrome 14, and it takes a couple of tweaks to keep the Tumbler experiment working in it.  

They got rid of the per-project scons; so add \tumbler\build.scons to the build.scons in \example.

And set this variable in your environment - I did it by going into my windows system settings and turning it on for everything: NACL_ENABLE_PPAPI_DEV=1

Do that, and the project from the previous post should work again.

I've also added texture mapping to it - with the textures generated procedurally because I haven't tried to read a file yet. Anyone interested in hearing about that? It's pretty much no different from any other OpenGL simple texture shader. One thing that helped was taking the error output from the shader compile, queueing it in an in-memory log, and then Posting that to the browser when I could.

Native Client OpenGL Tutorial

Seems like everyone's talking about Chrome's Native Client these days.  It is pretty exciting stuff, in my opinion - C++ has been my go-to language for fifteen years, and now I can make it do stuff in your browser? Cool. I could take those old prototypes I've written and make them more easily available? Cool.

So I'm digging in. The OpenGL stuff is in its infancy - an untamed frontier - virgin territory. Exciting but daunting. Also, I've never used scons before, and I've only dipped my toes in OpenGL and JavaScript. If it wasn't for help from Jeff Ward, my new hero, I don't know if I'd even have been able to get the Tumbler demo working.

But I did, so let me tell you how I did it. Of course, this may become obsolete tomorrow. But there it is.

• I did the NaCl getting started tutorial. The only thing they didn't mention is I had to put Python in my path after installing it. 
• I got the Native Client code branch, which includes experimental\tumbler. Yeah, there's a big ol' deprecated there, which means all of this may become irrelevant, I guess.
• I created a Tumbler project in the native_client_sdk_0_4_907\examples folder, the same way as their hello_tutorial.
• I copied the experimental\tumbler files over my new Tumbler project.
• I discovered their includes have pretty full path names, so I had to go through the #includes and take the experimental\tumbler\ prefixes out. I don't know why they did it that way. I assume since they're Google they're Really Smart and have their reasons; I just don't know what they are.
• I added all the .cc files to the sources in build.scons 

sources = ['tumbler.cc','tumbler_module.cc','cube.cc','opengl_context.cc' ... etc.

• Added the gles2 library to the build, after the sources:

nacl_env.Append(LIBS=['ppapi_gles2'])

• Run Chrome 13 with command line parameter '--enable-accelerated-plugins'

Voila. Rotating cube. The gateway has been opened.

32-bit overflows and me

I don't know many who remember the 16-bit processor days. Back then, we used to always check for overflow conditions because we had to. These were my Magic Candle days, before Zortech came along and gave us access to protected mode - and what a relief that was. Not only did it catch bad pointer writes a huge amount of the time, but 32 bits - finally we can easily express a number higher than 65535!

At first, I kept checking overflow conditions anyway, out of habit. Which takes a while - never mind the CPU time, what about the programmer time?

It wasn't long before I stopped and said - "Wait a minute. Just what are the chances an overflow is going to bite me?"

Take, for example, an incrementing counter, going up every frame. When is that sucker going to overflow? A little quick math - 2 billion divided by 60 fps divided by 60 seconds in a minute divided by 60 minutes in an hour divided by 24 hours in a day ... it's going to take a year for that sucker to overflow.

So I got complacent. In fact - I would even get frustrated with coders on my team who spent time making sure their code was overflow-safe.

Decades later - just the other day - I finally got bitten by an overflow bug. I was using the high-resolution timer API in Windows (which ticks much faster than 60 per frame on most processors), ignoring the high 32 bits, and it worked on my machine, but my machine was not the machine we were demoing the game on publishers to - and because QueryPerformanceCounter is different from processor to processor, the demo machine would get all funky after playing for 15 minutes or so.

Whoops.

Am I going to beat myself up about it, though? Nope. Because this is the only time in my last fifteen or so years of coding that I remember getting bitten by a 32-bit overflow. And with the kind of coding I'm usually doing - prototyping - it is usually not worth spending the time to think about it. My expected value of return on time invested ... it's just not there.

(Though I also realize that in some applications - like where a malicious user could get at your data - it suddenly becomes very important again.)

What about y'all? Are there certain types of bugs or correctness that you just don't sweat about?