So, we thought about taking part in the alternative demo competition. The platform is mostly free choice there, but the compo name itself directs you to think about something different. I thought that maybe it could be interesting to make a demo which would consist of only a single static line with changing colors, and try to take most of that limitation. That is, to make a “1-Dimensional Demo” (at least by my definition).

Early on I decided there is no need to try showing technical mastery with such a hard limitation, and decided that it is enough to just make a vertically big image and small amount code which shows that image one line at a time, until the image ends. I made a few effect prototypes with Photoshop, synced to music by checking music positions in milliseconds and converting those to Y-pixel coordinates in the image, after deciding on a frame rate.

It became clear that there should be a good piece of music to go with the effects, because good audio can add so much more to the experience. I asked my friend !Cube if he could make up a composition starting with some piano playing, since I thought it could make a nice start to show just white bars on black background, flashing with colors synced to the piano.

To get beyond my tests (still accompanied by my own music), I asked stRana to help me with the actual production and design. That and just a few days later, most of the pieces started coming together, and we ended up finishing it nicely in time, a day or two before the event started.

For the tech part, I actually just expanded on my first proto tests a bit more. The production is built with Processing. It was mostly fine for the task, except that using the accompanying “minim” library for audio playing didn’t seem to be a perfect choice. I’m not sure of the contributing factors, but it seems the audio latency varies by computer and maybe even some times on the same computer. It didn’t seem to help much to ask for playing position from the audio system, since that seemed to be a too granular value not really telling where the actual audio play “head” is going. But, I didn’t want to rewrite the whole production just to fix this thing since it worked fine otherwise.

In the end we did really fine; Scanline by Rustbloom ended up winning the Alternative Demo competition. The weird thing is that the prizes in Alternative Party are usually strange obsolete leftover stuff donated by companies; we got two huge rack-mountable servers which were probably really good in their heyday, back in 2003. :) But we also got a bit of actual money on top of that (yay!).

You can download the executable version here: (.zip)
Download for Windows & Mac OS X (hint: source code is also there if you look for a source/ folder)

Or just watch it from the YouTube right here:

As usual, I spent a little bit of time to make some entries to the event competitions. Read on for videos and a bit of info.

–
Together with stRana we created Grandma by Rustbloom, for the Assembly 2011 event’s demo competition. It is an experiment of using Autodesk Photo Scene Editor to author content for real-time use, with only a minimal amount of tech to get the thing up and running. I made a simple custom editor which made it possible to move and orient the objects, and create & synchronize camera tracks to put together the demo. For music we used an antique phonograph recording from 1910′s, now in public domain, featuring Adele Rowland singing about Granny.
Grandma even ended up taking the 5th place in the demo competition, which was a very nice surprise. I guess it had unique enough style to stand out from the other entries.
Click here to download the executable version for Windows, or watch the video below.

–
I also helped out XMunkki to create a little humorous entry for the Assembly event’s 4 KB intro competition, Nelejän Kilon Nakki by XZM & tAAt. Technology-wise it interestingly the 2D effects in the production are actually running inside a complex pixel shader written by XMunkki. I mostly tweaked some of the visuals/movements and created the audio track using 4klang.
Click here to download the executable version for Windows, or watch the video below.

–
For the Evoke 2011 event I also took part in the 4 KB intro compo, with Excess Geometry – Ylijäämägeometria by tAAt 2011. This production was an experiment which started with the thought “what if I precalculate a big static bunch of vertex positions, and make a production which only shows a sliding window of those vertices”. That is, the effect code basically boils down to: glDrawArrays(GL_POINTS, array_pos_in_time, 50000);. Since the demo features a planar ground as a context to show other objects, it actually has to be “refreshed” all the time by re-inserting more vertices to the plane. So, the silly design choices largely dictate what kind of things are featured.
Click here to download the executable version for Windows, or watch the video below.

• relatively high-quality anti-aliased lines (better than subsampling or postprocessing)
• simple low-tech solution extendable to wide range of platforms (e.g. not relying on availability of shaders)
• visually better consistency than what you get if you just ask graphics API to anti-alias lines for you, and you might not even get any if the hardware is lacking
• try to solve issue of anti-aliased lines showing a “roping” effect
• concentrate on case of single lines without yet going to additional complexities such as line caps or joins between multiple lines

I set to test out stuff with Processing, and decided first to do a comparison of what anti-aliased lines look by default in it. Here’s an animation showing my simple test pattern with P2D, P3D and JAVA2D renderers:

As you can see, the results vary a bit, which is no surprise since those different renderers surely have differing precision/performance goals or just a different way to render the lines. For lines close to perfectly horizontal/vertical lines they’re pretty similar, showing clearly the “roping” effect I mentioned above. For lines close to 45 degree angles the JAVA2D renderer seems to look a bit better.

So, to move forward, here’s a magnified illustration of the technique how I’m drawing lines using two quads having a gradient going from 100% in center to 0% towards edge. In actual rendering that gradient ramp is done in alpha channel, but for these example images I’m using green background and a ramp from white to black to show more clearly what’s being done.

I’m basically just building on top of somebody else’s basic idea about how to render hardware accelerated lines by constructing polygons with gradient fins yourself instead of using a call to draw line primitives. I don’t know whose idea this is originally, having heard this a few times from different sources, but to fully research this subject you’d need to go back 30 years or so (check the short list of related links at end of this post).

When you use this technique to draw a line with “1 pix” thickness (although the fins cover total of 2 pixels), it yields pretty identical result with what you see in the above examples from Processing’s P2D/P3D/JAVA2D renderers. Well, not quite – for some reason, it actually depends a bit on the hardware. On low-end Intel GMA950 that statement of looking the same holds true. When I try that on my desktop PC with nVidia video card, the lines actually look much better (slightly fatter but without the roping). I found this out only later though, since I did all of my initial tests about this on a mini laptop which has the GMA950. :)

When the roping issue of anti-aliased lines is discussed, I have noticed that often somebody knowledgeable enough says it’s actually a gamma issue. The problem here being of course the fact that there are many ways to tackle the gamma thing, where none of them are a silver bullet solution which wouldn’t bring a host of other problems with it.

I got the idea that I could modify the above technique to draw two 0.5 unit wide fins per side, and apply gamma correction at the halfway. This would be still very simple and low-tech way to draw gamma corrected lines.

So here’s an illustration of what’s modified compared to the previous example:

The magic value of 0.72974 comes from 0.5^(1/2.2), assuming that your display gamma is 2.2. I also tried 0.707107 which comes from 0.5^(1/2), which is equal to sqrt(0.5), i.e. a good approximation which is “close enough” if you want to simplify the equation. Here is an animation showing the differences with no gamma correction, and then gamma correction with values of 2 and 2.2:

As I said above, the “no gamma” case looks very close to the gamma corrected one on different hardware, but the gamma 2.2 corrected case looks identical on the few machines I tried this on. I’m not sure what’s going on with that, hopefully somebody can explain it to me. I don’t have any explicitly enabled “gamma correction” features from drivers.

A few observations from the images. With the above technique even the perfectly horizontal and vertical lines get a small halo to nearby pixels. What’s good though is that the perceived brightness stays same very well regardless of line angle.

Perhaps one of the most annoying side effects of this technique is the fact that now the lines look fatter than normal 1 pix wide lines. I have done a few tests of reducing the fin width and/or decreasing the brightness. You can’t reduce the fin width much without the result quickly getting ugly, but decreasing just the brightness doesn’t really make the line look much thinner, it looks just darker. I don’t know what would be the optimal way, but I think maybe it involves a combination of both to some extent. Here’s one test image where I have reduced the fin width slightly as well as the brightness:

I think a bit of the roping effect has crawled back in, but the perceived brightness between angles is pretty much ok.

Here’s test code, runnable inside Processing. What’s additionally not visible in the example images above is the fact that the default renderers clamp coordinates to integers, while this method allows you to draw lines with perfect sub-pixel precision. The test code is modified to offset the lines by time slowly so you can see that in action. If you want to try the regular lines reference test case, replace the renderer in initial size() call to P2D/P3D/JAVA2D, and replace the call to testAALines(…) in draw() with the commented call to testLines(…).

Related links:

• Anti-Aliasing Through the Use of Coordinate Transformations (K. Turkowski, 1982).
• Prefiltered Antialiased Lines Using Half-Plane Distance Functions
• GPU Gems 2 chapter 22: Fast Prefiltered Lines
• OpenGL Invariance: Texture AA (with glAArg library)

Additional credits/thanks: I think I learned first time about using simple gradient instead of other tricks (like textures) from Mikko Mononen. Raigan Burns noted that the line being a bit fat and “bleeding” into adjacent pixels is actually a feature, since that way the lines actually look a lot better in motion. Alex May told me that most of Eufloria game’s drawing works like this, except for using texture for drawing the lines and having a bunch of textures with different gradients to get different visuals. The gradients are circular and lines are drawn using a cross section of the texture, with rest of the texture used to make caps for round-ended lines.

Some time before the event I also spent a moment to wade through Box2D physics engine documentation, and made a little prototype game called Luomuheinäseipääntapinheitto (a.k.a. Organic hay pole peg throwing), entering it also to the gamedev contest (placed 8/19). Background music is Test Drive by Zapac. Check out a video from Youtube, or download and try it (only for Windows).

Here’s links (mostly Youtube) to some other highlights from the event: XMunkki’s gamedev entry Raya Racer for N900, Evoflash’s winner Flash demo from wild compo, Archee’s 4k intro with physics and AI, winner 4k, Pier 64k from Hedelmae, Tricky truck – Archee’s winner entry from gamedev, 64k intro compo 1st and 2nd, Fairlight’s demo (2nd in compo), and finally ASD’s winning demo.

I was just reading Chromium Blog and it just announced: WebGL Spec Initial Public Draft Released. Well, I was quite surprised at half way to the post when I noticed they mentioned that one of the show cases a port of my San Angeles Observation 4 KB intro. I downloaded a fresh Chromium build (a development version of the Google Chrome web browser) to try it out, and have to say that I was quite impressed – the thing runs really smoothly. Let’s hope this tech becomes available as soon as possible to all major browsers. :)

Youtube link: http://www.youtube.com/watch?v=tAeTxPINttw

The ragdoll, Mr. Dismount, is now simulated better than ever and the graphics have been sweetened to something completely different when compared to the barren look of original Dismount series. There’s a simple screenshot button to create your own Dismount Moments. Sharing the images has been made really easy: simply save to photo library, email to your friend right away, or send it to Facebook, with automatic tagging of your friend if you picked a face from Facebook to start with. ;-)

We also worked countless of iterations with the user interface, tweaking small but important nuances. The hit position can simply be changed by touching (or touch-dragging on) the ragdoll. Camera view is simply controlled by touch-dragging from the border areas of screen (i.e. when starting to drag outside of the ragdoll), and zooming is done using the pinch gesture.

Sweet background music is made by Jonne Valtonen (Purple Motion). The sound effects have been painfully (literally) foley-recorded, tweaked, adjusted and mixed by Tuukka Savolainen, who has also drawn the sweet graphics for the game. Our platform code as well as some other parts were made by Mikko Lehtonen, and some nice visual enhancements were coded by Mikko Mononen. Jani Kahrama was the producer and is also behind the level design and 3d models. Yours truly (Jetro Lauha) is behind the original concept and acted as the lead programmer. I especially also want to thank Sara Kapli, who was very supportive and e.g. helped me with making reference lighting for some scenarios, of which some also made it to the final product without much modifications.

Finally, big thanks to authors of Irrlicht Engine and Open Dynamics Engine which were a big help in developing this product. There were many other open source libraries as well and I did my best listing them in the about text inside the game.

Touch Arcade was quick to act and they already wrote up a nice preview piece about the game.

Again I worked with XMunkki on an intro called Dream Creditor, which ended up at the fourth place in the competition (Download Windows zip / YouTube video). Additionally I made a tongue-in-cheek-production with little marching elephants called Irrelephant. Audience seemed to like it a lot so it placed on the 3rd place! (Download Windows zip / YouTube video). You can probably also easily spot that my little 2D walker prototype (from my previous post) ended up as part of this production.

But after I started to like more the whole concept of isolated first-stage prototypes, I felt EVALDRAW wasn’t just enough for all of my needs. After pondering with some alternatives I ended up “standardizing” on Processing, although it would still have a lot to learn from EVALDRAW. :-) However the one cool thing with Processing is that you can export your creation to be a stand-alone mini-app or even to a web page. As long as you have installed Java.

Lately when working with some ideas for a platformer game, I wanted to make some tests for a “walker”. To be exact, the simple kind which would just use some carefully chosen formulas like sine curves to move feet and body.

So here are my results.

As said, you need to have Java plugin installed.

I think it took from me roughly 2 hours to code & tweak those after having thinked about it beforehand. Naturally I had a few iterations – and actually the order of progression goes from bottom to up. I like how just the movements seem to convey different characteristics – the bottom one is somehow very steadfast, middle one is in haste, and the top one is a joyful jogger.

I actually wanted to make a “running one” as well but failed at it for the time being. :) I did check out Braid and some Mario games just to analyze how they approach the idea of making a character run or just generally move around.

Update: Added a “disney-happy version” of the bottom walker as suggested by Late below. Thanks! :)

With XMunkki I once again created a 4 KB intro, Rose Shank (download Windows zip). What’s special about the creation is the fact that it was created in a custom language which uses LISP syntax (Lisp-ahtava aka IL4). The code is compiled into a custom minimal bytecode and a VM for that particular case. Respect to XMunkki – he is the brains behind that nice little system which we have talked about for some years, and he finally got around to implementing it!

If you hadn’t heard yet, I recently also quit working for my previous employer Sulake Corporation and co-founded Secret Exit Ltd together with Jani Kahrama. We created a prototype of one of our game concepts for the Assembly Game Development competition. Cinnamon Beats took the 3rd place although it’s still in pre-alpha and we have received many positive comments about the game.

Update: Sources for Rose Shank are available.
You can also view a YouTube video of it!