LÖVE

Oh, that's a shame.

I think you can get the latter error kludged up by making all these locals in the beginning of the files a globals, that would tamper performance a bit though.

As for former, I have a vague idea what went wrong. The code have hard-binded joystick hat mappings, and that line would expect the joystick hat to exist, whereas under OS X, XBox controller wouldn't have one. This is particularry what I've tried to solve with cock.remapJoystickHat. You can still use that: remap your hat "buttons" to the hat #1 and it should work (provided it would run at all). Now I see my mistake to assume that arbitrairly hard-binded joystick hat would exist to begin with. I'll patch that up, thanks for the bug report.

Jasoco wrote:

raidho36 wrote:Thanks for the input. Are you using LuaJIT by any chance? These operations are not related to the OS X and are confirmed to work with vanilla LÖVE on Linux and Windows, and there's no reason why lj_getNumJoysticks should've been an upvalue, let alone an undefined upvalue.

Yeah. They're both LuaJIT. (I'm on Mavericks which breaks all versions of Löve that are stock out of the box, so I have specially compiled versions of 8 and 9 with JIT since I can't use the normal ones from the website itself.)

0.9.0's joystick module is substantially different from any previous version, don't expect anything joystick-related written for 0.8.0 to work out of the box with it. In fact, I believe you're using a version which won't even work with the latest 0.9.0 changes or the old 0.8.0 API.

Thanks for clarification, slime.

Looks like the problem with 0.9 was that it's not supported by the library. The other problem was with poorly written demo and a missing failguard in the code.

That clears up the things. LuaJIT had nothing to do with the errors.

I've thought that my update loop is really bulky, and numerous "if-else"s have bothered me quite a lot. So I decided to rewrite the update loop. I took the inspiration from TLbind, which was grouping input by device rather than any other parameter, which allowed for iterating through the whole controls set and only using a single function to aquire input. That should've improved performance a lot, and make the code slimmer.

Turned out, it made the code twice as bulk, because there were certain snippets that were applied per-binding rather than per-device, so I had to copy-paste them all to every loop. I've managed to perform some fine-tuning and stripping extra characters while maintaining somewhat readability. The code ended up being only 30% shorter. Performance-wise, it was only 20% faster. Given that nobody digs into the sources that much, and that 100000 full update iterations for 12 bindings run in under 2 seconds (one such update loop takes 13.5µs, versus 16.2µs in last version), the difference is completely neglectible. I just wasted a good few of hours re-designing and re-implementing binding internal layout while I could just left it as it is.

Just for the sake of fairness, I decided to compare the performance to original TLbind library. Of course, given such miserable execution time, it makes no choice difference whatsoever, but I just wanted to know. I expected it to be vastly faster than COCK, several times or more, given former's simplicity. I almost instantly noticed that setting it up is pretty awkward. And while basics are straightforward, other things are quite obscure. There was no proper explanation how to use giveInstance either. Of course on top of that it didn't had an ability to use some features that I've applied to my own test control sets, but nevermind that. I recreated closest possible set to what I used for my own library. Because all other functions aren't called often, I only measured the update function.

When I ran the test, turned out that TLbind would run update loop in 11.7µs, versus 13.5µs of COCK performance, mere 20% difference. So it wasn't even that much faster, given it's simplicity.

What's the current status of 0.9 support? Is it coming soon or ever? I downloaded the demo and it's still crashing

Raidho's not been here in months, I highly doubt he'll update it