

A HTML5 game that crashes every browser - browser makers, please do better - AshleysBrain

Hi HN,<p>Not sure where else to best reach the browser people, but I've made a little space shooter HTML5 game using canvas 2D.  Here's the URL:<p>http://www.scirra.com/labs/spaceblaster-webapp/<p>Arrow keys to move, hold space to shoot, press shift to fire rockets.<p>This game crashes every single browser on Windows 7 64-bit.  I've had it crash on Chrome 14.0.835.202, Firefox 7.0.1, Internet Explorer 9.0.8112.16421, Opera 11.51 and even Safari 5.1.1 for Windows.  Sometimes it crashes within 30 sec, but it almost always crashes before completing the game.<p>Please either tell me what I'm doing wrong, or fix your browsers.  Everyone loves HTML5, right?  So please make sure it works properly, because current browsers just don't seem to be good enough.
======
unfortunate
I keep filling my car with water, my car stops working, they should really fix
cars.

If _your_ code crashes every browser, _your_ code is shit. Yes the browsers
could do better, but you shouldn't write shit code that crashes them.

~~~
AshleysBrain
I see what you're getting at, but IMO this is probably one of the better coded
HTML5 games out there. It's written to be fast, low memory overhead and
conforming to ECMAScript 5 strict mode. It still doesn't work. I genuinely
have no idea how I can improve the quality of the code in this.

~~~
maushu
Huh, why are your assets all on different files?

Have you tried to put them into sprite sheets?

~~~
manuscreationis
+1 to this response

I've recently been reading into making use of sprite sheets with Canvas apps,
and the drawImage method makes using sprite sheets a breeze. You simply need
to keep track of cellsize, number of cells, and your current cell.

~~~
ehsanu1
I suppose spritesheets would making loading time faster since there would be
fewer files. But other than that, it's just a neat way of organizing sprites,
which can also be managed with a good naming convention tying together related
sprites. Is there any other reason to use a spritesheet?

Well, if you're using dom-based animation, spritesheets also work better for
animations since it's much faster to adjust _background-image-position_ in a
_div_ , compared to just replacing the _background-image_.

~~~
manuscreationis
Thats actually a different approach than how I had been doing it - i had been
loading a hidden spritesheet by grabbing it from the dom (this is all just
prototypal, playing around with canvas code, nothing "production" quality mind
you), then keeping track of the position in memory and iterating through the
frames using the overload of drawImage that lets you specify a slice of the
image as what you want to draw.

I wasn't even aware of using background-image-position as a way to do this...
I'll stick that one in my cap, thanks!

I'd say the main benefit of spritesheets as i've seen it would be what you've
already commented on: Fewer GETs against the server (when you're thinking in
terms of scale, for a large project with lots of assets, i'd say this becomes
important, but of course that's a fairly subjective metric), as well as
organization of files.

You could go with naming conventions... but then for a 45 frame animation, you
have 45 distinct files all named something like "SPECIFIC_ANIMATION_FRAME_X",
as opposed to using a dynamic approach, utilizing the cell-size of the frames
and the width and height of the image overall, to calculate the frames on the
fly; To me, that is far more maintainable than a huge pile of aptly named
images.

You could make the claim that calculating out the frame each time is wasted
cpu cycles that could be spent elsewhere, but I feel like it's the right
approach.

But that could just be my opinion. I would love for someone to weigh in with
actual metrics on whether or not using a dynamic approach is actually faster
or slower in a meaningful way than a brute-force style naming convention
animation system.

~~~
ehsanu1
Well, I doubt there would be much of a speed difference when using
canvas/drawImage, since I assume "calculating the frame" involves just use
some arithmetic on the dimensions of each frame - which is pretty trivial in
terms of CPU use at 60fps.

Anyways, you're right, with lots of assets it probably is a much better way to
organize sprites into spritesheet. I just never did anything on that scale. 45
animation frames? Sheesh, I'm happy if I can get 5 or 6. :)

------
manuscreationis
On the idea that it's your code, and not your browser, in my samples with
Canvas, i've noticed memory is very easy to start "leaking"

One thing I found on StackOverflow (I cannot find the article again, I
apologize... I should've bookmarked it) was that if you're drawing lines and
not using the "beginPath" call, you'll get a memory leak. No idea why this
would be.

I realized I had exactly that problem in my sample canvas app, and making the
change actually reduced my memory overhead. In Opera and Chrome, anyways.
Firefox still had wild memory fluctuations, but that didn't surprise me.

Moral of the story: There are probably several things you could tweak to
reduce your memory usage, as it does seem that a lot of canvas code out there
is memory-abusive.

------
ehsanu1
You'd get a better reaction from people if you assumed you're at fault instead
of blaming 4 independent browser makers as all being at fault.

nookie here mentions memory use, so why don't you use the profiler in Chrome's
web developer tools to find the memory leak (assuming there is a memory leak,
as nookie implies). I believe they have some tools to help you in that regard.

~~~
dlikhten
I think this quote said it best. I was told this when I started programming...
"Don't blame the JVM immediately, there is a very high probability this is
just a bug you made, probably some race condition. After all possibilities are
exhausted then blame the JVM, you are not even close to that." And there you
go. Modify to suit your needs. If every browser crashes, I bet you either has
a major bug or found a flaw in a core mathematical component each browser
relies on, in either case that flaw must be worked around. So in both cases
its on your shoulders.

------
steventruong
I couldn't replicate the crash. Played a couple games. Died, started off where
my points left off. Was over 1000 pts. Browser ran fine even with a bunch of
other tabs.

Mac Lion 10.7.2 + Chrome 14.0.835.202 Regular Build

------
n00kie
Mac + Chrome = crash. Memory usage keeps growing. No idea.

