Text Editors

Programmers spend most of our time in front of a text editor. Whether it is a standalone editor, or one integrated in an IDE, that’s just what we do.

Back in MS-DOS days, my editor of choice was QEdit, later renamed to The Semware Editor. I loved its configurability, and remapped pretty much everything in it to suit my preferences. Around that time I was also working on Unix systems and used vi there, although only for short editing sessions. I had been exposed to Emacs multiple times (starting with MicroEmacs on the Atari ST), but I could never get comfortable with its crazy keyboard combos.

After Windows 95 came and became my regular environment, the best choice was Ultraedit. Very soon, Microsoft Visual Studio became the compiler and IDE of choice for Win95 development, and its built-in editor proved quite powerful, so I would use Ultraedit for editing files that were not C++. Continue reading

On Freemium, playstyles and evil game design

In a couple of Gamasutra blog posts, Adam Saltsman (of ‘Canabalt’ fame) ranted against what he feels are ‘evil’ game design systems. I characterized his arguments as ‘hysterical’, which is perhaps a bit unfair since rants are meant to be hot. Anyway, at some point I felt compelled to write a long reply, and I’m reposting it here. I’ve edited it only slightly, so it’s possible that some of it is confusing outside of the context of the original discussion.

My guidelines are not for gamers; they’re for humans. My guidelines are not about styles of game or difficulty of game; they’re about treating players with a modicum of respect.

Now, we agree that all players and all humans should be treated with respect. But there is no inherent lack of respect in ensuring that your game encourages players to pay if they like the game and want to enjoy more of it. If anything, you are asking players to respect YOU as a creator by paying something for the enjoyment they derive from your work. Short of a pure donation model, this encouragement must affect the product you create in some ways. That doesn’t make the creator greedy, which seems to be Adam’s characterization of the monetization process.

Continue reading

Stage3D Vertex Buffer formats

If you played with the Stage3D spinning cube sample I linked in the previous post, you will notice one thing: the vertex colors in the vertex buffer are given as 3 floats (red, green and blue). This is rather wasteful in most cases because color components often vary between 0.0 and 1.0, and it’s more efficient to specify vertex colors (including alpha) as a single 32-bit value. For example, in hexadecimal notation, 0xFF800040 would mean alpha of 1.0 (0xFF), blue 0.5 (0x80), green 0 (0x00) and red 0.25 (0x40).

If you look in the Stage3D docs, you will find the constant Context3DVertexBufferFormat.BYTES_4 to use in the call to Context3D.setVertexBufferAt(). But if you naively just change the vertex buffer array to turn each vertex color’s set of 3 components into a single hex value, make dataPerVertex = 4 instead of 6, and use BYTES_4 for va1, then you will find that the colors are coming out wrong. Why? Because the function VertexBuffer3D.uploadFromVector() always stores the values from the Vector in floating point format. Of course! This is the most common situation for the components of the vertex positions, normals, texture coordinates and such. But we need our BYTES_4 color value to be stored verbatim as a 32-bit uint.

Vector.<Number> and uploadFromVector() do not give you control over the byte format of value. How do you solve this?

Continue reading

Flash Stage 3D is out!

A couple of days ago, Adobe released to the masses a new version of their Flash Player, and an updated SDK. The biggest change (for me at least) is the inclusion of hardware-accelerated 3D, known as Stage3D. Here’s a quick tour of what I did to compile and run my first Stage3D program (Windows 7 PC but should be applicable everywhere). Useful because the Adobe site is not really clear about this.

Continue reading