@All - I just released a new update to the Pro Version see features list below). Additionally, there is now a lite version for those who want to try it first: LITE VERSION.
@Rob,
Sure, let me explain what my tool kit does for you
#1 Changes Green Throttle to a events based model versus polling.
Normally, if you wanted to check whether the A button on a controller was pressed you’d write this code (may have errors, written from memory):
local greenthrottle = require('plugin.greenthrottle') local function onEnterFrame() gt\_startFrame() -- Get latest inputs -- If device is connected continue with polling... if(greenthrottle.getConnectedState( greenthrottle.CONTROLLER\_1 )) then -- Is BUTTON\_A down? if( greenthrottle.getButtonState( greenthrottle.BUTTON\_STATE\_DOWN, greenthrottle.CONTROLLER\_1, greenthrottle.BUTTON\_A) ) then print("Button A on controller 1 was just pressed!") -- Do something.... end -- Want to check for more states and more inputs? The code gets longer fast. end return false end Runtime:addEventListner( "enterFrame", onEnterFrame )
Not only is this long, but it in’t like touch processing at all, which makes it a bit harder to deal with for less experienced Corona SDK users.
With my toolkit you can achieve the same code like this:
local gtevent = require "gttools.gtevent" gtevent.start() local function onButtonA( event ) if(event.phase == "began") then if(event.num == 1) then print("Button A on controller 1 was just pressed!") end end return true end Runtime:addEventListener( "gt\_a", onButtonA )
#2 Allows you to route Green Throttle device inputs back to the simulator. - Yes, all Corona SDK Pro users can include the standard greenthrottle plugin by adding it to their build.settings file. This gives you access to stubbed out versions of the polling functions. These don’t do anything on the simulator, but get linked up to the plugin when built for the device. In short, while you can write and run your code on the simulator you can’t actually test it till it’s on the device. My toolkit has code in it that let’s you route back to the simulator. The above code could be run on the simulator as follows:
A. Modify above code to look like this:
local gtevent = require "gttools.gtevent" gtevent.start() if( system.getInfo( "environment" ) == "simulator" ) then local gtreceiver = require "gttools.gtreceiver" gtreceiver.start() else local gtsender = require "gttools.gtsender" gtsender.start() end local function onButtonA( event ) if(event.phase == "began") then if(event.num == 1) then print("Button A on controller 1 was just pressed!") end end return true end Runtime:addEventListener( "gt\_a", onButtonA )
B. Build it and install it on an Android device that has been paired with a Green Throttle controller.
C. Run the Android copy.
D. Run the simluator.
E. Turn on your controller and push button A. The simulator will print this:
Button A on controller 1 was just pressed!
So, how does this work? Well… without giving up the secret sauce…
I bundle up the events on the android device and send them over WiFi (via a UDP connection) to the simulator.
I originally wrote my own UDP code for this, but found that the (free) AutoLAN library worked better because M.Y. Developers did a nicer job of configuring sockets as well as packing/coalescing the data before sending it. In short, they send bigger packets at a higher rate. So, since its free and has a nice license I used their code as the backbone for the UDP connection.
#3 More features… - I’m still working on this product, but I have added all of these features so far:
-
Polling to events conversion - Discussed above.
-
Green Throttle to Simulator Event Forwarding - Discussed above. Note: This can also be used to send one controller’s inputs to multiple devices (of any type) so you can test on multiple devices simultaneously. Not sure how useful this would be, but it is technically possible.
-
Smart Polling - I added the ability to configure the event convert to selectively poll for only those inputs you care about. This can be set on a per controller basis.
-
Overall Polling Rate - I added the ability to easily change from checking inputs every frame to every 2nd, 3rd, …
-
Digital Polling Rate - Like the overall polling rate, I added a separate way to poll digital inputs more slowly. You usually want to check analog inputs every frame, but digital inputs can be checked every 4th … 8th frame (at 60FPS) with no noticeable effect on usability. This will save battery life.
-
Controller enabling/disabling - Of course, you can selectively ignore devices to save more juice. No need to check for devices that will never be attached.
-
Examples: Lots of examples, including simple, sender/receiver, event dumper, visual event dumper, single player pong (joysticks control paddles), and the latest one a game framework with a splash scree, main menu, and blank play/options/credit GUIS, all hooked up to the controller.
-
… - More features and documentation are coming.
The following video shows Green Throttle controlled code running on the simulator :
http://www.youtube.com/watch?v=PwL2LZ1VAt0
(Note: The pong example looks a little jerky because tied the analog sticks directly to the position of the paddles which is not the right way to make a smooth positional control. You’d be better off treating the sticks like digital inputs [which you can do] and then moving the paddles up or down at fixed rates.)
If anyone is still reading and want to get this, you can get it using one of these links.
Gum Road (for CC users) - https://gumroad.com/l/fzOt
Sellfy (for Pay Pal users) - https://sellfy.com/p/H0s4