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
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)
Last edited by PotHix,