HTML5 stuck in preloader when on server

[Vasco]

I've been testing html5 by running the project through Flash Develop, which does some magic to run the game in a browser window.

Today I tried copying the game to my server, and when I try to run it from there, it usually gets stuck in the preloader.

The only time it didn't get stuck, was when I enabled FlxPreloader in Project.xml, and then set bytesTotal in FlxPreloaderBase to the number of bytes of all the files. But even so, the game would only run from the browser in my desktop PC, when I tried from my Android device it got stuck with the loading bar almost full. I've tried setting bytesTotal to a lower and higher number than the actual bytes, with the same result. Now I can't even get it to load on my desktop for some reason, with the correct number of bytesTotal :S

Any ideas?

[SruloArt]

- Every html5 game needs a server. When you build it with FlashDevelop it creates one just for you. If you don't have one, the game won't work.
- Take a new project, build to html5, upload the bin html5 folder to a server that is not related to you (dropbox) and see if the problem persists. Report back with a link + browsers tested + bitfive or openfl-html5 + project source.

- Setting different values to bytesTotal will not do anything as you have the #if js flag on FlxPreloaderBase that prevents anything but NMEPreloader from compiling. So, it's impossible + impossible-"er" taking into account that onUpdate has another flag that prevents you from changing bytesTotal on android (mobile + windows). A small tip about bytesTotal (Flash) = don't write the exact number of bytes (x=actual number - a few dozens Kb).

And a general tip for html5 - I would be very surprised if you actually manage to play a html5 game on mobile at this stage without some serious bugs. Please surprise me.

[Vasco]

I didn't notice the #if js flag on FlxPreloaderBase, I guess it worked once for some other random reason then...

Thanks for the bytesTotal tip.

I didn't think that playing on mobile would be much different than on desktop, but that makes sense, since the browsers are different. That's kind of a disappointment, there's not much point in html5 at the moment without mobile support :(

I'll try to set up a new project for testing then.

[bumblefish]

I'm actually not having any bugs myself other than the bitmap fonts blurring which I can work around using a spritesheet for text and the sound problems.
The sound problem is the only obstacle I can not overcome as using .wav is just WAY too big. 

[SruloArt]

1. I'm glad to hear that you don't have bugs, yet. :)
2. Graphics are really the way to go for text for now. You can also use Openfl's textfield for stuff like score, but embedding fonts is not that easy.
3. You can decrease the size of your .wav files with several methods: use Audacity to decrease its quality and make it mono, use Format Factory to make a smaller .wav (tricky but possible), or try to handle procedural music and sounds (this requires work).
4. If .wav is a real issue, you can use openfl-html5, that can handle .ogg across browsers, but you should be careful about what type of .ogg you use, as this backend is quite picky. In fact, even if you have wav/mp3 files that it does not recognize in your project it will get stuck unless you delete them. So, it makes it harder to switch between openfl-html5 and openfl-bitfive (which requires .wav to work on Firefox).

[bumblefish]

Thanks for the tips! I'll see if I can work around this issue. 

[Vasco]

I've been able to get my game working on mobile, with the Firefox browser for Android (I was using the HTC browser before). I think that one of the reasons that it was not working before, was that I was deleting some sound files from the export folder, that weren't needed in the html5 version, but maybe the game was "looking for them" anyway, so the game wouldn't load?

Anyway, while the game loads on the Firefox browser, it runs pretty slow, and it keeps getting slower until it completely freezes the phone. There is also some crackling sounds.

Is this mainly a problem with HaxeFlixel/bitfive, or is it just that html5 and the browsers aren't mature enough to run this properly? If I used another html5 game framework, would I get much better results?

[SruloArt]

1. Possibly. 2. Sounds like a memory leak. Remove all text and try again. 3. It's not. Flambe and Phaser are better HTML5 targets, but you can still have memory leaks. You can try using open-html5 (but I don't think it will be much better in terms of performance) or openfl-html5-dom.

[Vasco]

Well, just for the record, I tried it in the Opera mobile browser, and it worked pretty well, although performance isn't that great. Removing the text did nothing for the Firefox browser, and when I run on the desktop there's no memory leak.

[SruloArt]

1. Good to know, it's virtually impossible to tell exactly what's going on without some kind of a project to test with.
2. My general advice is to try the same project only with openfl-html5 (add <set name= "no-custom-backend"/> before you add flixel in your project.xml) + remove all the wav/mp3 files and use only ogg for all targets. If the sound is the culprit then the problem should be largely solved.
3. My best next guess will be particles, there's really a big performance hit with particles on Firefox for some reason.
4. After that I would try to optimize the code but I have no idea where to begin. Check to see how much memory each browser takes with your game on, maybe that would help, there can be high memory usage without a memory leak, so you can Use recycling with texture-atlases + reduce your bitmaps size and alpha.
5. iPhone4/iPad 1 and many different old android phones with Android v. < 3 will have poor performance no matter what. You can test performance on native android/iOS vs mobile-html5 to rule that out.