LÖVE

ivan wrote: ↑Thu Sep 24, 2020 5:11 am Well done, it works fine.

Thanks.

ivan wrote: ↑Thu Sep 24, 2020 5:11 am Just note that you don't need a quit button in the web version.

Right. We removed it yesterday, actually, but I just didn't regenerate the lovejs package since then. I wish I could automate that, by the way, but I saw it's not as simple as simply replacing the game.data file.

Stifu wrote: ↑Thu Sep 24, 2020 5:46 am Right. We removed it yesterday, actually, but I just didn't regenerate the lovejs package since then. I wish I could automate that, by the way, but I saw it's not as simple as simply replacing the game.data file.

Have not tested this but it looks like all of the files are the same except for index.html
Basically the "INITIAL_MEMORY" variable is defined there (it would be better if this is passed dynamically as a request parameter (something like play.php?m=25000000&c=0 where m is the memory and c is the compatibility flag)
All other files look identical, but hopefully Davidobot can explain.
It would be good to move the identical code in one script so that can be cached and reused between games.

PS. Yes, I can confirm that it works fine simply by swapping the game.data file
As long as the memory variable doesn't exceed the limit it should be fine..
Would be good to make a standalone love.js player so that we can swap the game files using a parameter.
Something like: play.php?game=supergame.love&m=250000000

I'm not sure this is right. I noticed the game.js file is different, for example, as at the end of the file it specifies the size of the game, and also attaches an id to the bundle (which might be used as the client cache key, I'm not sure). By simply replacing the game.data file, the behavior I got was that browsers that had already accessed the previous version would be stuck on that old version, even when trying to Ctrl+F5 my way through.

That's right, the game.js gets the full size of the file encoded in it. The initial memory is a separate thing and cannot be smaller than the size of the file, but should definitely be bigger (as the program footprint grows initially when started).

I suddenly found myself with a lot less time due to writing a paper and doing my dissertation, so I suspect updates will be slow for now, sorry!

I've figured out why our canvas had the wrong dimensions when the DPI settings are not set to 1.0. It's due to the fact we used the push lib with the highdpi parameter set to true. Setting it to false fixed the issue and makes Zabuyaki behave like other lovejs games.

Fix commit: https://github.com/thomasgoldstein/zabu ... 2564e65bf2

Awesome work David! Love how easy it is to create a port, with a single command!

I was able to successfully port some games first try, but for others, I'm getting these errors:

love.js:9 wasm streaming compile failed: TypeError: Failed to execute 'compile' on 'WebAssembly': Incorrect response MIME type. Expected 'application/wasm'.
(anonymous) @ love.js:9
love.js:9 falling back to ArrayBuffer instantiation
(anonymous) @ love.js:9
game.js:260 loading game.data from remote
game.js:231 Uncaught RangeError: offset is out of bounds
at Uint8Array.set (<anonymous>)
at processPackageData (game.js:231)
at IDBRequest.putMetadataRequest.onsuccess (game.js:209)

Any idea how this could happen? If the error is new to you I can try to strip down my games and figure out why it works for some but not for other games.

Sheepolution wrote: ↑Tue Oct 20, 2020 5:04 pm Awesome work David! Love how easy it is to create a port, with a single command!

Thanks!

Sheepolution wrote: ↑Tue Oct 20, 2020 5:04 pm I was able to successfully port some games first try, but for others, I'm getting these errors:

love.js:9 wasm streaming compile failed: TypeError: Failed to execute 'compile' on 'WebAssembly': Incorrect response MIME type. Expected 'application/wasm'.
(anonymous) @ love.js:9
love.js:9 falling back to ArrayBuffer instantiation
(anonymous) @ love.js:9
game.js:260 loading game.data from remote
game.js:231 Uncaught RangeError: offset is out of bounds
at Uint8Array.set (<anonymous>)
at processPackageData (game.js:231)
at IDBRequest.putMetadataRequest.onsuccess (game.js:209)

Any idea how this could happen? If the error is new to you I can try to strip down my games and figure out why it works for some but not for other games.

I think I've seen this error before, but I don't exactly remember how/why... Are you using Chrome or Firefox? I have a gut feeling it may be down to the browser and how they treat MIME types - https://trac.nginx.org/nginx/ticket/1606

Something to try though - try increasing the memory when compiling? As in, using the -m flag. It might be that there is some funky stuff going on with a large amount of memory being required at start up.

Stifu wrote: ↑Thu Sep 24, 2020 12:32 pm I'm not sure this is right. I noticed the game.js file is different, for example, as at the end of the file it specifies the size of the game, and also attaches an id to the bundle (which might be used as the client cache key, I'm not sure). By simply replacing the game.data file, the behavior I got was that browsers that had already accessed the previous version would be stuck on that old version, even when trying to Ctrl+F5 my way through.

I'm experiencing this right now, and I'm rebuilding the whole thing. Sometimes when I refresh the page, or when I did a whole new build, the game won't load and it will be stuck on 'game.js:260 loading game.data from cache'. I tried changing the javascript so that it never uses cache, but then it gets stuck on 'game.js:260 loading game.data from remote' :')

Davidobot wrote: ↑Wed Oct 21, 2020 12:49 pm I think I've seen this error before, but I don't exactly remember how/why... Are you using Chrome or Firefox? I have a gut feeling it may be down to the browser and how they treat MIME types - https://trac.nginx.org/nginx/ticket/1606

Something to try though - try increasing the memory when compiling? As in, using the -m flag. It might be that there is some funky stuff going on with a large amount of memory being required at start up.

Cool, I'll try this out.

Edit: Increasing the memory worked!

Also, I have more info on the bug I was talking about earlier (see above). So the game was actually loading, but sometimes when reloading the page it changes the window's size to its minwidth and minheight instead of the set width and height in the config. Weird stuff.

Sheepolution wrote: ↑Wed Oct 21, 2020 1:19 pm I'm experiencing this right now, and I'm rebuilding the whole thing. Sometimes when I refresh the page, or when I did a whole new build, the game won't load and it will be stuck on 'game.js:260 loading game.data from cache'. I tried changing the javascript so that it never uses cache, but then it gets stuck on 'game.js:260 loading game.data from remote' :')

Ahh, right. You should clear your local data in its entirety. So in Chrome that would be Inspect > Application > Clear Site Data

Would probably be ideal to add a checksum or something to the data so that it knows when to expire. Or perhaps a TTL.

Sheepolution wrote: ↑Wed Oct 21, 2020 1:19 pm Also, I have more info on the bug I was talking about earlier (see above). So the game was actually loading, but sometimes when reloading the page it changes the window's size to its minwidth and minheight instead of the set width and height in the config. Weird stuff.

Strange stuff indeed. I don't have too much time to work on this right now. If you could document bugs/findings in the GitHub Issues that would be fab) easiest way for me to keep track of things.

Davidobot wrote: ↑Wed Oct 21, 2020 3:11 pm Strange stuff indeed. I don't have too much time to work on this right now. If you could document bugs/findings in the GitHub Issues that would be fab) easiest way for me to keep track of things.

Done!

When does the pthread error appear? After successfully porting several older games I encountered a game that gave me this error. But I'm pretty sure that I don't use any threads. I can't think of anything special I'm doing that I don't do in other games.