NativeJoystick: AIR “ANE” extension to support all joysticks that Windows can.

I’ve made an AIR native extension (ANE) to handle joysticks in Windows.



  • Static runtime libs for DLL, release-mode, no dependencies besides system and small size.
  • Not newing anything for each poll (slow in Flash), nor dispatching events unless you actually add event listeners.
  • Supports up to 16 controllers, with 6 axes/32 buttons when available.
  • Finds OEM joystick name in registry.
  • Works with same product/manufacturer ID & USB serial number cheap controllers as long as Windows detects them.
  • Ditches Adobe’s GameInput API, which is buggy as hell [1] [2] [3]
  • Open source, MPL2.0 licensed (And almost ready-to-go projects)

Source and files

You can grab the source code for the DLL, the ANE, and the demo project on github:
(The demo is a FlashDevelop project, the dll is a Visual Studio 2013 for Desktop C++ solution).

You can grab the compiled “.ane” directly from github too:

How to use it on FlashDevelop

You must download the NativeJoystick.ane (it’s actually a ZIP file) and keep an unzipped directory of that file under the same name as the file for debugging. You must additionally modify two .bat files that FlashDevelop generates for AIR projects.

Read the file at github for further instructions (“How to use the ANE in your own FlashDevelop project”):


The source is mostly licensed under MPL2.0 (there’s a couple of MIT licensed files from FreeGlut). The graphical assets are CC-0 (Public Domain dedication). Basically: Modifications to the library must be made open & public with attribution but the application that uses it can be closed-source, commercial, static-link the library, whatever.

Posted: 2014-08-25 14:27 | Author: | Filed under: dev | Tags: , , , , , , , | 4 Comments »

AS3 benchmark: Function call vs. Lots of object-member access cruft.

Every 2 trillion years I update this blog with a benchmark test. I’m trying to migrate from AS3 but I still have open projects so I’ll be stuck with it for a bit longer and you might too, and this might be helpful.

I knew that function calls were slow on Flash, but man, they’re soooooooooo slow! I wanted to know if it would be more cost effective to call a function if I needed a lot of accesses to the object internal members rather than prefixing “object.” to each variable (e.g. an update call for a particle that needs to update several variables.)
So I set up some code to test for a lot of iterations the performance of an update call (CALL) versus just manually inline the function accessing the object variables multiple times (ACCESS). Where the function would do “x += vx*dt“, the inlined one does “particle.x += particle.vx * dt“. Also repeated the internal code 4 times (CALL4 and ACCESS4) to simulate a more complex class. The results where astonishing.

In release mode, even adding a lot of object access cruft (“obj.” before each variable), it ran in 1/3 the time in respect to the calls (ACCESS vs CALL)!!!
Even if all accesses are repeated 4 times, it ran in 59% of the time of a single function call (ACCESS4 vs CALL). My guess is that Flash is caching the object somehow and optimizing access.
Bottom-line: Manual-inlining is always better.

So here’s the data and graphics (log-log) to support my tests. You can clearly see the linear correlation maintained indifferent of the number of iterations, making it clear that the function call is the one slowing things down. Values are in seconds, top row is # of iterations.


And here you have the code to try it yourself:

You’ll need to call the static “run()” with the number of iterations you want and take the generated data from the static variable “out” (in release mode there’s no trace)

Posted: 2014-04-25 03:42 | Author: | Filed under: Uncategorized | 1 Comment »

Cryo-Skulls of Flappy Temple post-mortem


(click image to play online or download for android)

This will be a bit technical maybe, but closure is nice, so I decided to write up a little post-mortem anyway. Never did one!


I had two ideas for the flappy jam: A Joust-like with ostriches flying towards and attacking you, have the bottom be lava, et cetera. The other was about a reverse flappy bird, in which your objective was to kill the bird placing or moving obstacles. I contacted delfei, the graphic artist and graphic designer of the game, and to my luck she was available and willing to participate too. I was more inclined to the inverse mechanics idea and we both agreed it would be the most different of the two, and better.

Read the rest of this entry »

Posted: 2014-02-24 23:42 | Author: | Filed under: Uncategorized | No Comments »

HELI BRAWL dev announcement

I’m making this fast action 2 to 4 local multiplayer helicopter fighting and more game. Here’s a teaser!


Posted: 2014-01-16 19:13 | Author: | Filed under: Uncategorized | No Comments »

update(dt) versus global static frame time

I made a AS3 (AIR) benchmark to know if it’s better to update objects in an object chain (groups) passing the frame elapsed time “dt” (delta time) by parameter or just use a global static variable.

A global static is of course more confortable: Unclutters function parameter lists, also you can access it even from weird places outside the update chain (maybe drawing something depends on it, I don’t know)

Here are the results

DEBUG build

Mode Tree depth Total calls Time (±0.5) Frame % (±3)
update(dt) parameter 2 1110 1ms 6.0%
update() global static 2 1110 1ms 6.0%
update(dt) parameter 3 11110 6ms 36.1%
update() global static 3 11110 6ms 36.1%
update(dt) parameter 4 111110 56ms 337.3%
update() global static 4 111110 58ms 349.4%


Mode Tree depth Total calls Time (±0.5) Frame % (±3)
update(dt) parameter 2 1110 0ms 0.0%
update() global static 2 1110 0ms 0.0%
update(dt) parameter 3 11110 1ms 6.0%
update() global static 3 11110 2ms 12.0%
update(dt) parameter 4 111110 10ms 60.2%
update() global static 4 111110 12ms 72.3%

The benchmark used a tree-like structure of objects in which each object had 10 objects each (common scenario).
“Frame %” is the percent of frame time used just for dummy update calls in a 60FPS game, as a reference (the error margin is  ±3%)

Bottom line, global static is significantly slower for more than 10k objects but it’s OK for a few. It might make a difference for particle systems, so I’ll consider it. Also, repeated queries from a global static on a different object will decrease performance more. The parameter is in local scope so it’s as fast as a local variable.

Some other bonuses of passing as parameter are: you could have localized altered time scales for a branch of objects (e.g. slow motion in-game) but keep it normal for others (e.g. menues, HUD, or other counters).

A hybrid solution might be best, to have a static global updated once per frame to be able to use in weird places, but stick to update(dt) for performance where it counts the most.

Tests were ran on a 2.2GHz/4GB ram/Windows 7 64-bit notebook.

Thanks for reading.

Posted: 2014-01-08 20:06 | Author: | Filed under: Uncategorized | Tags: , , , , , , | 1 Comment »

Survive Quest released!

2BAM is glad to announce a new game!

A short adventure game, homage to the hardness of the genre classics of the EGA era.

The mayor part was built in 2011 but was never released, I got around translating it the last week, got help proof reading all that, fixed a bunch of bugs and nuisances, improved the controls and the visuals of texts. And finally, it’s done!

Click here to play!


SurviveQuest-screenshot-1 SurviveQuest-screenshot-3

Posted: 2013-07-14 21:41 | Author: | Filed under: games, Survive Quest | No Comments »

CJR map generation is moving forward

I’ve found a lot of obstacles and I’ve been thinking and reworking the map generation system. Lately I didn’t code that much because I wanted to make good decisions beforehand.

Today I’ve reworked some my Graph ADT classes to make them more abstract and reusable along the code. Although is hard to work without templates (AS3), it tries to be comfortable (keep auto-completion, expandable data structures) but yet keep good performance (no data adapters as AS3 doesn’t support static variables outside the primitive  types).

Also I’ve made some progress in map generation. I’ve made a empty-space rectangle-fitting algorithm that works really well and I’m happy I managed to figure out a not so much brute force way to do it. You can try the test online clicking here (Flash). The test is for a massive map (9000×6000 pixels), just to be on the safe side when testing. Lower divisions (“resolution”) take more time to process(1 tile division might take as long as 30 seconds!), but as you can check, higher resolutions don’t change the final organization very much.


Posted: 2013-02-14 21:46 | Author: | Filed under: CJR, links to test | Tags: , | 1 Comment »

IndieGames coverage of CJR demo!

I was contacted by John Polson of IndieGames with a couple of innocent questions and the next thing I know I’m at the front page of their blog! Amazing 🙂

Here’s the link to the article:

Posted: 2013-02-03 19:02 | Author: | Filed under: CJR, press | Tags: | No Comments »

Messing around with some chained explosions…

I’ve been messing around with the weapon customization menu in CJR.



Posted: 2013-02-02 04:44 | Author: | Filed under: CJR | 1 Comment »

Syndication plugin enabled!

Hi there!

Shape Mage

This is a syndication plugin test that should post to my twitter and facebook accounts.

Read the rest of this entry »

Posted: 2013-01-30 09:39 | Author: | Filed under: Uncategorized | 2 Comments »