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.
Common Organization of Controls Kit (1.3 update)
- slime
- Solid Snayke
- Posts: 3166
- Joined: Mon Aug 23, 2010 6:45 am
- Location: Nova Scotia, Canada
- Contact:
Re: Common Organization of Controls Kit (1.3 update)
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.Jasoco wrote: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.)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.
Re: Common Organization of Controls Kit (1.3 update)
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.
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.
Re: Common Organization of Controls Kit (1.3 update)
Lol I am going to test out the C.O.C.K. library
Re: Common Organization of Controls Kit (1.3 update)
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.
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.
Re: Common Organization of Controls Kit (1.3 update)
What's the current status of 0.9 support? Is it coming soon or ever? I downloaded the demo and it's still crashing
Re: Common Organization of Controls Kit (1.3 update)
Raidho's not been here in months, I highly doubt he'll update it
lf = love.filesystem
ls = love.sound
la = love.audio
lp = love.physics
lt = love.thread
li = love.image
lg = love.graphics
ls = love.sound
la = love.audio
lp = love.physics
lt = love.thread
li = love.image
lg = love.graphics
Who is online
Users browsing this forum: Semrush [Bot] and 3 guests