Q: Why there are a lot of get parameters at startup?

A: The get parameters for config are in the middle between coders, testers and end user. Is like parameters in MAME. Sometime the engine can't scale itself to the device, so some sort of extra configuration is needed. Is too nerdy for the settings box and is way more useful to put them to an URL, in order to create, spread and bookmark different version of the game. Moreover, some games can play full throttle on a mobile, someone else needs smaller screen or higher frameskip for playing well. Since is nothing that Akihabara can decide, it goes in autoframeskip and tries to get a vaild screen size. But I liked to leave some choices to the users, if they are interested (and, if are interested, are porobably nerdy enough to understand).

Q: Why you choose this way to write akihabara? Not using all canvas methods and so on?

First of all, akihabara doesn't use much of html5 canvas capabilities for some reasons, but the most important is that just few of them are really useful for making arcade games, mostly for sprite blitting. Using sprites blitting for most of the operations, including text, allowed me to concentrate on solving less specifications compatibility issues (you'll probably know that some w3c specs aren't well respected by browsers and different releases have different compatibility levels) and more on creating core and toys. A clear example of this advantage came up when I worked on wii compatibility: while the blitting commands were ok, canvas initialization was very buggy. Luckly just these two commands were used in the whole engine, so was a quite easy patch. I also decided to limit some important features too, like rotations and zooming for make faster collision detections and gfx processing, in order to make a lighter engine. I've added sprite flipping instead of blitting pre-flipped sprites because flipping is usually not expensive in terms of processing, since just the pixel blitting order is changed, without any per-frame calculation.

The tests you pointed out are very interesting in this way:

Clearing the canvas

• canvas is never cleared up between frames, so much time is gained here, whatever is the method. Is possible that the canvas is cleaned up on startup, but happens once per load.

Drawing images

• akihabara uses the aligned way, afaik, since numbers are always rounded. The resize test was one of the one I did on dev-ing and made me dropping the idea of supporting real time scaling and explore other ways for stretching the screen size for the pixel effect. Akihabara actually uses css for zooming the screen, that takes really a few but acts on the whole virtual screen. Spritesheets vs. individual sprites
• akihabara uses both ways but demo games tries to uses just a sheet. While the test on my android says that sheets are faster (and occupies way less memory - not tested but logical, since header storage makes an inevitable overhead) than single frames, the results are luckly comparable.

None of these are used or heavily used, except fo the dev lib with spritesheet creation helpers, so no great performances are needed (executed once on a browser)