Reputation: 38564
Are SVG graphics a viable option for an in-browser game, with a google-maps style interface? This would involve zooming in/out, and scrolling in two dimensions over a very large distance.
For example, the client might request some area to be drawn in from the server -- and rather than the server returning a generated image for that section, it would return a series of gzipped SVG images and their locations in the requested area. Then the user could zoom in and out without grabbing new "tiles" from the server, since SVGs are scalable.
Would this be better than generating pngs or jpegs and sending back tiles? Would it perform well if there were many clients requesting images all over the place? Would it perform well on the client? What are the downsides to this approach?
Upvotes: 3
Views: 2995
Reputation: 7466
In my experienced. The downside is the achievable level of detail using SVG is lower than lossy image compression like jpeg and png. I had difficulties getting all my vector graphics to play nicely with each other. If your artists are comfortable with working in SVG then this may not be an issue. Another note is that SVG compatibility may very between browsers. For instance I'm not sure which browsers support SVG. Webkit does, and I think Firefox does mostly, but I'm fairly sure IE is out of the picture, so to speak.
Overall SVG will put higher demands on client machines and lower demands on your servers. Calculating hundreds of SVG images is a lot more work than arranging PNGs.
In really depends on your game. If you are writing Chess, it would probably work fine. If you want to do something more complex in real time( E.G. a 2d side scrolling game), I have no clue.
using this SVG clock in Raephael as an Example. I am running Chrome on Windows and periodically different bars "twitch" and "reset for a second"
I just saw this first person SVG Demo So it can be done.
Upvotes: 5