V8 Js Engine + Minimal Canvas Implementation


aho

Member
Joined
May 16, 2009
Messages
183
Website
kaioa.com
V8 JavaScript Engine

http://code.google.com/p/v8/

"V8 implements ECMAScript as specified in ECMA-262, 3rd edition, and runs on Windows XP and Vista, Mac OS X 10.5 (Leopard), and Linux systems that use IA-32 or ARM processors." (emphasis added)


The Canvas Element

http://www.whatwg.org/specs/web-apps/current-work/#the-canvas-element

Now, implementing the whole thing would be bat-shit crazy. For being usable for games only a small subset is required:
  • the state stack
  • transformations
  • compositing: always source-over
  • colors & styles: only needs solid fill (context.fillStyle='#abc' or '#aabbcc' - no constants)
  • simple shapes (rectangles): only fillRect
  • images: all 3 methods, first parameter is always an image, if possible the draw texture extension should be used to speed things up
While all that vector graphics stuff is certainly cool, it's pretty hard to implement. Well, it's too CPU intensive either way.

The Img Element

http://www.whatwg.org/specs/web-apps/current-work/#the-img-element

PNG is the only format one needs. Well, TGA would be easier, but that doesn't work in a browser.


The Audio Element

http://www.whatwg.org/specs/web-apps/current-work/#audio

Since MP3 doesn't easily loop without gaps, Ogg/Vorbis is the only sane choice.


Events

Img and audio should fire events. Apparently keyboard and mouse events would be also helpful.


Well...

That's the basic idea. Something like that would allow everyone with a good browser to write some simple games. There also isn't a compile step involved. So, the turn-over rate is pretty excellent. Additionally, everyone can quickly test the game right away in their browser without having to put it on their Wiz first. This also means you might be able to make some extra money through advertising (with the web version - well, in theory), which makes it easier to justify spending time on this stuff.

The V8 engine is pretty amazing. It's about as fast as JS can be these days. It's quite a lot faster than all those Python interpreters for example. Given that there is no bloody DOM manipulation involved, the performance should be reasonable good. Well, not awesome, but on par with the better emulators, I'd say. V8 does generate native code after all.
 
Some update

Things I forgot:
  1. Needs a way to exit the application (well, duh).
  2. Needs a hook to load JS files - or - a configuration file which lists all JS files.
  3. Read/write files.

Other things:

Snapshot works, ARM works, snapshot+ARM doesn't. However, it's somehow possible to generate the snapshot on ARM... then go back and "bake" it in. I'm not really sure how that works. Well, here are some patches to make it work right away.

I also think that it might be better to use more straightforward implementations for images and audio. The differences can be easily hidden with the help of a small JS library. So, it isn't really necessary to bother with all that asynchronous stuff. It's pointless for small games anyways.
 
If anyone is interested... I managed to compile the V8 shell (it's self-contained and 3.3mb in size btw) after lots of trouble. It can load files and print stuff to stdout... sooooooo, in theory it would be good enough for benchmarking. However, the V8 benchmark suite stuff fails all over the place. I get a score of 0.0 everywhere despite the fact that the tests finish quicker than they do with Internet Explorer.

I'm not really sure what's the reason for this, since basic timing seems to work as it should. Also, the raytracing test complains that the result is incorrect, which indicates some kind of math issues.

I don't know how to fix this. I don't even know where I should look.

I think I'll give JamVM a try. I have far more experience with Java and Java bindings anyways. I still think that V8 could be very interesting though. So, maybe I'll go back to this at some point.
 
Back
Top