I recently came across the hqx Scaling Algorithm for upscaling pixel art images. hqx was originally developed for the ZSNES emulator to scale up each frame in realtime and is thus written in fast (read: ugly) C code.
I took the challenge to implement hqx in JavaScript for Biolab Disaster and I think the result looks great. The algorithm does an extremely nice job with "organic" structures such as all the rock tiles, but tends to make low contrast zones quite blurry.
hqx comes in three flavours: hq2x, hq3x and hq4x. All of these are implemented in the JavaScript version and you can directly test them with Biolab Disaster hqx (the links below the game).
The source for the JavaScript implementation of hqx is available on Github under the GNU LGPL.
(Silly title, I know, but how could I ever resist such an opportunity?)
My HTML5 Game Engine Impact is now ready. It took some time, but I think it was worth it. I'm proud of what I have achieved and I hope you'll like it too.
Part of why it took so long to put it all together is that it now runs on the iPhone, iPod Touch and iPad. Try it yourself at playbiolab.com and impactjs.com/drop or watch a short video:
All those platforms still have their problems with sound and the iPhone 4 has a hard time filling all its pixels, but the games remain to be playable even on the 1st gen iPod Touch. You can read a bit more about Impact on mobile platforms in the documentation.
Even with iOS support, it might come as a shock to some of you that I am selling Impact, rather than releasing it for free. I love free and open source software and I've been contributing stuff for quite some time now. I had a hard time thinking about whether to release my Game Engine for free. The reason I decided to charge for Impact is a) it is easily the biggest thing I've ever made and I'd love to continue working on it full time, and b) I believe it is worth the money.
Ironically, my decision to sell Impact set back the release date quite a bit. If I'm selling something, I want it to be worth every penny. And even though the engine hasn't been far from completion for some time, I hadn't written a single line of documentation.
I feel that a good documentation is crucial for the success and adoption of any software project. So I set myself the goal to write the best documentation I possibly could.
I'm not a big fan of inline documentation (with documentation generators like JSDoc) because it tends to clutter the source code with trivial statements and – more importantly – makes it easy to write bad documentation. If you are writing the documentation separately from the code, you think about it differently. You think about the documentation as something that works without the source code, something that makes sense without the source code.
You rarely see code examples in automatically generated documentations, but for me as a developer, code examples are oftentimes exactly what I need. Take a look at the documentation for the ig.Entity Class - one of the more complex classes of Impact. This is something documentation generators just can't do.
Of course it took me longer to write the documentation separately than it would have if I wrote it inline, but this is only because it is more in-depth, more thorough.
But don't take my word for it. Please see for yourself!
On a lighter note, I'm currently sending out a few thousand emails to those who signed up on the old Impact landing page. I'm using a 10-line PHP script for that. Let's see how this turns out...
I finally found some time to work on the Impact website in the last few days. I just wanted some pages with documentation and tutorials along with a nice and simple forum. Nothing special. I looked around to find a forum software that would fit my needs. I couldn't find any.
So I sat down for a few days and put together my own forum. It's called Discuss and you can see the beta here. Account creation only takes a second and you don't need to provide an email address, so please try it.
This is my problem. I love to create my own stuff. My problem even has a name: Not Invented Here.
“Not Invented Here” syndrome is manifested as an unwillingness to adopt an idea or product because it originates from another culture
Ouch, that sounds pretty harsh. Of course there's a bit more to it, as Joel Spolsky wrote some time ago.
The thing is, “Not Invented Here” has worked great for me. This Blog is running on my own CMS, that I created some time in 2004 and it has been virtually unchanged since. It survived being linked by Daring Fireball twice, has seen the Reddit frontpage twice and the Digg frontpage once (when Digg was still popular, mind you). All without downtime or any security issues. I can only imagine what a struggle it would have been if this site was running on WordPress.
Of course, my CMS is not the answer to all problems. In fact, it only does very few things, but those are the things I need and it does them very well. (That also means that I won't release it any time soon. The fact that it works for me doesn't mean that it's “complete” in any way. Sorry.)
Back to my original problem. All the different forums that I tested suffered from feature creep. The big players (i.e. phpBB, woltlab and vBulletin) are trying to let you create your own personal Facebook, with Blogs, profiles, private messages and whatnot. Even those forum applications that advertise themselves as “light” (FluxBB, PunBB) will greet you with more than 200 files and make little distinction between code and layout.
And they all look the same, like they time traveled from 2001 to the present day. It's extremely difficult to make one of these systems feel like a part of your site. I'm still impressed by how Shaun Inman was able integrate his Mint Forum (PunBB) so tightly.
I like simple. I like software that does one thing and does it well. I'm extremely allergic to feature creep and code smell. When I create my own stuff I know what I get. Sure, the “Not Invented Here” syndrome initially demands a lot of time, but I like to think that it pays off in the end.
With all that said, creating my own forum probably is borderline stupid. I will be surprised if this works out and I don't end up installing PunBB or FluxBB anyway.
I know you're waiting for the release of the Impact Game Engine, and I promise you, it's coming. I just get distracted too easily. So here's my game Biolab Disaster running on the iPhone 3GS with 60 frames per second:
The game is running in its own process and is not using the iPhone's browser at all. Instead, it's just using the JavaScriptCore Framework to run the game. All the necessary calls to the Canvas API have been reimplemented with OpenGL-ES and the touch input is passed over to JavaScript to be evaluated by the engine. I of course had to make some changes to the engine, but the game source code is exactly the same as for the web version.
The JavaScriptCore Framework is still private on iOS. So as it is now, I won't be allowed to distribute the game in the AppStore. But my understanding is, that if I bundle my own copy of the JavaScriptCore Framework (which is part of WebKit and thus freely available) with my game, I should be on the safe side. Let's see how this works out.
Before I go into some details of my HTML5 game Biolab Disaster, let me use my 15 minutes of fame to say the following:
Safari, please get your shit together! You are a very nice browser; my game runs with an excellent frame rate and everything works fine. But please (please!) support the Ogg Vorbis codec for Audio elements. There is no reason not to. I had to encode all my sound files in Ogg Vorbis and MP3, just because of you, Safari. You make my life unnecessarily difficult.
(I could now go on and say the same thing about Microsoft's upcoming IE9, but I don't care enough about their half-assed attempt to build a browser)
Biolab Disaster was completely build for HTML5 – that is, JavaScript and the new Canvas and Audio elements. It doesn't need any Plugins, just a good browser. The game was initially conceived as a demo for my Impact Game Engine, but it became much more in the process. I made a short making-of video that shows how the game and the engine were built:
Despite this all being a relatively new technology, the browser support is pretty good already. When I began with this project it wouldn't run in Opera at all; now Opera has one of the best Canvas and Audio implementations around. Current versions of Chrome and Firefox still have some sound issues (lag) but otherwise run the game fine. I did some performance tests on different browsers and platforms:
Frames per Second
A frame rate below 30 starts to feel “chunky” and anything below 20 is not really playable – or at least no fun to play. The iPhone 3GS and iPad therefore sadly fall into the “unplayable” category. The performance on an iPhone 4 should be significantly better, but I don’t have access to one at the moment. Mobile Safari also won't load the sound files correctly as it seems – the game is stuck in the preloader. I will look into it a bit closer in the coming days.
It's worth noting that – regardless of the browser – JavaScript performance was never an issue. The real bottleneck is the Canvas API. All browsers spend about 90% of their time drawing into the Canvas. Especially Firefox is a bit on the slow side, but with the upcoming hardware acceleration in Firefox 4, performance shouldn't be a problem anymore.
Biolab Disaster formulates the playable truth that it makes sense to create games for HTML5. Not only is the result on par with current Flash games, but also is the development process incredibly smooth and satisfying. The hurdles that a new technology such as HTML5 sets, were already overcome by the game engine. For the development of the game itself, I didn’t have to deal with any browser or platform issues at all.
With Microsoft delivering some HTML5 support in Internet Explorer 9 and JavaScript and rendering performance steadily increasing, I can’t see any reason why JavaScript and Canvas would not be the gaming platform of the coming years that finally removes Flash from its quasi monopoly.
See for yourself.
My entry for the JS1k contest is a JavaScript Syntax Highlighter implemented in 1023 bytes of JavaScript – just one byte short of the contest limit. I also submitted an uncompressed and somewhat more readable version of the source.
The highlighter recognizes keywords, strings, comments (single and multi line), numbers, regexp and punctuations. And as far as I can tell, it works perfectly. It handles escaped characters as well as /* "strings" in comments */ and "comments // in strings" correctly.
I really doubt that I'm going to win anything with this though, as there are already many other unbelievably awesome demos.
Update: Stripped a few more bytes (1005 now) and formatted the source so it's actually readable. I also made the script a Quine – a program that prints its own source. You can find the new version here.
How do you display a list with a huge number of items? Easy: just paginate – split your list into several pages and let the user click through them one by one. Google does it with their search results, every forum software in existence splits a thread after N posts, my Blog only shows 8 entries at most. It's a solved problem.
Some years ago Microsoft had a different idea with MSN Search (now Bing): Infinite Scroll. If you do an image search on Bing and scroll down far enough, more results will be loaded on the fly and appended to the current page. There's no need to click a Next Page link. I don't know if they were the first to do it, but they certainly were the first I remember.
Today, many sites are using Infinite Scroll or the slightly less ambitious Load More button. And it constantly annoys me. It's not so much that most implementations are done very carelessly, but that the idea is inherently broken and really can't be done right.
Take Twitter for example. Say I'm writing a Blog post about how John Gruber was all the rage about X a few days ago. Naturally, I want to have a link to his tweets from said day in my post, so I visit twitter.com/gruber, click the more button two or three times, till I see those tweets and… now what? How do I link to this page? Do I have to link directly to twitter.com/gruber and tell my readers to click more a couple of times? How often? Well, it of course depends on how chatty he's been since I posted my story.
You might say that this issue could be easily fixed by utilizing the Fragment Part of the URL. So after I click more the URL would change to twitter.com/gruber#20, twitter.com/gruber#40, twitter.com/gruber#60 and so on (or better yet, counting from the first tweet). Now, what if I'd want to link to Grubers first 20 tweets? The URL would be twitter.com/gruber#8900 and the page would load nearly 9000 tweets? I don't think that's a good idea.
The non-link-ability is not the only problem of this technique: How do I jump to the end of the list? Or generally, how do I jump to a specific item (e.g. the first unread post in a forum thread)? What if the page becomes so long that my browser struggles to keep up?
It ultimately boils down to what we gain by using a Load More button instead of Next Page. And the only answer I can think of, is a few milliseconds of time I'd otherwise would've spent waiting for a whole new page to load. I also believe that appending items to a page is even more confusing for the user than going to a new page. After you've clicked more a few times, the list becomes so long that you easily get lost in it.
Pagination might not be as cool as all the AJAX stuff, but for navigating a list of “infinite” size I really can't think of a better approach. It doesn't have to be the old school pagination with a Next Page link though – you could build something that utilizes AJAX, caches the next page in advance, makes use of your mouse' scroll wheel etc. Ultimately it just has to be something that says “you are viewing items 340–380 of 920”: Providing a fixed sized, moving window into a set of items, instead of the fixed position, growing window that is Load More.
Songfever, at it's heart, is a tangible front-end for iTunes. Album covers are projected onto four physical objects standing on a shelf. With a scroll wheel, attached to the shelf, you can scroll through your music library in a Cover Flow like fashion. The goal was to reintroduce the aesthetic quality of a physical music collection (CDs, LPs), while maintaining the comfort of a digital one.
Each of the four covers are tracked by a webcam mounted above the shelf. Their positions are translated in software in the same way the projector located relative to the webcam in the real world. When rendered in a 3D OpenGL view and projected back onto the shelf, the album covers line up with the physical objects again. Approximately, that is.
Songfever was our main project in the 4th semester for “Digital Media” at the Hochschule Darmstadt. I was responsible for the programming; the UVC Camera Control I posted some month ago, was a small part of it.
Visit the Songfever Website for some more photos and videos.
