Love.js - A Direct Emscripten Port

[danvdragos]

@Ulydev
Yes but not fully because the browser doesn't support UDP. You can use a websocket in js and proxy bytes from stdin/stdout in no more then ~50 lines of code.
If you are more adventurous you could try WebRTC, implement peer discovery over a known IRC channel and you get P2P multiplayer. This way you pay nothing on servers and use your money to make more games.

Web allows us to get the game to people in the most convenient way possible with few clicks. I focus right now on having a desirable game with a good single player experience. I may post something on WebRTC in the future.

[Ulydev]

Yes but not fully because the browser doesn't support UDP [...] I may post something on WebRTC in the future.

Thanks for the reply! So that means enet won't work, right? Either way, I was going for a client-server approach but I might be interested in WebRTC as well. Please keep me updated about it

[Positive07]

WebRTC, WebSockets, and XHTTPRequest are the standard ways to contact a server from JS, it would be great to have all three since they are used for entirely different things.

This would be a really amazing addition to Love.js actually

[popcade]

I just noticed WebAssembly is now working on most browsers:

http://webassembly.org/roadmap/

Might worth a try compile to WebAssembly for a try.

[lxinuuja]

Hi,
First of all, totally awesome that there is a tool to port my löve to javascript, thank you for creating it! I've been working on a game now for a few months and I think it's ready to be published. However, the ported Love.js throws an exception of, I guess, running out of memory. Here's what I get in the console:

Cannot enlarge memory arrays. Either (1) compile with -s TOTAL_MEMORY=X with X higher than the current value 16777216, (2) compile with -s ALLOW_MEMORY_GROWTH=1 which adjusts the size at runtime but prevents some optimizations, (3) set Module.TOTAL_MEMORY to a higher value before the program runs, or if you want malloc to return NULL (0) instead of this abort, compile with -s ABORTING_MALLOC=0

I get the same by running the magic script both in release-performance and release-compatibility.

Any clue what to do to make it work? Is my game too big to load? The project folder with all the assets is 120 megabytes. Biggest single file is the mp3 music track which is 10,5 MB.

My repository is here, I just made it public, hoping someone could help me with my web release:
https://gitlab.com/aleksi.nuuja/defendroids/tree/master

Thank you!

[Tanner]

Hi,
First of all, totally awesome that there is a tool to port my löve to javascript, thank you for creating it! I've been working on a game now for a few months and I think it's ready to be published. However, the ported Love.js throws an exception of, I guess, running out of memory. Here's what I get in the console:

Cannot enlarge memory arrays. Either (1) compile with -s TOTAL_MEMORY=X with X higher than the current value 16777216, (2) compile with -s ALLOW_MEMORY_GROWTH=1 which adjusts the size at runtime but prevents some optimizations, (3) set Module.TOTAL_MEMORY to a higher value before the program runs, or if you want malloc to return NULL (0) instead of this abort, compile with -s ABORTING_MALLOC=0

I get the same by running the magic script both in release-performance and release-compatibility.

Any clue what to do to make it work? Is my game too big to load? The project folder with all the assets is 120 megabytes. Biggest single file is the mp3 music track which is 10,5 MB.

My repository is here, I just made it public, hoping someone could help me with my web release:
https://gitlab.com/aleksi.nuuja/defendroids/tree/master

Thank you!

If you have set everything up correctly using release-compatibility, you should not get that error.

That said, your game is very large and I'm not sure how emscripten/a web browser is going to handle trying to load all those assets into the virtual file system. Even if this does work, consider that sending someone to a web page that performs a 120MB download automatically is not a very considerate thing to do.

[lxinuuja]

If you have set everything up correctly using release-compatibility, you should not get that error.

Thanks for the support! I cleaned my assets and managed to cut down the size of the project somewhat. Release-compatibility now works and my game is released for players at: https://aleksinuuja.github.io/ (I made a bunch of other changes as well, so not sure if the error was related to project size or not.). However, release-performance still fails with the same memory related exception.

The game runs with rather low FPS compared to when executed locally, and I am looking for optimization tips. But that's offtopic in this thread. :-)

[Tanner]

If you have set everything up correctly using release-compatibility, you should not get that error.

Thanks for the support! I cleaned my assets and managed to cut down the size of the project somewhat. Release-compatibility now works and my game is released for players at: https://aleksinuuja.github.io/ (I made a bunch of other changes as well, so not sure if the error was related to project size or not.). However, release-performance still fails with the same memory related exception.

The game runs with rather low FPS compared to when executed locally, and I am looking for optimization tips. But that's offtopic in this thread. :-)

You may find this recent issue helpful with regards to your memory issue in the performance release. https://github.com/TannerRogalsky/love.js/issues/48

[murks]

Release-performance helps a fair bit with performance in my experience (once you get rid of the memory issue).
In my case it went from unplayable in Firefox to playable. It was playable in Chromium even with release-compatibility.

The performance issues had weird effects. Our little game jam entry is basically just cookies jumping around on clouds. We used love.physics for that, which was overkill.
One issue in Firefox was that the cookies would fall through the clouds right at the start of the game. This may have been because in the version I tested this with the cookies were still allowed to 'sleep' (a physics performance optimization).
Jumping is based on a simple foot sensor, which allows for variable height jumping. However, in Firefox the performance issues somehow cut the jump height in half.

It seems low performance in the browser can significantly affect physics. That's something I did not expect at all.

[Tanner]

It seems low performance in the browser can significantly affect physics. That's something I did not expect at all.

Large update steps will result in a poor physics simulation. A robust, predictable physics simulation is one of the main reasons that people will opt to use a fixed timestep.