Page 14 of 23
Re: Love.js - A Direct Emscripten Port
Posted: Sun Sep 13, 2020 10:39 am
by Davidobot
MadByte wrote: ↑Sat Sep 12, 2020 7:22 pm
I tested it on desktop Chrome / Chromium as well - same issue.
I think it has to do with different resolutions and/or scaling/dpi.
D0NM wrote: ↑Sun Sep 13, 2020 7:44 am
Now trying to see where does our Zabuyaki stop working with lovejs.
Stifu wrote: ↑Sat Sep 12, 2020 1:06 pm
Disabling shaders
I finally figured out why some shaders don't work. It's a matter of strict type casting. So if you have any multiplication/division with floats/doubles, you need to make sure that both numbers are written as doubles. So something like (taking screen to be a vec2 in the example)
won't work, but
will!
Re: Love.js - A Direct Emscripten Port
Posted: Sun Sep 13, 2020 5:53 pm
by ivan
Hey, I almost got this working in compatibility mode.
First off I got the following error:
Code: Select all
Error: [string "boot.lua"]:530: conf.lua:21: attempt to index a nil value
love.js:9 stack traceback:
love.js:9 [string "boot.lua"]:777: in function <[string "boot.lua"]:773>
love.js:9 [C]: in function 'error'
love.js:9 [string "boot.lua"]:530: in function <[string "boot.lua"]:380>
love.js:9 [C]: in function 'xpcall'
love.js:9 [string "boot.lua"]:787: in function <[string "boot.lua"]:780>
love.js:9 [C]: in function 'xpcall'
Basically I am trying to load the game's options file in conf.lua using love.filesystem.load
After removing my conf.lua completely I managed to get it started.
I see my splash screen but everything goes black after that point.
The music and menus seems to work, but the screen is totally black.
I tend to use scissors a lot and no shaders at all.
I can provide a love file upon request.
Any tips on getting this fixed?
Re: Love.js - A Direct Emscripten Port
Posted: Sun Sep 13, 2020 7:24 pm
by pgimeno
ivan wrote: ↑Sun Sep 13, 2020 5:53 pm
Code: Select all
Error: [string "boot.lua"]:530: conf.lua:21: attempt to index a nil value
What about showing what conf.lua line 21 does?
Re: Love.js - A Direct Emscripten Port
Posted: Sun Sep 13, 2020 7:53 pm
by Davidobot
ivan wrote: ↑Sun Sep 13, 2020 5:53 pm
Hey, I almost got this working in compatibility mode.
...
The music and menus seems to work, but the screen is totally black.
I tend to use scissors a lot and no shaders at all.
I can provide a love file upon request.
Any tips on getting this fixed?
If you use scissors, you might need to specify some setCanvas flags. Like the *boolean stencil (false)* on this page:
https://love2d.org/wiki/love.graphics.setCanvas
Much like the android port, this one is quite picky this things.
Also, Firefox and chrome render things differently, so try with different browsers.
Re: Love.js - A Direct Emscripten Port
Posted: Sun Sep 13, 2020 8:13 pm
by Stifu
Davidobot wrote: ↑Sun Sep 13, 2020 10:39 am
I finally figured out why some shaders don't work. It's a matter of strict type casting. So if you have any multiplication/division with floats/doubles, you need to make sure that both numbers are written as doubles. So something like (taking screen to be a vec2 in the example)
won't work, but
will!
Thanks for the tip, we'll try that.
Re: Love.js - A Direct Emscripten Port
Posted: Mon Sep 14, 2020 7:44 am
by Stifu
Ah, by the way, a feature request. Running love-js game.love game -d (-d for double, or something) could generate a lovejs package which would contain the code for both the pthread version and the compatibility version, and during execution, it'd detect if your browser supports pthreads in order to pick the best version. What do you think?
Re: Love.js - A Direct Emscripten Port
Posted: Mon Sep 14, 2020 10:21 am
by ivan
pgimeno wrote: ↑Sun Sep 13, 2020 7:24 pm
ivan wrote: ↑Sun Sep 13, 2020 5:53 pm
Code: Select all
Error: [string "boot.lua"]:530: conf.lua:21: attempt to index a nil value
What about showing what conf.lua line 21 does?
Attached is my .love file if you want to take a look, but note that it's a big project.
I had to remove my conf.lua to circumvent this issue.
My game tried to use love.filesystem.read from conf.lua and that was causing the crash.
Looks like the next hurdle to overcome is "cannot resume normal coroutine".
Davidobot wrote: ↑Sun Sep 13, 2020 7:53 pm
Much like the android port, this one is quite picky this things.
Keep up the great work, I would definitely use love.js for all of my game demos if I mange to get it working.
Re: Love.js - A Direct Emscripten Port
Posted: Mon Sep 14, 2020 11:21 am
by slime
FWIW, scissors don't need any special setup or setCanvas flags - they don't require a stencil buffer or anything else. They should work everywhere all the time on all platforms.
Re: Love.js - A Direct Emscripten Port
Posted: Mon Sep 14, 2020 1:05 pm
by Davidobot
ivan wrote: ↑Mon Sep 14, 2020 10:21 am
My game tried to use love.filesystem.read from conf.lua and that was causing the crash.
Looks like the next hurdle to overcome is "cannot resume normal coroutine".
The "cannot resume normal coroutine" happens if there are errors in the coroutine (loading.lua in this case)
Here's a .love that I modified to get it passing the splash screen. I don't recall all the changes (you can do a git diff) but it was something like:
- Use love.filesystem.getInfo(fn) before attempting to read a file to make sure it exists. (in app.read) [this was for loading bindings.lua or something]
- Make sure to use doubles in the shaders (1 -> 1.0; 0 -> 0.0)
It currently crashes when trying to load the level. I'll leave that up to you though
Stifu wrote: ↑Mon Sep 14, 2020 7:44 am
Ah, by the way, a feature request. Running
love-js game.love game -d (-d for double, or something) could generate a lovejs package which would contain the code for both the pthread version and the compatibility version, and during execution, it'd detect if your browser supports pthreads in order to pick the best version. What do you think?
Could you make an issue on GitHub with the request? It's easier for me to keep track of things that way.
Re: Love.js - A Direct Emscripten Port
Posted: Mon Sep 14, 2020 3:11 pm
by Stifu
Davidobot wrote: ↑Mon Sep 14, 2020 1:05 pm
Could you make an issue on GitHub with the request? It's easier for me to keep track of things that way.
Sure. But I can't find the Issues page on your repo. Is it disabled, maybe?
On my own GitHub repos, I have an "Issues" tab between the "Code" and "Pull requests" ones, but there is none on your repo. Typing the /issues URL does not work either and redirects me to /pulls.
Edit: this has been resolved, and the issue has been created.