Gah. People please stop using Z as the default key for down (or whatever). If you can't detect my keyboard layout use keys that are the same on every keyboard, no matter the language, or provide an option to configure the keys. My Z (on a Slovenian keyboard) is where your Y is (on your English keyboard).
This makes the game unplayable for me, since my "down" key is above my "up" key, which makes it almost impossible to play. /rant over
Awesome demo tho. Would love to see source of the flash part (maybe I missed it) so we could compare the source, not just performance (which seems to be about the same on my 5 year old laptop).
edit: who's now working on a (HTML5|Flash) vs Silverlight demo? That would be even more awesome.
You have asked an important question: how do you detect the keyboard layout (in Javascript) when using KeyUp/KeyDown events? A regular press event will provide the charCode but the press/release versions do not.
There are no keys that will work for everyone. I use Colemak -- the A and Z keys are in the same spot as Qwerty, but K is where N is on Qwerty, so that's a difference. Throw in Dvorak, and you only have A and M in the same place on those three.
I always install a us keyboard configuration as well in addition to my french keyboard for those kinds of issues. There is no need for two keyboard. Then you can just switch by pressing ctrl-shift simultaneously on windows.
Or just buy a US layout keyboard and use that! It's much better for coding anyway (especially for ObjC and its square brackts - these things aren't even labled on most international keyboards). Also it allows for much faster zergling production!
I quite like my Slovenian keyboard thank you very much. I have all the stuff I need to program (PHP mostly, so C would be cool to), and I have used English keyboards and didn't like them.
I'm sorry if I'm rude, but there are other characters than a-z (which I need to input quite frequently). And that is a concept English speaking developers seem rather hard to grasp (judging by most of the software out there). I just wanted to point that out.
Interesting problem of tuning both sides speed. Here (small Atom netbook hooked to big screen) the ball moves noticeably faster on the Flash side. To the point of making me lose a Pong match with myself.
Chrome has four different versions at any one time. Stable, beta, development, and canary. Canary is essentially a nightly build, and is buggier than a very buggy thing indeed, as you might reasonably expect.
The Flash side was unexpectedly slow, and comments on this same article on Reddit indicate that it is because they are doing a lot of JavaScript-to-Flash communication, which is unusual for a game, as well as enabling "wmode=transparent", which allows DOM elements to be positioned on top of Flash content, slows down Flash content, and is apparently unnecessary for this page.
Flash defaults to "non-web-friendly" (windowed) flags by default, HTML5 defaults to "web-friendly" flags. As a commenter said, you can also make the canvas tag opaque by using a special browser-specific style.
If you remove the windowless flag from Flash, you would have to add the opaque flag to HTML5 to make it a fair comparison.
HTML5 allows you to position elements on top of the drawing canvas and use a transparent canvas so the background of the page would show through the drawing. Flash does not, unless you add wmode=transparent to the parameters.
I was wondering why the ball appeared clipped on the flash side, even though I can't remember having seen this problem in a flash game before. It was also unusually slow. That old 3D first-per-view demo with textures had a clearer image and was faster.
Granted, the ball is using more pixels to render itself than all the pixels available on an atari 2600, and it's going through 10 levels of abstraction layers rather than using assembly code to blit pixels directly to the framebuffer...
Call it what you like, but it's basically a line-based "framebuffer" in memory, and the display just happens to be reading from that memory every time it draws a line. IIRC you get something like 80 clock cycles to blit your pixels into that memory space before the next line gets drawn, but it's still acting as a framebuffer.
No, it is not even a line-based framebuffer. Starting on every H-Sync interrupt, the CPU has to change the TIA chip latches with accurate timming for "producing" pixel output. So, there is no framebuffer at all.
Only because we keep trying to reinvent it using an increasingly esoteric, inefficient (from hardware's POV, if not a human's), high-level, abstract method, using newborn tools rather than proven ones.
While I'm seeing better perf on the flash side (XP, FF 3.6.12), Pong isn't exactly an ideal test bed.
Interesting that on the page they say "We believe the two technologies are not in competition" but that is exactly what this type of demo is going to stir up. While the improvements in browsers and javascript engines as of late has been nice, I think we're still a few years off from real parity, especially on lower-spec'd machines. Make no mistake, Flash on the web will be obsoleted by HTML5. But not yet, especially for all those people who don't update their browser every month.
For the time being, if Flash evangelists really wanted to make a point, they should do this same type of set up, but with a complicated (hardware-accelerated?) visualization.
HTML5 will eventually achieve comparable functionality and more importantly, business models may emerge (flash gaming is an industry after all) given time that make it a viable alternative to the people making games. At some point it'll almost certainly coexist alongside Flash games on sites like Armor, Kongregate etc. But it's not going to kill Flash.
HTML5's real fight is against native mobile platforms where it's competing against much richer platforms than Flash and more importantly business models that revolve around a mountain of cold hard cash people throw like confetti at the games they like.
If all it does is coexist or even entertaining the fantasy where it 'kills' Flash its lost, Flash is just the tip of casual gaming. Solipskier made $70,000 in the first 2 months of their iOS version ... against $16,000 on the Flash version (and that's more than most Flash games make).
Firefox 3.6.12 on a Mac.
For what it's worth:
Interesting behavior on the left side, the ball occassionally sticks to the paddle and vibrates, travels up the paddle and then scores a point against itself. (This is not a set up for a punchline.) Also, both sides show some stuttering in the ball movement.
I wrote a simple pong game once for a CS class, and in my case a vibrating ball was caused by simply negating velocity on a collision rather than setting its sign. It's better to do something like this (using C pseudocode as that's my native language):
if(collision) {
switch(side_of_screen) {
case LEFT:
horiz_speed = abs(horiz_speed);
break;
case RIGHT:
horiz_speed = -abs(horiz_speed);
break;
case TOP: // Positive Y is downward
vert_speed = abs(vert_speed);
break;
case BOTTOM:
vert_speed = -abs(vert_speed);
break;
}
}
Method: Get the ball to hit a paddle on the top or bottom. It seems the code that deals with paddle collisions only imagines horizontal collisions, so, every frame (or whatever unit of time it uses), it registers a collision and reverses its horizontal direction. This is the "sticks to the paddle, vibrates, and travels up the paddle" behavior you describe. Move the paddle up and down to follow the ball's vertical movement, so it doesn't fall off. You rack up a lot of collisions very quickly like this.
This works much better on the left side, for whatever reason. I've succeeded twice in getting the ball to vibrate on the paddle while moving slow enough vertically that I can follow it and prevent it falling off. I haven't managed to do it on the right side; I have gotten it to vibrate, but only for a short time before it gets flung away.
Also, sometimes the ball vibrates on the top or bottom surface for a little while (fraction of a second). This has happened only on the left side so far.
Running Gentoo with Firefox 3.6.9 on a Core i7, HTML 5 is much more noticeably laggy while Flash (10.2.161.23) is perfectly smooth. In Chrome they're more or less equivalent. (Firefox's sluggishness could have something to do with many Firefox addons and having over 100 tabs open.)
Edit: I do know that "Square" isn't an official release, it's a preview, but boy is it great. 64-bit support on Linux, hooray! 32-bit with nspluginwrapper is a pile of crap and would consistently crash, also taking out Firefox before they abstracted out the plugins from the browser. Secondly given Flash Player is insecure by default, it's probably better to be using the bleeding edge release over the current stable since it's less likely to be targeted.
are you sure its the flash that is smooth? I got have the same firefox on osx, and flash is laggy compared to the smooth js version. Flash is left, remember?
Plus who knows how each side was coded. I make games for a living and more times than not, jerkiness/glitches are an indication of bad programming than the platform it was written in. Pong is an ultra-simple game but you'd be surprised even on a game as basic as that the issues that can crop up that require elegant coding. Collision in particular -- the simplest, most obvious way in pong to check when the ball collides is to check the intersection of a point and a line, or a point and polygon/rectangle, the point being the edge of the ball (top/bottom of it for the walls, left/right of it for the paddles) versus the edge of the paddle or the whole paddle. More precise, but more math used and thus a less common way of writing the game, is to check the intersection of a circle and a line segment/polygon.
For example in flash, there are some built-in methods that everyone tends to use but don't get "pixel perfect collision" -- if you google that phrase you can see where people have tried to come up with perfect collision and how complicated all the math is for it.
I know for a fact just from playing this flash/html5 pong that it wasn't coded perfectly because it glitches when the ball gets to too high of a speed, either getting stuck in the wall and bouncing along it but not away from it, or going right through the paddle.
So this is really apples and oranges, unless both halves were coded with the exact same algorithms for everything (and just different syntax for the languages) -- very unlikely -- and, as evidenced by the other commenters also completely dependent on the environment/browser implementations of html5 and the flash plugins.
However, way cool on the link-bait worthiness :) I shoulda thought of this =P
On my Motorola Droid running Froyo, the flash side is much smoother. On the JS side I couldnt really control it because the browser was also intercepting every keystroke and trying to put them in the url/search bar.
Interesting. A big complaint leveled against Flash was that it steals keyboard focus. This causes problems when you're playing a Flash game and then want to tab away from the screen. In this instance, that it doesn't delegate control to the browser is a feature.
Also on a motorola droid here. I experienced the same problem, but if i tapped on the flash side first before giving keyboard input, the browser would stop intercepting my keyboard stokes, and I could control the javascript side.
I also noticed the flash side was smoother, while the javascript side was very jerky.
I would definitely like to see the source for this. Over time, it's become a lot more clear to me that Flash's defaults (and the normal tutorial code you read) are tuned for high resolution advertising contexts, mostly, so the need for taking steps to get good real-time / interactive performance out of Flash isn't always totally obvious to people.
Safari 5 on OS X: HTML5 smooth, Flash sluggish. (Does the "known performance issue" on Safari 5 affect the Flash side?)
Anyway, as the author suggests, this kind of test has merely entertainment value. While 95% of Flash could be replaced by HTML5, Flash still has its place on Games.
I've sought high and low for a way to do this on Vimperator, but I can't for the life of me figure it out. Forgive me for asking, but how do you exclude urls in it?
Actually you don't need to do so - at least in Vimperator you can enter 'pass through mode' by pressing ctrl-z. This disables vimperator keys and allows you to interact with sites in 'normal way'.
I didn't notice any real difference between the two on Firefox 3.6.
The only complaint I had was that there was some sort of hit detection problem on the HTML5 side (the ball got caught inside the paddle, and the rally count shot up by about 30 in about a second). I can't hold it against the HTML5 code though, since the flash side did it to me too about 10 seconds later.
Can't tell the difference on a MacMini2,1 w/ Safari 5.latest – both sides jerk a bit sometimes, but are mostly smooth-looking. Maybe if I blew it up to full-screen it would show a noticeable difference.
Reminded me of a BeOS demo, where windows would send each other messages about own position and the ball's physics.
My experience (Chrome on Linux) was smooth in both technologies (apart from a collision detection bug on the canvas side). Really neat demo though - when they're synced, it's weird to be aware that there's a sort of slight of hand happening with the ball as it crosses the center line.
It's interesting that the Flash version has a frame rate of 100 and a calculated size of 8000 by 9000 pixels, while the javascript version leaves these undefined. I have no idea what the performance implications these attributes have, as I have never seen either so high.
this should use a constant FPS game loop (http://dewitters.koonsolo.com/gameloop.html). Currently, the flash side is much faster; supposedly due to it rendering faster in my browser.
I guess it would if the idea is to show one has superior performance over the other. I was just commenting from the perspective of having a more uniform experience on both sides.
Interesting, at first the HTML5 was notably faster and smoother than the flash version, then the HTML5 became slightly sluggish and the flash version became smooth and fast. Anyone else get this? I'm on Chrome.
Looks like my left cerebellum and my right hand is winning, not sure if it's because of HTML5 or not. Flash is using less CPU, Ubuntu 10.10 64bit with Chrome 8.0.552.23 and Flash 10.2 d161.
Both ran smoothly (FF 3.6.12), but there were some collision issues with HTML5. Hitting the ball with the side of the paddle almost always results in the ball passing through it.
Ubuntu and chrome on older laptop, flash runs noticeably faster, and has odd accelerating effects on flash side. So, Flash is faster but not a consistent speed?
On my system here at work(Dell Core2Duo Xeon, 8GB win7x64), the "HTML5" side was slightly less glitchy, and the flash sides graphics were more antialiased...
IBM thinkpad T61, 2GB ram, running firefox 3.6.8 for Ubuntu 9.10 (yeah yeah, I know), and Flash 10,1,82,76 .
Ball is nice and smooth on HTML5 side, and kind of jerky on flash side. That could just be Linux+flash issues, but the animation for HTML5 is super-smooth, so I'm guessing it's just bad flash plugin.
Yeah in the old days it performed quite bad. Nowadays with the newer distro's like suse 11, (k)ubuntu and a couple of others I really havent found any more glitches than on any regular windows machine running flash..
I develop with flash regularly on my Linux machine (Ubuntu 10.something), and it's definitely a bear compared to windows. I'll be happy for the day I can walk away from flash, but it makes computationally intensive consumer applications much easier/feasible. When we started out project almost three years ago, it was such a clear winner over JS, but now it's becoming a wash.
I code Flash too, on 2.26 Ghz laptop running 4gb and multiple distro's, no real problems here..
A lot of us Flash coders actually want to drop Flash from our websites, widgets and resumes. It performs bad and puts a lot of stress on the CPU, blocking my vital programs from running.
I've been coding Actionscript for some time now, but only started really liking it when 3.0 came out. I remember when the Papervision project became popular I loved coding Actionscript.... I still do and I dont think JS has the right properties to become anything close to Flash.
64-bit Linux is even worse, as it has to go through a 32-bit adapter to work in 64-bit Firefox. Video is unwatchable for me on a Core i7 with a fast video card.
Yeah, I use a 32 bit compiled version of firefox called swiftfox for all my flash debugging/testing. Definitely slow as heck, but, faster than using the wrapper/adapter method.
Awesome demo tho. Would love to see source of the flash part (maybe I missed it) so we could compare the source, not just performance (which seems to be about the same on my 5 year old laptop).
edit: who's now working on a (HTML5|Flash) vs Silverlight demo? That would be even more awesome.