Love.js - A Direct Emscripten Port

Discuss any ports of LÖVE to different platforms.
danvdragos
Prole
Posts: 2
Joined: Wed Jan 18, 2017 7:24 am

Re: Love.js - A Direct Emscripten Port

Post by 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.
User avatar
Ulydev
Party member
Posts: 445
Joined: Mon Nov 10, 2014 10:46 pm
Location: Paris
Contact:

Re: Love.js - A Direct Emscripten Port

Post by Ulydev »

danvdragos wrote: 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 :nyu:
User avatar
Positive07
Party member
Posts: 1014
Joined: Sun Aug 12, 2012 4:34 pm
Location: Argentina

Re: Love.js - A Direct Emscripten Port

Post by 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
for i, person in ipairs(everybody) do
[tab]if not person.obey then person:setObey(true) end
end
love.system.openURL(github.com/pablomayobre)
popcade
Prole
Posts: 2
Joined: Wed Jun 08, 2016 3:42 pm

Re: Love.js - A Direct Emscripten Port

Post by 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
Prole
Posts: 2
Joined: Fri Apr 28, 2017 8:43 pm

Re: Love.js - A Direct Emscripten Port

Post by 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!
User avatar
Tanner
Party member
Posts: 166
Joined: Tue Apr 10, 2012 1:51 am

Re: Love.js - A Direct Emscripten Port

Post by Tanner »

lxinuuja wrote: Fri Apr 28, 2017 9:04 pm 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
Prole
Posts: 2
Joined: Fri Apr 28, 2017 8:43 pm

Re: Love.js - A Direct Emscripten Port

Post by lxinuuja »

Tanner wrote: Sun Apr 30, 2017 1:59 pm 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. :-)
User avatar
Tanner
Party member
Posts: 166
Joined: Tue Apr 10, 2012 1:51 am

Re: Love.js - A Direct Emscripten Port

Post by Tanner »

lxinuuja wrote: Wed May 03, 2017 10:38 am
Tanner wrote: Sun Apr 30, 2017 1:59 pm 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
User avatar
murks
Party member
Posts: 185
Joined: Tue Jun 03, 2014 4:18 pm

Re: Love.js - A Direct Emscripten Port

Post by 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.
User avatar
Tanner
Party member
Posts: 166
Joined: Tue Apr 10, 2012 1:51 am

Re: Love.js - A Direct Emscripten Port

Post by Tanner »

murks wrote: Sat May 06, 2017 9:36 pm 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.
Post Reply

Who is online

Users browsing this forum: No registered users and 30 guests