The lock-ups during loading are due to one of the restrictions of web applications, they don't allow emulation of threads with shared state. As such, using sf::Music (and anything else relying on and including sf::Thread itself) just won't work, since it relies on a background thread that continuously decodes samples from the music files. Everything has to be loaded in one go, so the "easiest" solution to make it lock-up free would be to load everything possible at the start of the application, unfortunately this would require loads of memory (but who doesn't have 16GiB of RAM these days?
). The cleanest solution would be to make use of web workers to load resources in truly native background threads, but that would require either an addition to the SFML API or rewriting portions of the application in Emscripten-specific code, both of which I didn't want to do
.
At some point, like I said, I'll probably write a "porting guide" or a "best practices for web compatibility guide" for SFML. If developers follow those, they should be able to port their applications basically for free to the web platform. All in due time...
The only bug I've noted: R-Shift was always pressed (I've change the "time control" to another key, and it's working).
Hmm... that's strange, did you cause the HTML document to lose focus in any way while holding R-Shift down? The application can only receive input events when it has focus, and since it can't asynchronously ask an operating system for the current key state, it has to rely on tracking the state changes itself. This means that keys can get "stuck" in the down position if focus is lost while they were released. Maybe there is a way to fix this, I still have to work on polishing the implementation up.
