Page 7 of 23

Re: Love.js - A Direct Emscripten Port

Posted: Sun Apr 03, 2016 6:05 am
by pevzi
Nixola wrote:It looks fine here; Linux x64, Firefox (latest), Intel GPU (up to date drivers).
Just noticed that the left one looks a little bit darker here. However, the interesting thing is that the same is true for native LÖVE as well.
Ulydev wrote:Here's what I get on a Macbook Pro with Intel Iris GPU
Haha, that's cool indeed. Well, there's certainly something wrong with that ParticleSystem/Canvas combination.

Re: Love.js - A Direct Emscripten Port

Posted: Sun Apr 03, 2016 12:45 pm
by slime
pevzi wrote:There seems to be a problem with ParticleSystem drawn to a canvas. It is rendered correctly when drawn directly to the screen but when I try to render it to a canvas and then draw the canvas to the screen, it looks nothing like intended. Here's an online example and here's the source code for it.
See the notice near the top of the [wiki]Canvas[/wiki] wiki page. tl;dr: use love.graphics.setBlendMode("alpha", "premultiplied") when drawing the Canvas to the screen, if regular alpha blending was used when drawing content to the Canvas itself. :)

Re: Love.js - A Direct Emscripten Port

Posted: Sun Apr 03, 2016 1:54 pm
by pevzi
slime wrote:See the notice near the top of the Canvas wiki page. tl;dr: use love.graphics.setBlendMode("alpha", "premultiplied") when drawing the Canvas to the screen
Oh. Totally missed this one, thanks. It fixes the issue with the canvas being drawn darker but it still doesn't work for me when using love.js with Intel GPU. Just getting the same result as before. I've updated the example.

Re: Love.js - A Direct Emscripten Port

Posted: Sun Apr 03, 2016 2:24 pm
by slime
pevzi wrote:That's interesting. Here's what it looks like in both Chrome and Firefox when using Intel GPU:
smoke_wrong.png
But it works fine when I run the browser with a discrete NVIDIA GPU.
I use Windows 10 x64 with the latest 64-bit Chrome and Firefox.
That sounds like a graphics driver bug. Which Intel GPU do you have? Are you using the most recent possible graphics driver version for it?


EDIT: Can you also see what [wiki]love.graphics.getCanvasFormats[/wiki] reports?

Re: Love.js - A Direct Emscripten Port

Posted: Sun Apr 03, 2016 3:40 pm
by pevzi
slime wrote:That sounds like a graphics driver bug.
I thought so too but I've just asked my friend who uses AMD GPU to test this and it looks like this for him as well. :roll:
slime wrote:Which Intel GPU do you have? Are you using the most recent possible graphics driver version for it?
Intel HD Graphics 4600 and yes, I have the latest driver version installed.
slime wrote:EDIT: Can you also see what [wiki]love.graphics.getCanvasFormats[/wiki] reports?
Here you are:

Code: Select all

rgb10a2 true
r32f    true
rgba4   true
r16f    true
r8      true
rg32f   true
rgba32f true
rgba8   true
rgb565  true
normal  true
rgba16f true
rg16f   true
rgb5a1  true
hdr     true
rg8     true
srgb    true
rg11b10f        true

Re: Love.js - A Direct Emscripten Port

Posted: Wed Apr 06, 2016 2:06 pm
by logorrhea
I'm having issues getting this to work at all =\

If I follow the instructions on Github, and serve the debug folder, the page hangs on "Syncing Filesystem". Same with release-compatibility folder.

The release-performance folder runs, but displays several errors in the javascript console:

Code: Select all

love.js:1 bad name in getProcAddress: glGenQueriesEXT,glGenQueries
love.js:1 bad name in getProcAddress: glDeleteQueriesEXT,glDeleteQueries
love.js:1 bad name in getProcAddress: glIsQueryEXT,glIsQuery
love.js:1 bad name in getProcAddress: glBeginQueryEXT,glBeginQuery
love.js:1 bad name in getProcAddress: glEndQueryEXT,glEndQuery
love.js:1 bad name in getProcAddress: glQueryCounterEXT,glQueryCounter
love.js:1 bad name in getProcAddress: glGetQueryivEXT,glGetQueryiv
love.js:1 bad name in getProcAddress: glGetQueryObjectivEXT,glGetQueryObjectiv
love.js:1 bad name in getProcAddress: glGetQueryObjectuivEXT,glGetQueryObjectuiv
love.js:1 bad name in getProcAddress: glGetQueryObjecti64vEXT,glGetQueryObjecti64v
love.js:1 bad name in getProcAddress: glGetQueryObjectui64vEXT,glGetQueryObjectui64v
love.js:1 bad name in getProcAddress: glIsVertexArrayOES,glIsVertexArray
love.js:24 Uncaught 8334848 - Exception catching is disabled, this exception cannot be caught. Compile with -s DISABLE_EXCEPTION_CATCHING=0 or DISABLE_EXCEPTION_CATCHING=2 to catch.
I'm sure I'm just doing something wrong, or have missed something, but would someone be able to point me in the right direction?

Re: Love.js - A Direct Emscripten Port

Posted: Wed Apr 06, 2016 8:45 pm
by Tanner
What's in the console when you run the game with the debug release?

Re: Love.js - A Direct Emscripten Port

Posted: Fri Apr 08, 2016 4:19 pm
by logorrhea
Figured I should just make a gist this time instead of filling up the forum with logs...

https://gist.github.com/logorrhea/8bede ... 6ec13d0431

Thing is, I don't think I'm packaging the game incorrectly since the game does run in the release-performance folder. But maybe I'm wrong? I've tried pointing the script at both the game's root folder and a packaged .love file, each with the same result.

An example of what I'm doing would be:

Code: Select all

-- From the love.js debug folder
python ../emscripten/tools/file_packager.py game.data --preload /Users/tylerfunk/workspace/love/mygame@/ --js-output=game.js

-- or
python ../emscripten/tools/file_packager.py game.data --preload /Users/tylerfunk/workspace/love/mygame/mygame.love@/ --js-output=game.js

Re: Love.js - A Direct Emscripten Port

Posted: Fri Apr 08, 2016 6:17 pm
by Tanner
Does the debug release work for you if you just package a very simple love project? I'm wondering if it's something related to your source because it looks like your doing the packaging right.

Re: Love.js - A Direct Emscripten Port

Posted: Thu Apr 14, 2016 7:51 pm
by logorrhea
Yes it looks like a super-simple project works. I'll just start removing dependencies until it works, and get back to you about the cause. Thanks :)