LÖVE

We've finally fixed our color swap shader to make it work on the web!
Here's the code change, for posterity: https://github.com/thomasgoldstein/zabu ... 227194eb29

Now to try and fix stage loading... I've got a hunch that one is a filepath-related issue.

Edit: I've filed a little issue: Suggestion: remove the <h1> element from the index.html page

deleted: the reported problem in my post doesn't exist

Just managed to get my shaders to work with love.js and my game works perfectly
https://2dengine.com/arena/

Note that in WebGL you are not allowed to initialize your externs so: Should become: D0NM, I have never noticed this before, can you please post a test script.

ivan wrote: ↑Mon Sep 21, 2020 6:37 am Note that in WebGL you are not allowed to initialize your externs so:

Code: Select all

extern number scale = 1;

Well. True. But it used to work. You do not see shaders compilation warnings automatically.

ivan wrote: ↑Mon Sep 21, 2020 6:37 am Should become:

Code: Select all

uniform float scale;

I needed an integer length of a dynamic array. GLSL demands
constants to be able to unroll such cases: You cannot pass values as constants here...
Anyway, I just inject my constant right into the GLSL text source.

ivan wrote: ↑Mon Sep 21, 2020 6:37 am D0NM, I have never noticed this before, can you please post a test script.

EDIT: Just fixed our game and found that there is no such bug. My bad.

D0NM wrote: ↑Mon Sep 21, 2020 1:07 pm

ivan wrote: ↑Mon Sep 21, 2020 6:37 am Note that in WebGL you are not allowed to initialize your externs so:

Code: Select all

extern number scale = 1;

Well. True. But it used to work. You do not see shaders compilation warnings automatically.

Löve does not perform any syntax analysis of the code beyond some very basic checks. Compilation of GLSL is performed by the GL driver, and the driver for web is inherently different from the driver for desktop (but similar to the driver in most mobile devices). See e.g. https://stackoverflow.com/questions/289 ... -webgl-use . Using shaders inherently means deferring shader compilation to the GL driver of the machine where Löve is running, and different drivers have different versions and accept different variants of the language. This has bitten people that found out that their Löve file worked e.g. in AMD but not in nVidia.

It's far beyond Löve's scope to include a desktop GLSL to web GLSL source translator in order to make it acceptable by WebGL, therefore this is not something that can be fixed on the Löve (or love.js) side. Just try to make your programs compatible with GLSL ES 1.0 when you write shaders.

pgimeno, You are right! I'll follow GLSL ES 1.0.

And to all the readers of this thread:
This LOVE2D function might help u finding some GLSL compilation warnings and errors.
https://love2d.org/wiki/Shader:getWarnings

I eventually found that I sometimes index var4 arrays with indexes that are greater then the array length.
These warnings are hidden by default. You have to use getWarnings function and log them yourself.

YASS! Finally made our Zabuyaki working.
here is the link to Zabuyaki
https://www.zabuyaki.com/play/
use keys ESC(back), Enter(Start) Arrows. X(Attack), C(Jump) for player 1.
Up to 3 Gamepads should be supported, too.

The problem was in a crashing/freezing implementation of the well known function: It crashes (with love.js only!) on loading a non existing file.
IT should not crash/freeze, because there is errorMsg in its return.

So a simple wrapper saved a day!
I used function love.filesystem.getInfo() to check if the file exists.

merged the message to the previous post

D0NM wrote: ↑Mon Sep 21, 2020 6:40 pm YASS! Finalle made our Zabuyaki working.
here is the link to Zabuyaki
https://www.zabuyaki.com/play/

Yay! Thanks, everyone.
Somehow, on my desktop PC, the game is super smooth with Firefox, but very laggy with Chrome. In my experience, Chrome generally outperforms Firefox, so this surprises me. I wonder what's the bottleneck here.

Edit: also, on my Windows 10 laptop, text size is set to 125% by default, which messes up the lovejs canvas size. I wonder how to fix this properly...

Edit 2: I see window.devicePixelRatio returns 1.25 in my case. This might be useful to fix this.

Edit 3: you can easily reproduce the problem by using Firefox, going to about:config, and setting the layout.css.devPixelsPerPx value to 1.25. I still haven't found a proper fix.

Edit 4: Another Kind of World is not affected by this issue (canvas size and content dimensions remain stable regardless of DPI settings). So maybe it's a problem with our game...

Edit 5: I figured out the performance problem with my Chrome. Hardware acceleration was off. I enabled it in the advance settings.

I reckon people are likely to miss my many edits, so I'm double posting.
A picture is worth a thousand words, so here are two images that show our problem.

Zabuyaki when DPI is 1.0 (looks fine): Zabuyaki when DPI is 1.25 (canvas is too big, 800x600 instead of 640x480, and a part of the game is truncated): Since Another Kind of World does not seem to suffer from this issue, I assume this is a problem with Zabuyaki's code. I compared the conf.lua of our games, and they're very different (AKOW does not set the width and height in that file, and does it elsewhere, for example). I tried messing with the highdpi and usedpiscale values, but it did not help.

Zabuyaki's code: https://github.com/thomasgoldstein/zabuyaki
Zabuyaki's web version: https://www.zabuyaki.com/play/

Any ideas? Thanks!

Well done, it works fine. Just note that you don't need a quit button in the web version.