- It is dog slow. I mean, slo-o-o-o-o-o-o-ow. You've-finished-the-exam-and-there's-still-an-hour-to-go slow. Sitting in a traffic jam for three hours and the kids keep asking for an ice cream slow.
- It works in Firefox and Opera. I've tested in Midori, which is a WebKit browser, and it seems to work there too except that the fonts display as black-on-black, which means that either (a) Midori misimplents the spec (10% chance) or (b) I'm doing something wrong (90% chance). It's probably broken the same way in Safari too, but the game seems to work.
- You have to care about XML at inopportune moments. I spent twenty minutes trying to work out why
createElementdidn't work before sighing and usingcreateElementNS. - You can specify all the sizes in percentages! So it works at any size at all and the browser handles it all for you! Resize the game while you're playing and it all still carries on working and scales for you! Do that with canvas!
- The previous point appears to be the only thing where SVG scores over canvas. For everything else using SVG on the web seems rather like having your scrotum gently resting between a pit bull's teeth. It makes everything slightly more awkward than it ought to be... and any moment now you know the pain is coming.
- Did I mention slow? Can somebody please tell me what kind of a world we live in where my dual-core 2x2GHz PC can't render a screen made out of rectangles at more than 10fps without dropping keypress events? I mean, come on.
- It's not very optimised code (but it shouldn't need to be). It would probably be a lot faster if I actually did things an SVGish way, by which I mean use the
transformattribute and so on, but there are so many things I'd rather do than matrix arithmetic that it's not even funny. Up to and including eating a pound of fish fingers with broken glass in.
On I wrote Games in pure SVG, on the subject of JavaScript and the DOM, Software, Web, and Rants.
Also if I select "view source" on this thing Firefox acts all buggy and shows me nothing. hmm... strange.
martin: nfi. It works here in Firefox. :-)
That thing was way too fast to be playable, and I didn't even test it in Firefox 3.5/6
I don't think there anything stopping SVG from being wrapped with a higher level toolkit for making this type of thing much easier?
Interesting experiment. Thanks for posting it.
It is not slow in Firefox 3.5beta. Actually it is pretty fast.
By 'slow', he means he's had to limit the frame rate to avoid the dropped keypresses mentioned in the post. It runs at a pretty jerky frame rate.
martin: works fine here, firefox 3.5. you have to keep pressing the key, that's how it's designed to work.
by the way - 633...
awesome game, love it
Have you tried it in Chrome? I've heard that Chrome's V8 JavaScript Engine is the fastest.
xzyzz: Nope, because there's no Chrome version for Ubuntu.
Adam: yeah, I seem to top out around there. It's really hard to go much beyond 600 or so unless you can see into the future :)
Chris: certainly not, but a toolkit wrapper will make things even slower. (Raphael JS is an excellent wrapper toolkit for SVG/canvas.) If SVG was fast it'd be excellent, I think.
To be fair, I have never had a full screen flash thing run at a good framerate either, when your drawing with vectors and those vectors need to be anti-aliased, things are gonna go slow, weather it be flash, svg or canvas.
What version of webkit do you use? It displays fine with webkitgtk-1.1.6 (meaning there is white text on black background). However it's not playable at all at Celeron M 1.6GHz. The framerate is fine, but keystrokes are being stealed too much both with gecko and webkit backend in ephiphany. Midori is on the other hand a total disaster with inline find always stealing focus...
er... me=idiot... just found I can turn the inline find off...
It runs pretty well inside my RSS reader (WebKit-based, on a 1 month old MacBook Pro).
Actually, sil, if you found a nifty way of using the 'liquid resize' plugin on the server's images on demand, you could actually have variable sizes for raster graphics as well.
Would be very slow, though. And I'm not sure how well it would work with text.
@sil http://build.chromium.org/buildbot/snapshots/chromium-rel-linux/?C=M;O=D
You can also try the latest arora with qt 4.5 with -graphicssystem raster or -graphicssystem opengl (the last is very experimental).
As a game, it sucks baaaadly, but it does run fast and fine under Firefox 3.5b4 Shiretoko on my eee PC.
I don't know anthing about the technical side but that game is incredibly addictive..
Work well in rekonq
Chrome runs it ok
Don't see the FPS counter, but runs quite fine on today's chromium ppa.
Was this inspired by the recent:
http://www.kdedevelopers.org/node/3948
and
http://www.kdedevelopers.org/node/3949
SVG is pretty crappy at this sorta stuff. The areas where its noticeably nicer than Canvas are just things that work better with a DOM. Want something to change appearance on hover, just add a hover pseudo class to some CSS. Want a gradient to change with time, just change the stop-color attributes on a few nodes. Want to blur a picture, just add a filter rather than iterating through every pixel itself. Want to create a nonlinear 2D transform.... well then you're screwed and need Canvas.
The DOM is what makes it slow, which is its biggest problem. But its also what makes it nicer than Canvas at times (you don't have to do any logic it all to figure exactly what someone clicked on, and you don't have to redraw the entire screen just to change something). You could for this game even probably draw your room once, then mirror it using a use node and a tricky transform for the floor.
The JS access to attributes has always driven me crazy too. You'd think that rect.height would let you set/read the height of something. But instead you have to use rect.height.baseVal.value (or valueInSpecifiedUnits if you want to get back percents). When you get into transform and paths it only gets worse. Its nice (fantastic even) that you can do things like read individual transforms or combine them all into one quick matrix without writing any extra code, or tweak individual points in a path without having to parse everything. But there's a lot of digging through specs to figure out how to do it.
Nacho: three hours, most of which was workDigDSuing out how to do SVG at all. If it was a proper game I'd have done more with it than this :)
DigDug: or rect.setAttribute("height", "120")
Isn't the point of canvas that it can be mixed with HTML content? It is supposed to by like any other HTML element like SVG, video or images. The white box should be able to be styled via CSS to have a transparent background.
J5: sorta. The point is that the canvas itself is a first-class object that can be controlled like all your other HTML elements, but the things on the canvas are *not*. With SVG, every aspect of your drawing is actually a first-class object, accessed in the same way (and styled in the same way) as the rest of your document. The canvas is a little hole into another world where you have to use a different set of APIs to do anything; it's like a Flash or Java applet.
[...] ganz anderes hat Stuart Langridge damit gemacht: Er integrierte ein JavaScript-Spiel in die .SVG-Grafik! Durch einen Tastendruck [...]
It is not at all slow on my machine, FF 3.0.x on Jaunty. I scored 617 on my second attempt. :-)
[...] ganz anderes hat Stuart Langridge damit gemacht: Er integrierte ein JavaScript-Spiel in die .SVG-Grafik! Durch einen Tastendruck [...]
Works pretty fine on Opera :)
I can see the source too!
With Midori trunk and GtkWebkit 1.1.6 it works well and fonts, too.
xaml ! SVG is for supercomputers trying to render squares and circles.
SVG is worse than canvas, in more or less the same ways HTML is worse than PDFs. :-) It's not the tool for every job, but I'd be more partial to SVGs for most of the things *I* would be hacking at which does graphics on the web, despite the growing pains.
I just happen to have more use for an abstraction of data, vectors and objects (SVG) than an abstraction of a bitmap (canvas). As it turns out, fast-paced games often have a use for the latter.
On the other hand, web provisions evolve to meet the needs of what they typically end up being (ab)used for. Creative (ab)use like this can thus aid getting us faster SVG engines, over time.
It just hurts a bit being ahead of the adoption curve.
[...] Sundström, von SFCave inspiriert, cave nur mit SVG und JavaScript implementiert. Ich hatte mich da auch mal rangesetzt, aber es schnell (nach wenigen Stunden) wieder aufgegeben. [...]
SVG is slow ?
Yeah! Slow on Critical Mass :'(
http://en.wikipedia.org/wiki/OpenVG
http://ivanleben.blogspot.com/2007/07/shivavg-open-source-ansi-c-openvg.html
"Flash, Flash, I love you, but we only have fourteen hours to save the Earth!"
Aq, thats pretty cool for 3 hours work! I was gonna brag about a score of 410 on my first go but someone said they got 600-odd.
You should port this to iPhone and make a mint selling it on the App Store (just shove me 15% for giving you the idea).
http://www.google.com/search?q=svg+games
http://keith-wood.name/svg.html
I'm hoping the Palm Pre's implementation of WebKit includes a full implementation of SVG. It will be something to start with for game development anyway.
[...] ganz anderes hat Stuart Langridge damit gemacht: Er integrierte ein JavaScript-Spiel in die .SVG-Grafik! Durch einen Tastendruck [...]
Thats cool. I agree, that was a good post! but i m not agree to you to.
it is very difficult to follow them, well according to me, one should try reservatol.
Yes its possible to do naturaly, but it will surely help the casue lot.
You will find here a nice collection of free antiaging
Sadly, it appears the "V" in SVG has been lost on the author of this post, and must have learned next to nothing about SVG in the process leading up to this post.
this game requires 3 SVG elements. that's it. 2 paths for top & bottom, and a rectangle or any other shape as the puck.
Is there a bugzilla for reporting bugs on this thing? :P I could only get it to work if I furiously single clicked the blue block with the mouse while simultaneously hitting a keyboard key.