Live data from Hacker News

Pong written in both flash and HTML5. Left side is flash, right side is HTML5.

labs.codecomputerlove.com

91–100 of 129 posts

Re: Pong written in both flash and HTML5. Left side is flash, right side is HTML5.

#91
post #79
post #59

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…

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.

Re: Pong written in both flash and HTML5. Left side is flash, right side is HTML5.

#92
post #12

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.

Core i7 920 on Chrome 9 (canary). Both sides are equally fast, but there's a visible stutter when the ball's moving quickly.

Re: Pong written in both flash and HTML5. Left side is flash, right side is HTML5.

#93
post #85

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.

Chrome 7.0.517.41 on a Mac. I got a score of 9135 (I stopped when it exceeded 9000).

http://img201.imageshack.us/img201/8486/screenshot20101102at...

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.

Re: Pong written in both flash and HTML5. Left side is flash, right side is HTML5.

#94
post #87

Earlier quoted context omitted.

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...

Framebuffer? There is no such thing in the 2600 (see "Atari_TIA" Wikipedia entry for details).

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.

Re: Pong written in both flash and HTML5. Left side is flash, right side is HTML5.

#95
post #59

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…

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.

A "right" answer is to make the keys remappable.

Re: Pong written in both flash and HTML5. Left side is flash, right side is HTML5.

#96
post #87

Earlier quoted context omitted.

Framebuffer? There is no such thing in the 2600 (see "Atari_TIA" Wikipedia entry for details).

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.

Re: Pong written in both flash and HTML5. Left side is flash, right side is HTML5.

#97
post #62

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.

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.

Re: Pong written in both flash and HTML5. Left side is flash, right side is HTML5.

#98
post #45

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.)

Where exactly are you getting Flash Player 10.2.161.23? Pretty sure latest release is 10.1.x.

Re: Pong written in both flash and HTML5. Left side is flash, right side is HTML5.

#99
post #96

Earlier quoted context omitted.

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.

Ah, then perhaps I'm confusing it with another console that predates my existence :P

Re: Pong written in both flash and HTML5. Left side is flash, right side is HTML5.

#100
post #12

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.

1005PE here (ie. also an Aton netbook). Flash side stutters for me, while HTML5 is smooth.
Post reply on HN