Another Rainbow Drawing Interation

Last night, after some profiling under iOS, it became clear that the method of drawing rainbows that I discussed in my previous post was going to be too heavy. Basically, the nice curve-y geometry of Rainbow's rainbows just contain too many vertices for my iPhone4 to want to render every frame at 60fps.

So, this morning, I revised the drawing code again, this time to accumulate into a framebuffer. This means that the actual amount of bow geometry rendered each frame is quite small, in exchange for the (large) fixed overhead of a full-screen blend. As an added bonus, when two active fronts overlap, the resulting bow is nicely blended (something that no other method I've come up with can achieve).

Unfortunately, this method limits (somewhat) the kind of graphical effects the game can perform. E.g., it can't fade out an entire band that hits a wall, or animate bands along their length. Rather, it could do these things, but I'd have to change the drawing method again, and sacrifice transparent bands and smooth mixing, or pay for another full-screen blend which -- it seems like -- the game can't really afford.

Stylish [Rain]bows

Today's hacking on Rainbow proceeded under Linux with OpenGL3 for output. I've built a helper class that should (fingers crossed) mean that everything transitions cleanly to OpenGL ES (at least as far as streaming vertex attributes).

Today, I worked on making the rainbow draw more nicely. The first step was to start using a special purpose shader.

The shader takes the position of each vertex and three info values -- the index of the frequency band, the position within the frequency band (shown above), and an alpha value which modulates the band's transparency.

A 1D profile texture (with mipmap) provides "fake" antialiasing, while a 1D color texture tints each band.

The above screenshot also shows off, to some extent, decent bow overlapping. In the Javascript version of Rainbow, overlapping is depth-buffer based (basically, bands are ordered based on the amount of time they've been controlled). This wasn't really satisfying, because it could result in hard edges where band orders switched.

This shows my first attempt at resolving the overlap problem by adding smooth fades. Unfortunately, without some sort of matching fade out, there are slight edges induced (especially in the infrared and ultraviolet). Solving this is going to involve slinging a fair number more dynamic vertices around, so I'm going to jump back to iPhone and see how my performance is faring before getting too far into things.

Rainbow Port Progress: Steering

Today, I continued working on my port of Rainbow from Javascript/WebGL to C++/OpenGL. I got steering in, and tested out collision detection -- [nearly] working first time.

As you can see in the screenshot above, I haven't yet turned on depth testing (to make the stripes render in the proper stacking order). Also, if you are an astute counter of pixels, you will notice that this shot is exactly the size of an iPhone4 display.

Yep, instead of graphical effects, I decided to find out how similar the OpenGL 3.2 and OpenGL ES 2.0 APIs were, and got an iPhone compile working. Turns out: really really similar; though the GLSL flavors are unfortunately somewhat different. Also, using GL_STREAM_DRAW vertex buffer objects instead of just pointing to data in memory seems to be a bad idea on iOS (versus the only game in town in GL3).

So it looks like my mobile version is going to probably have some unfortunate #ifdef magic in place in the graphics code. On the other hand, steering (multiple) rainbow fronts around with multiple fingers is already working (and fun!), and there's a fair amount of room on an iPhone screen to do it in.

Porting Rainbow

Today, I took some time away from fiddling with Rktcr's path select mode to work on the OpenGL/C++ port of my WebGL/Javascript game Rainbow. I'm using this port as an opportunity to re-write a lot of my basic infrastructure code, and to add some features to the game.

After one afternoon of work, I have basic drawing working nicely. I'm hoping that tomorrow I can get gameplay going again, test the collision detection routines I wrote today, and maybe even start playing with some of my graphics enhancement ideas.

It would be odd, though not entirely unexpected, if it turns out that the C++ port takes longer than the original javascript version to write.

Rktcr: Path Select

Rktcr, as text, is pretty much free association. I know what I want to happen in the game, and it flows relatively freely into the code. This isn't to say that things work properly on the first try -- many of the systems in Rktcr have undergone (and are undergoing) refinement.

Of course, you can motivate this refinement by downloading the demo and providing feedback.

One of the systems in the game that I've been having a fair amount of trouble getting right is path selection. In the current demo, path selection looks like the above shot -- a simple way of picking any completed trajectory through the zone.

This path select doesn't really give one a good idea of the content of paths, or how they vary -- e.g. two paths that are the same except for the last five ticks are displayed entirely separately. It also strikes me that path select mode, with its holistic view of trajectories, is a good place for timeline-based editing.

The (work-in-progress) screenshot above shows my current progress in playing with these ideas. I'm generally liking the two-level timeline (detailed view and overall view) for showing the controls applied along a trajectory, though I dislike the redundancy. Perhaps I will test a magnification-in-context style as well. I also like the faded-wheel trajectory visualization (n.b. this is animated in game, though I'm still trying to find the right sort of curve to use to animate it -- right now it's a sine wave, and feels a bit too smooth).

However, I'm struggling to figure out how to show different paths in this context and how to select between them. In broad outline, I know I want to use a tree structure, which should make common segments of paths clear. Indeed, I have a fair number of sketches of potential display and control options. Unfortunately, no option is clearly the correct one yet.

Rktcr Demo Zero Video

I believe I recently mentioned that Rktcr Demo Zero is out.

As a further enticement to just go download it, already, I've created the following compelling piece of documentary cinematography.

I'm sure you will agree that it is a great success, though perhaps overburdened with symbols in -- I would say -- the surrealist tradition.

Rktcr Demo Zero is out!

The title says it all. Rktcr demo zero has been unleashed upon the world.

Download it now, while you read the rest of this post. (Zip file contains versions for Windows [32-bit], OSX [10.7+; 64-bit], and Linux [32-bit]. You'll need a decent video card to play.)

This is the first public release of the game, and -- thus -- a great opportunity to provide feedback. I'm very interested in what you, the players, enjoy about the game and what you not-so-enjoy. You can let me know by contacting me directly through e-mail or instant message, by commenting on the game over at Steam Greenlight, or simply by commenting on this news post.

I look forward to hearing about your experiences with Rktcr. Have fun!