Web support + non-jit lua support + configurable keys #4
Conversation
There might be some differences in scoping on web because just including the library once at the beginning of main.lua still doesn't fix errors in other files. Better safe than sorry, I suppose.
This was very easy to do and it sounds almost exactly the same. Probably the reason it wasn't used right away is because newQueueableSource was added to LÖVE2D only by version 11.0, while the early picolove versions were made for 10.2.
First off, pcall is unnecessary since load already does error handling of its own. Second off, load takes an iterator function that spits chunks, instead of a string. While yes, the specification says that strings are also allowed, for readability and more importantly web compatibility we have to switch to loadstring.
Using a workaround here: https://stackoverflow.com/questions/6247572/variable-array-index-not-possible-in-webgl-shaders#comment20990173_6250189 It's a bit weird and probably way slower but it's better than 16 elseifs or instantly crashing.
Something about metatables doesn't work on web. I can't figure out what exactly. Considering bxor is literally the only bitwise operation that uses this functionality, and all other bitwise ops are made of bxors, I just ditched the whole make_bitopt thing and implemented bxor by myself without using any advanced lua features. It doesn't crash! Yet. Certainly should come back to this at some point and figure it out properly.
Because debug.upvalueid doesn't exist on web. I think this only hurts performance and doesn't seem to affect anything else. Hopefully. There is something to be said about switching to a more rudimentary deepcopy implementation, so that it would be easier to understand and to possibly get better performance (since deepcopy gets called a lot), but Gonen knows better than me about how this would break things.
Harrowing
If the platform is detected to not be web, include the regular LuaJIT bitops lib instead of the pure lua one.
How this works: every frame lua side checks for the existence of the file called "file_pending" in the root directory. When it finds it, it knows that a file has been dropped and loads it in. "file_pending" is created from the JS side, as well as writing the actual TAS file dropped to the in-memory filesystem. It knows which file to write to because the lua side creates and updates a file called "working_file" which contains exactly the filename that you'd expect it to contain. Currently only works with cctas. Also I accidentally changed whitespace to tabs on random lines. No need to thank me.
I do believe that maintaining a handwritten exclude list is just a waste of effort, so I replaced it with a find. Technically if you want to exclude any lua, p8, or png files you still need to manually add a -not -path to the command, but I think excluding those types of files is less common.
I'm going to be entirely honest, I did not notice there was a makefile in this project until today.
The tastool saves the tas to both the internal in-memory filesystem and to the user's PC.
|
One more thing that could be better is documentation. The web celia page doesn't really explain what it is or what it's for. Also I accidentally included a github workflow action in this pr. It's completely untested and hasn't been run even once so feel free to revert 57fc23c. |
|
There are little things that've been forgotten:
Also visual selection is broken:
|
|
The checks to toggle controllers buttons are also a bit weird: |
oh yeah this is just a honest mistake. I fixed that in the regular keypressed on dc44b9d but forgot about selection_keypressed.
Just an oversight as well, I misread the meaning of the for loop. My two commits above should fix these both of these issues.
Honestly I left that one on purpose because I'm not entirely sure what it does.
Yeah this sounds like a good idea. I just wasn't sure if changing pico8.keymap would break anything, so I didn't touch it. |
No you can change pico8.keymap as will, it's only purpose is precisely to define which keys act as the controller buttons.
The visual selection is working when you press alt+button, but the loop still isn't there when you press only the button. (In master there's only one loop but each iteration checks for both alt and non-alt. |
Also fix all selection but for real this time.
love.keyreleased became one hack longer. This is related to the fact that when a one key is released, all others are also considered released. This behaviour makes sense for keybindings consisting of several chords, but specifically messes up the thing tas tool is doing here. I'm thinking of a better solution to this.
|
Apparently the workflow action does work with no necessary edits. |
User has to install love.js either way so they might as well use `npm install`
Presumably. It's up to the reader to find out *why* getInfo returned a truthy value on a directory that didn't exist.
Turns out that every single modkey not working is an issue with my particular browser and not everyone's.
For some reason web keeps having unique floating point errors that are not encountered locally. In fact this was the reason numberlua crashed originally. For authenticity's sake I restored the original bxor implementation with flooring added. Considering the values a, am, b, bm are used as indices I believe rounding them to a whole number is safe. I can't say the same about rounding the output of band and tobit, so an Epsilon value is used (derived experimentally). Nowhere does the tastool code try to apply bitops to non-whole values, so even floor(x+0.5) like in bxor would've been safe, but I'm trying to look out for custom carts.
Setting PATH is often times a pain. Now the makefile tries the node_modules directory in the same folder, first.
I went over most of the details in the discord already. Despite the name of the branch and some things I said previously, this works both locally and on HTML5. In fact if the tastool detects that it's not being run on web it will disable some compatibility patches in favor of speed (e.g. 8f05f29).
Although the fork isn't well tested there aren't any bugs I know about.
Bit could use a better XOR implementation, but the original one didn't work on web.
Default web keybindings could be better, but I don't want to force my (vi)ews on everyone by straying from the original control scheme too far.
My keybindings lib could be faster. I don't have evidence of any major slowdown though so I didn't optimize prematurely. The lib could also handle key combinations that are a subset of another combination in a better way, but that's a bit complicated, so right now it's handled by a hack from tastool's side (3ced5da).