I'm wondering what the most viable approaches are for 2d game graphics, running in straight (and cross-browser) Javascript?
I've found the canvas and SVG approaches so far. Are there other straightforward methods that offer primitive graphics operations like drawing lines, circles, pixels? Preferrably supported out of the box in IE, unlike canvas/svg. :)
(I recently wrote a dinky little javascript game. Straight CSS+DOM worked for me in that case, but I'm looking into better ways of doing it next time.)
-ThomasN
You can have a look at this very simple library:
http://fx.inetcat.com/
Quoting their manual:
Compact lightweight JavaScript library
which extends DOM element by adding
animation methods. Facilitates CSS
properties and other parameters
alteration along timeline. Supports
parallel effects sets and effects
chains. Has extended set of callbacks
to adjust behavior.
If you follow the manual you see how easy is to make animations.
I'm just starting my JS port of a game I'd written in Silverlight, so I haven't used it (yet), but I was really impressed by the demos and API for Raphael.
It has a great set of functions, including awesome animations.
An svg-based library lends itself well to developing with physics engines and such, in addition to being able to animate and manipulate (rotate, mirror, etc.) images/sprites.
Related
GSAP claims to use HTML5 to perform outstanding animations for web use, but says clearly in the their article on Greensock.com that it does not use the canvas frame work in html5. It is clear that they are using Javascript from the provided script, but it is very confusing to interpret. In what other way would they use html5 animations without the canvas? And if they do use pure HTML5 does this mean that HTML5 animations are significantly faster than CSS, jQuery, and Javascript?
There's not such thing as "html5 animations".
There are, mainly, CSS3 animations (with either CSS transition or CSS animations) and Javascript animations.
CSS3 animations are generally well optimised (with a few quirks) but lacks support (old IEs) and flexibility (you'll have to use JavaScript to tweak them.) They're best for hover effect (with transitions) or basic animations.
JavaScript transition used to be based on a setInterval. A timed loop, and inside this loop the styles are changed. JQuery does this, and not very well.
Recently, Window.requestAnimationFrame() was introduced to replace these setInterval animations. Support is limited (old IEs), performance is top notch (because the browser can skip frames), and it's always style updates inside.
What GSAP does is using this requestAnimationFrame() while optimizing for less repaints and adding a lot of useful features (reverse, timelines, stagger...) On basic animations, you can achieve the same performances with CSS3 or your own JS code... if you know what to do.
There are also others animations (canvas, svg... event webgl) but more specialized.
In my limited experience with GSAP, and during some discussion with the developer of Velocity.js, it seems that GSAP has some very convoluted code that is quite difficult to interpret; I'm not sure if this is because they're purposefully obfuscating the code or that they do some very crazy optimizations... Maybe a bit of both. They may have also taken native code and created a Javascript implementation. In any case it makes reading the source quite difficult to do.
As far as your question about HTML5 animation, which I'm taking to mean animating objects on the DOM without Javascript, if you're using a compliant browser, you can achieve many animations via the CSS transform and transition property, the former being about DOM object transformations (moving it 10px to the left) and the latter being about how the object moves as it transforms (does it move linearly over a period of time, or use a user specified cubic bezier curve to describe its motion?). With current compliant browsers, the main difference in these properties besides vendor prefixes like -webkit- and -moz- is small. What this means is that you can reliably get animations on DOM objects across those browsers if you take case of the prefixes. You can use these transform/transition properties to manipulate almost any DOM object property.
In terms of speed, it depends. CSS animation is generally the faster between it and Javascript, but it lacks control because it's hard/impossible to manipulate certain properties like key frames. Javascript animation is slower, but using a good library makes this difference negligible and in some cases Javascript animation can be faster. It really depends on what you're trying to achieve. CSS and newer Javascript library animation is considerably faster than jQuery due to some reasons listed here.
*: Of course some browsers, like IE9 and 10, while being relatively compliant, do miss some properties and have quirks about their rendering engines.
I have background on Canvas 2D context, but i want to perform a 3D animation like this one, is Three.js library the best choice to do such animation? Can you point me to some useful tutorial or documentation that may help. Thanx in advance.
That's one of the most common choices.
As WebGL enables OpenGL without the need for libraries, you might also do it with just Vanilla JS but that would be harder as WebGL doens't offer much more refinement over the raw and crude OpenGL.
Apart three.js, you could also try GLGE or PhiloGL but as Three.js is the most popular I would recommend to go for it if you have no specific requirement.
Looks like the demo you linked to is using a canvas library called Clay.js. Not one that I've personally heard about until now. For 3d in canvas the most popular one I know of it Three.js as you already mentioned. It has the benefit of supporting webGL as well (browser based openGL variant).
Three.js has limited documentation and some examples but outside of some books you may buy there isn't a lot of hand holding. You basically need to dive in and start coding. Here are some online resources that may help you get started (not necessarily all focused on THREE.js):
http://aerotwist.com/tutorials/getting-started-with-three-js/
http://learningthreejs.com/
http://learningwebgl.com/blog/
To make it easier to work with THREE.js Jérôme Etienne created a project called tQuery which you can think of kinda like jQuery. A wrapper to make it easier to get your hands dirty. Here's a video where he shows how to create a webGL game in 10 minutes.
I'm looking for a simple JavaScript library or framework to create interactive 2D animations in the browser. (Excuse the buzzword in the title, but I'm not set on any particular rendering technology like Canvas or SVG.)
This should make it simple to draw and animate arbitrary (though not very sophisticated) shapes on a canvas screen and allow users to select and move these shapes as objects (kind of like a very basic RTS game engine).
Ideally, the following features should be supported (directly or indirectly; I'd implement it myself if necessary):
panning
zooming
fisheye partial zooming
box selection (selecting multiple objects by drawing a box around them)
Not being familiar with such things yet, I find it tricky to research what's out there (e.g. regarding search terms). Also, I have no illusions about some magical package that doesn't require any effort on my part - indeed, I'd prefer simple and readable libraries so I can learn about the basics by reading the source.
If you like simple libraries, perhaps take a look at GameJS. It claims to be "a thin library on top of the HTML5 canvas element." It's a port of PyGame to JavaScript, which in my experience is a fairly nice abstraction layer that at the same time doesn't overdo it.
If that doesn't cut it, have a look at this list of JS game (and animation) engines.
You probably did make a search and found dozens of js game engines. I will just narrow it down for you. It is impossible to just spit out one single js game engine. Also, you might find some to be more appropriate than others based on the type of game you want to make. So here they are
LimeJS
Impact
Crafty
I'm a long-time Flash developer who's recently decided to dive into HTML-based web apps, since, in my opinion, HTML5 provides a really compelling alternative to Flash.
(Not in every case - each technology has it's strengths and weaknesses - but HTML5 has a lot going for it).
Anyway - I can't speak for anyone else - but any time I dig into a new technology/language - I need to get my head around some core concepts.
One of the notions for me that's starting to gel is that divs in HTML are reasonably equivalent to movie clips (or sprites) in Flash.
In other words - wherever i'd use a movieclip/sprite in Flash - I'm now using a div.
Two key points of clarification:
I'm specifically ignoring the timeline concept, since I never used that in Flash anyway. In my mind, movie clips/sprites are just "objects" with visual properties that I could manipulate with code
I'm tending to use absolute positioning with divs, since A) that's how I thought of things in Flash (x, y, and z, coordinates), and B) with web apps, the UI elements of app "screens" tend to have fixed positions, and don't "flow" with variable-length content
So - my question, for those who consider themselves reasonably expert with both HTML and Flash...
Is this a useful/accurate comparison?
Or, do I have have an incorrect understanding of how divs should be used?
What fundamental ways are they different?
What trouble am I likely to get into based on this assumption?
Many thanks in advance!
Yes, in most cases you will be using div in HTML, where you would use a MovieClip (or Sprite) in Actionscript. Here are a couple of situations where a div alone won't be enough:
divs do not have the EnterFrame event. You'll need timers to emulate that, or some sort of animation library (jQuery's .animate() should do the job in most cases).
If you use methods from the AS3 Graphics class (as in mc.graphics.beginFill(0xff0000)), you'll may need to use HTML5 canvas instead. For example, if you need a circle, you can either use canvas, or use an image instead.
Also, you'll have to keep your eyes open for browser support limitations on many HTML5/CSS3 features. For example, rotating a MC in AS is a no-brainer, but in HTML5 it's not supported in all browsers.
I know this is not a complete answer, but I hope it helps!
I haven't used Flash in years so I may not be the best person to answer but you seem to have the grasp of what a div is. You did note that you use a lot (all?) absolute positioning. I would recommend you not to this unless you are looking do animate the DIV in some way.
You can get a lot of benefit from using relatively positioned divs or a combination or relative and absolute.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I'm working on an interactive interface using SVG and JavaScript/jQuery, and I'm trying to decide between Raphael and jQuery SVG. I'd like to know
What the trade-offs are between the two
Where the development momentum seems to be.
I don't need the VML/IE support in Raphael, or the plotting abilities of jQuery SVG. I'm primarily interested in the most elegant way to create, animate, and manipulate individual items on an SVG canvas.
I've recently used both Raphael and jQuery SVG - and here are my thoughts:
Raphael
Pros: a good starter library, easy to do a LOT of things with SVG quickly. Well written and documented. Lots of examples and Demos. Very extensible architecture. Great with animation.
Cons: is a layer over the actual SVG markup, makes it difficult to do more complex things with SVG - such as grouping (it supports Sets, but not groups). Doesn't do great w/ editing of already existing elements.
jQuery SVG
Pros: a jquery plugin, if you're already using jQuery. Well written and documented. Lots of examples and demos. Supports most SVG elements, allows native access to elements easily
Cons: architecture not as extensible as Raphael. Some things could be better documented (like configure of SVG element). Doesn't do great w/ editing of already existing elements. Relies on SVG semantics for animation - which is not that great.
SnapSVG as a pure SVG version of Raphael
SnapSVG is the successor of Raphael. It is supported only in the SVG enabled browsers and supports almost all the features of SVG.
Conclusion
If you're doing something quick and easy, Raphael is an easy choice. If you're going to do something more complex, I chose to use jQuery SVG because I can manipulate the actual markup significantly easier than with Raphael. And if you want a non-jQuery solution then SnapSVG is a good option.
For posterity, I'd like to note that I ended up choosing Raphael, because of the clean API and "free" IE support, and also because the active development looks promising (event support was just added in 0.7, for instance). However, I'll leave the question unanswered, and I'd still be interested to hear about others' experiences using Javascript + SVG libraries.
I'm a huge fan of Raphael and the development momentum seems to be going strong (version 0.85 was released late last week). Another big plus is that its developer, Dmitry Baranovskiy, is currently working on a Raphael charting plugin, g.raphael, which looks like its shaping up to be pretty slick (there are a few samples of the output from the early versions on Flickr).
However, just to throw another possible contender into the SVG library mix, Google's SVG Web looks very promising indeed (even though I'm not a big fan of Flash, which it uses to render in non-SVG compliant browsers). Probably one to watch, especially with the upcoming SVG Open conference.
Raphael is definitely easier to set up and get going, but note that there are ways of expressing things in SVG that are not possible in Raphael. As noted above there are no "groups". This implies that you can't implement layers of Coordinate Transfomations. Instead there is only one coordinate transform available.
If your design depends on nested coordinate transforms, Raphael is not for you.
Oh Raphael has moved on significantly since June.
There is a new charting library that can work with it and these are very eye catching.
Raphael also supports full SVG path syntax and is incorporating really advanced path methods. Come see 1.2.8+ at my site (Shameless plug) and then bounce over to the Dmitry's site from there.
http://www.irunmywebsite.com/raphael/raphaelsource.html
I think it is not totally unrelated but did you consider canvas? something like Process JS can make it simpler.
You should also take a look at svgweb. It uses flash to render svg in IE, and optionally on other browsers (in the cases where it supports more than the browser itself does).
http://code.google.com/p/svgweb/
I will throw my vote behind Raphael - the cross-browser support, clean API and consistent updates (so far) make it a joy to use. It plays very nicely with jQuery too. Processing is cool, but more useful as a demo for bleeding-edge stuff at the moment.
As a Javascript beginner, I found Rapahel samples not so easy, I recommend http://cancerbero.mbarreneche.com/raphaeltut, which is a real Step by step tutorial.
For those who don't care about IE6/IE7, the same guy who wrote Raphael built an svg engine specifically for modern browsers: Snap.svg .. they have a really nice site with good docs: http://snapsvg.io
snap.svg couldn't be easier to use right out of the box and can manipulate/update existing SVGs or generate new ones. You can read this stuff on the snap.io about page but here's a quick run down:
Cons
To make use of snap's features you must forgo on support for older browsers. Raphael supports browsers like IE6/IE7, snap features are only supported by IE9 and up, Safari, Chrome, Firefox, and Opera.
Pros
Implements the full features of SVG like masking, clipping, patterns, full gradients, groups, and more.
Ability to work with existing SVGs: content does not have to be generated with Snap for it to work with Snap, allowing you to create the content with any common design tools.
Full animation support using a straightforward, easy-to-implement JavaScript API
Works with strings of SVGs (for example, SVG files loaded via Ajax) without having to actually render them first, similar to a resource container or sprite sheet.
check it out if you're interested: http://snapsvg.io
Since it's not mentioned here yet:
You should also take a look at Dojox.drawing, which also provides good SVG drawing capabilities. It has a pretty impressive set of features. I'm just starting a project with it, but it seems to me that it's far superior (at least in terms of features) to Raphael and JQuerySVG.
This presentation convinced me to use it instead of Raphael/JQuerySVG:
http://www.slideshare.net/elazutkin/dojo-gfx-svg-in-the-real-world-2114082
Reference:
http://dojotoolkit.org/reference-guide/dojox/index.html
Reference on Dojocampus:
http://docs.dojocampus.org/dojox/drawing
Download Dojo (including Dojox):
http://dojotoolkit.org/download/
Another svg javascript library you might want to look at is d3.js. http://d3js.org/
I prefer using RaphaelJS because it has great cross-browser abilities. However, some SVG & VML effects can't be achieved with RaphaelJS (complex gradients...).
Google has also developped a library of its own to enable SVG support in IE:
http://svgweb.googlecode.com/files/svgweb-2009-08-20-B.zip
If you don't need VML and IE8 support then use Canvas (PaperJS for example). Look at latest IE10 demos for Windows 7. They have amazing animations in Canvas. SVG is not capable to do anything close to them.
Overall Canvas is available at all mobile browsers. SVG is not working at early versions of Android 2.0- 2.3 (as I know)
Yes, Canvas is not scalable, but it so fast that you can redraw the whole canvas faster then browser capable to scroll view port.
From my perspective Microsoft's optimizations provides means to use Canvas as regular GDI engine and implement graphics applications like we do them for Windows now.