A HTML5 game that crashes every browser - browser makers, please do better
5 comments
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.
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.
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.
IMO this is probably one of the better coded HTML5 games out there
I genuinely have no idea how I can improve the quality of the code in this.
I won't jump to conclusions, but this attitude is kind of indicative of the Dunning-Kruger effect (http://en.wikipedia.org/wiki/Dunning-Kruger_effect) being at play, especially given that you seem to be blaming browser makers for your game crashing.
Even the very best programmers can think of ways to improve the quality of their code. In fact, they're more likely to find problems in their own code - that's part of why they're the best.
In any case, assuming you aren't suffering from the Dunning–Kruger effect, can you mention what attempts you've made to narrow down the problem?
Have you tried disabling parts of the game (like rendering for example) to see if the browser still crashes? That would be a simple, albeit tedious, way of narrowing down where the problem is. Come up with a minimal crash case.
If you find a legitimate problem across all 4 browsers, then you can use that minimal case to demonstrate the problem and file a bug report. Or, more likely, you'll figure out what's wrong in your code this way and fix it.
I genuinely have no idea how I can improve the quality of the code in this.
I won't jump to conclusions, but this attitude is kind of indicative of the Dunning-Kruger effect (http://en.wikipedia.org/wiki/Dunning-Kruger_effect) being at play, especially given that you seem to be blaming browser makers for your game crashing.
Even the very best programmers can think of ways to improve the quality of their code. In fact, they're more likely to find problems in their own code - that's part of why they're the best.
In any case, assuming you aren't suffering from the Dunning–Kruger effect, can you mention what attempts you've made to narrow down the problem?
Have you tried disabling parts of the game (like rendering for example) to see if the browser still crashes? That would be a simple, albeit tedious, way of narrowing down where the problem is. Come up with a minimal crash case.
If you find a legitimate problem across all 4 browsers, then you can use that minimal case to demonstrate the problem and file a bug report. Or, more likely, you'll figure out what's wrong in your code this way and fix it.
But, it doesn't work.
Your code can only be as good as the platform you're working with. You can't code features beyond what are supported, and if you're trying to do too much, you need to scale back. If you based a games design on the idea that every computer was quad core with a huge graphics card, it would be pretty amazing, but no-one except a select few could play it.
Short of it is, you're code doesn't work, whatever is wrong with it, it doesn't work. And you can't expect browsers to change to suit you, if you really don't know how to improve it, scrap it and start again but at the moment you can't blame the browsers for not being able to support your, probably brilliant, game.
Your code can only be as good as the platform you're working with. You can't code features beyond what are supported, and if you're trying to do too much, you need to scale back. If you based a games design on the idea that every computer was quad core with a huge graphics card, it would be pretty amazing, but no-one except a select few could play it.
Short of it is, you're code doesn't work, whatever is wrong with it, it doesn't work. And you can't expect browsers to change to suit you, if you really don't know how to improve it, scrap it and start again but at the moment you can't blame the browsers for not being able to support your, probably brilliant, game.
Huh, why are your assets all on different files?
Have you tried to put them into sprite sheets?
Have you tried to put them into sprite sheets?
+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.
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.
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.
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.
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.
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.
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. :)
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. :)
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.
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.
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.
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.
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.
Chrome's developer tools never show the memory going above 30mb during the entire game. It's using a heavily optimised engine that creates very little garbage and rarely makes allocations in JS. So the issue appears to be in the browser.
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
Mac Lion 10.7.2 + Chrome 14.0.835.202 Regular Build
Mac + Chrome = crash. Memory usage keeps growing. No idea.
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:
http://www.scirra.com/labs/spaceblaster-webapp/
Arrow keys to move, hold space to shoot, press shift to fire rockets.
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.
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.