Mike Acton

I'd been having some trouble displaying text in sixty second shooter. There's some stuff Google's working on that's still in development that worked well but I don't want to rely on it. A couple versions of Chrome ago, using browser text on top of the native client stuff seemed to hash my framerate - but either it was my imagination or they fixed it. Browser text is pretty decent now, particularly if your game isn't CPU bound - you can check it out by playing the game with the about:flags framerate counter enabled and turning the "browser text" option on and off.

But searching websites for how to arrange text left me with no clue how to make it look "videogamey" - but eventually, with some advice from Gregg Tavares and others, I found what I was looking for, and here it is.

For a lot of this, jsfiddle.net was awesome for just mucking around with a decent iteration loop. 

You can check this all out in the field, by the way, by going to the game sixtysecondshootertest.appspot.com and choosing 'view source' - (you can also see how I did the game's audio.)

I'm a rank amateur at this stuff, so if you know better ways, I'd love to hear them.

Web Fonts

Web fonts are cool. My wife picked out 'Comfortaa' for sixty second shooter. It does seem to add a second or two to the load time, which is a problem, but I'll work that out someday - the game really needs a loading bar.

Overlaying Text

I just wanted to overlay text on top of the game area, for a start. Could HTML even do that? I wondered. The old HTML I knew was only good for arranging witihin a single layer. Overlap wasn't its thing.

Eventually I tracked down the "position: absolute;" style in CSS. It's just what I needed - there's even a z-index if I want to control the order things are displayed, though I didn't seem to need it. It feels good just knowing its there.

For example, to put the player's score and whatever other useful in-game information in the upper-left hand corner...

Controlling Visibility

Here's another little tidbit: when I wanted to hide an element with javascript, the first thing a Google search told me was to set its style.display to 'None'.  One problem with that is it bashes whatever information was in the style.display before, whether it was 'inline' or '-webkit-box' or what. A better answer, with Chrome anyway, is to use 'style.visibility', setting it either to 'visible' or 'hidden'. This also keeps the element in the flow - other widgets won't move when it disappears. To wit.

Creating Elements On The Fly

I wanted the points you earned for shooting badguys to pop up when you hit them - the way to do that was to use the CreateElement javascript function. At first I kept track of them in a dictionary, but then discovered I could use the setAttribute() and getElementsByClassName() functions which allowed me to attach data to them and track them. Sorry, no jsfiddle for this one, check the game code.

Sometimes these would stick off the screen, and ugly scroll bars would pop in. Using overflow: hidden on them wouldn't fix it - so I used overflow: hidden on the entire page. Which will mess people up with screensizes smaller than 1024x768, but according to my stat reporting nobody's running that small ... so far.

Resizing The Game To Fit The Window

And that was all I needed, up until I wanted the game to resize with the window. Up until now I'd been doing everything in absolute pixels.

First, resizing the window is pretty easy: use the javascript onresize. (With native client, when you resize the embedded native client element, it calls DidChangeView on the instance. From there I resized my post-processing buffers as necessary.)

The hard part was putting text in the right place - particularly centered text. One way is to use absolute: position, left: 50%, text-align: center, width: arbitrarypx, margin-left: -onehalfarbitrarypx. (Resize that window to see it in action.)

But some of my text, I didn't just want to center it absolutely - I wanted it centered in the middle of the larger, left-hand pane. And it had all sorts of tabley stuff and radio button lists and doodads inside it. This was the biggest pain. This was where I broke out the new flex box stuff which is differently supported in different browsers ... on the bright side, since I'm only supporting Chrome, I only had to use -webkit-box. On the dark side, I discovered interesting things like it's hard to combine flex box with absolute position - look what happens (Chrome/webkit only) if you flex box a list at the bottom of the screen. (My solution for the lower nav bar was to use display: inline and lots of padding-right - they don't spread out exactly the way I wanted but whatev.)

For the box-centered-in-a-pane, I ended up faking it with padding. There's got to be a better way:

A Book

I learned almost everything I know about CSS from CSS: The Missing Manual... and a lot of Googling.

2ch’s latest efforts to make the unmoe moe has seen them manage to moefy the entire national borders of the UK, on the basis that she “looks like a girl worried about the size of her breasts.”

Other nations have been subjected to the same technique, with Chinese efforts in this area proving particularly successful, even if there is some evident disagreement over if and how to incorporate Taiwan…

This is not, however, a recent innovation:

See also the advent of Oniko for an outstanding example of more conventional moe anthropomorphisation.

A few months ago I’ve written an article named Where the top of the stack is on x86, which aimed to clear some misunderstandings regarding stack usage on the x86 architecture. The article concluded with a useful diagram presenting the stack frame layout of a typical function call.

In this article I will examine the stack frame layout of the newer 64-bit version of the x86 architecture, x64 [1]. The focus will be on Linux and other OSes following the official System V AMD64 ABI (available from here). Windows uses a somewhat different ABI, and I will mention it briefly in the end.

I have no intention of detailing the complete x64 calling convention here. For that, you will literally have to read the whole AMD64 ABI.

long myfunc(long a, long b, long c, long d,
            long e, long f, long g, long h)
{
    long xx = a * b * c * d * e * f * g * h;
    long yy = a + b + c + d + e + f + g + h;
    long zz = utilfunc(xx, yy, xx % yy);
    return zz + 20;
}

long utilfunc(long a, long b, long c)
{
    long xx = a + 2;
    long yy = b + 3;
    long zz = c + 4;
    long sum = xx + yy + zz;

    return xx * yy * zz + sum;
}

Related posts:

1. Where the top of the stack is on x86 I’ve noticed more than once that some programmers are confused...

nevver:

No More Problems in Poohville

Made by scientist Paul Vallett for his Electron Cafe blog, this funny cartoon is essentially about the differences between how science happens in the movies, and how science happens in real life.

On the one hand, I like it a lot, because the speed and ease of movie science does lead people to expect major breakthroughs to happen quickly, and makes them less critical of the sort of PR and journalism that tries to paint every new paper as a game-changer. In fact, you could probably make a case for movie science being one of the drivers that helps to create that bad PR and journalism to begin with. If decades of film and television have trained people to expect easy "Eureka!" moments, maybe they're likely to have less interest in nuanced results, or the fact that not all published science is correct. Unrealistic expectations matter.

On the other hand, well-done fiction is bound by reasonable constraints. There's not time for a "and then they do real science" montage in every movie. To a certain extent, I think this particular complaint might be a bit like wondering why nobody in Star Wars ever stops to pee.

A Redditor called “i_luv_ur_mom” posted this math teacher’s amusement, an equation that draws a lovely Bat-signal.

Do you like Batman? Do you like math? My math teacher is REALLY cool