Author Archives: Josh Tynjala

About Josh Tynjala

Josh Tynjala is a frontend software developer, open source contributor, karaoke enthusiast, and he likes bowler hats. Josh develops Feathers UI, a user interface component library for creative apps, and he is a member of the OpenFL leadership team. One of his side projects is Logic.ly, a digital logic circuit simulator for education. You should follow Josh on Mastodon.

Adobe Flex 2 running on OpenFL in JavaScript instead of SWF?

Around 15 years ago, Adobe introduced Flex 2.0, ActionScript 3.0, and Flash Player 9. I jump started my career as an expert in building Flex components and apps. Eventually, my experiences with Adobe’s framework led to my creation of Feathers UI — which today runs on OpenFL with the Haxe programming language. OpenFL aims to be an implementation of the Flash Player API — but it can target many platforms, from native mobile and desktop to web browsers with JavaScript (no plugins!). Over the years, I’ve also been a contributor to the Apache Royale compiler — which generates JavaScript from ActionScript 3.0 code. You are probably already seeing where this is going…

Edit: I updated to Flex 3 now

Is there some way to get a Flex application to run on OpenFL instead of Adobe Flash Player? OpenFL can target JavaScript, and Apache Royale can compile ActionScript 3.0 to JavaScript. Can both technologies work together? See for yourself: Demo: Adobe Flex 2 running on OpenFL.

Before you fall too far down the rabbit hole, let me warn you that this is all held together with bandaids, bubble gum, and duct tape.

Yes, it’s using the real ActionScript 3.0 source code included with the Flex 2 SDK, compiled to JavaScript with Apache Royale. It’s not a mockup or another GUI framework made to look like Flex. I had to make a few minor modifications to Flex classes due to slight differences between Flash Player and OpenFL, but most of the code is exactly the same as what Adobe/Macromedia wrote back in the day.

For an example of what I needed to tweak, the parent property of the DisplayObject in OpenFL is not a getter and setter (like it is in Flash Player). It’s a simple variable field instead. So when Flex tries to override the parent property to hide internal implementation details, that doesn’t work very well. I ended up modifying the code to use the internal/private _parent variable in several places to ensure that layouts worked the correct way. A more robust solution would be necessary for a real-world app (maybe a new public uiParent or flexParent property?), but this got things working quickly for my demo. Similarly, I had to tweak Flex’s overrides of some display list APIs, like addChild(), to handle some minor differences where OpenFL needed some extra hints to use only its internal APIs and not overrides. I also had to comment out some ApplicationDomain stuff that really only applies to SWF files loading child SWF files in Flash Player.

If you’re on a high DPI screen on desktop, you may notice that everything is rendering at the proper size, but it’s not blurry! This required adding some new code to Flex to smartly scale the SystemManager root display object. Basically, I just set scaleX/scaleY, and then any calculations in the framework using stage.stageWidth or stage.stageHeight needed to be tweaked to divide the width/height by by its respective scale property. I can’t stand looking at blurry Canvas/WebGL, so I decided to take some extra time to make things look good.

I did only enough work to get the Application, Button, and Alert components working, and that’s it. I’m sure that every Flex component would require at least some superficial tweaks. But I’m also impressed at how much code “just worked” and that I needed to focus on specific areas only. It really shows how well OpenFL emulates the Flash display list and vector drawing.

I had to manually bootstrap some things when the Flex app starts up, similar to the way that the Flex SDK compiler generates code for you automatically (you can see some of this generated code when you use the -keep-generated-actionscript compiler option when using the original Flex SDK compiler). For instance, I had to manually populate Flex’s StyleManager. The Royale compiler compiles CSS to native browser CSS for HTML, so that was never going to work for Flex running on OpenFL in HTML Canvas/WebGL anyway. Flex CSS is a simple subset of browser CSS, so I mainly just did a few Find/Replace commands in my editor to generate ActionScript from parts of defaults.css I copied from the Flex 2 SDK.

MXML only kind of worked. I could create a root component, set some properties, and listen to events, but adding children failed. The Royale compiler actually supports MXML with all of the bells and whistles, but the way that this gets converted to JavaScript isn’t really in the right data format for Flex to understand. With a few tweaks to the Royale compiler, and by adding some some additional parsing code to Flex, it could easily be done, though. For this demo, that wasn’t necessary.

I chose the very old Adobe Flex 2 released in 2006 instead of the newest Apache Flex 4.16 because I figured I would be most likely to find success creating this simple demo with an early version of the framework that hadn’t grown very complex yet. After completing this demo, I still believe that this was the right choice, but I also feel confident that Flex 3 or Flex 4 could also be feasible now that I have experience getting Flex 2 working.

Unfortunately, I’m not sure that I can legally share my code for this demo. Version 2 of Flex was still a commercial product (even if source code was included for customers to read). It was a later version of Flex that Adobe released as an open source project. I don’t think the open source license extends to previous versions. While I doubt Adobe legal cares about a discontinued product that eventually became open source, better safe than sorry. If you really want to see more, you should try to get in touch with me privately.

EDIT: I updated the project to use Adobe Flex 3, which was the first version that Adobe released as an open source project with the Mozilla Public License (MPL). Download the complete source code for this proof-of-concept from Github:

Github repository: openfl-adobe-flex-poc

Anyway, I just wanted to share a bit of nostalgia with you today. Back in the mid 2000s, Adobe Flex was a really great way to build rich applications for the web — an impressive precursor to today’s SPAs/PWAs (single page apps or progressive web apps) built with frameworks like React, Vue, or Angular. I owe much of my early career growth to Flex. Even if I can’t use Flex in my software development anymore, I still try to remember some of its spirit as I work on Feathers UI for OpenFL. That being said, it was ridiculously fun to use the real thing for the first time in a very long time!

Building an arcade at home: Part 1

Visiting an arcade filled with a cacophony of digital sights and sounds was always an exciting experience when I was young. I dropped so many quarters and tokens into those machines back in the day. I didn’t matter whether the place was filled to the brim with dozens of shiny new games, or if it was some dark corner of a pizza parlor with a couple of tough, old cabinets that had seen better days. When I saw an arcade, it wouldn’t be more than a second or two before I asked my mom if I could play.

While setting up my home office, I knew that I definitely needed an arcade cabinet standing in the corner. I’d install MAME on it so that I could play all of my old favorites, I’d set it up for two players going head-to-head or playing co-op, and it definitely had to be full-sized. Go big or go home, right?

Okay, so technically… I started with something much smaller than a full-sized cabinet, as you’ll see below. Later, in the upcoming part 2 of this series, I’ll share my experience upgrading to the big cab.

The thing that I was most excited about with this project was wiring up the buttons and joysticks and seeing a game actually respond to something that I had built myself. Yeah, it would just be some off-the-shelf parts that I bought and assembled, but still… creating something physical (even if it’s not too complex) brings me a really visceral sense of satisfaction.

Anyway, the extent of my experience with anything resembling this kind of project was mostly building a couple of gaming PCs from parts. On the electrical side, I also learned some basic wire splicing to fix a damaged cord on a table lamp, and I’ve upgraded some light switches in my house. I’ve always wanted to learn more about how to build fun, little custom gadgets, so after those previous projects, this feels like a natural progression.

The Enclosure/Case

With learning to hook up the wired controls being my primary interest, I didn’t want to overwhelm myself with too much complexity on the other tasks. A full-sized arcade cabinet could wait while a learned a thing or two first. Instead, I decided that I should start by creating some kind of small enclosure for the joysticks and buttons, where I could connect it to the TV in my living room.

I took a woodworking class in high school, but that was nearly 20 years, and those skills are long forgotten. Keeping my eyes on the electronics that I wanted to focus on, I looked for some kind of kit with pre-cut wooden pieces that wouldn’t require too much work (but also wouldn’t feel as basic as something from IKEA either). I hope to spend more time learning basic carpentry skills someday in the future, though. Just not right now.

LEP1 Customs LVL2GO arcade stick kit

I settled on the LVL2GO 2-player arcade stick kit from LEP1 Customs. It requires a little wood glue and a screwdriver (a drill is easier, from my experience). I also used some clamps to hold the parts tight while the glue dried.

This kit doesn’t seem to come with any instructions. Some basic illustrations or a photo of the finished interior would really improve this kit, in my opinion. It’s not super complex, but I had to pause for a bit to try visualizing how everything should go together before I could feel confident getting started. In the end, I’ll admit that this was kind of a fun puzzle.

The Computer

For the computer, I started with a Pandora’s Box DX “Family Version”. It’s basically a Chinese grey-market emulation system preloaded with a bunch of games. The idea was to get a plug-and-play system with little to no special configuration required.

Pandora’s Box DX from AliExpress

I bought it from the Pandora’s Box Official Store on AliExpress, along with its special wiring harness that connects to the joysticks and buttons. The shipment arrived from China within a couple of weeks. I also ordered a generic AC power adapter from Amazon, since one was not included with the Pandora’s Box.

A Raspberry Pi running RetroPie is another compelling option for arcade emulation. RetroPie requires a tiny bit more configuration to set up, so I decided to wait and try it later. Again, keeping things simple on my first try!

Joysticks and Buttons

For the arcade controls, I decided to go with the very popular Sanwa JLF joystick along with Sanwa OBSF-30 buttons for the main controls, and I used some smaller OBSF-24 buttons for secondary coin/player buttons.

Photo of two Sanwa JLF joysticks, 16 larger OBSF-30 buttons, and 4 smaller OBSF-24
Sanwa joysticks and buttons

Here’s what I picked up on Amazon (paid links):

Two other popular brands that create arcade controls are Seimitsu and Happ. As I understand it, if you really want to re-create the American arcade experience to the last detail, with convex buttons and the right joystick tension, you should consider going with Happ. I chose Sanwa mostly because I liked their appearance. If you’re interested in a deep dive, the Slagcoin Joystick and Button guide seems like it really goes into great detail about the differences between brands.

Final Assembly

The Pandora’s Box wiring harness has spade connectors at the end of each wire, and those easily slip onto the buttons. The wires are color-coded and the manual includes a lookup table. No soldering required (but I’d love to learn that skill eventually). The joystick has it’s own connector for the five wires that it uses (one for each direction, I think, plus a ground wire).

A ground wire is daisy chained from button to button. Unfortunately, the smaller secondary buttons were far enough away from the larger six main buttons that the last couple of daisy chain connections didn’t quite reach. I ended up pulling an unused wire from elsewhere, and I spliced it in to extend the ground wire. I used a couple of 3M Scotchlok connectors that I had left over from another project.

Interior. All wired up!

The exact placement of the Pandora’s Box inside the enclosure turned out to be important because, if the computer were placed directly below a button, it would stop the button from completing a full push down. It also bent the spade connectors a bit at the same time. I found a good spot slightly off center that seemed to work decently, even if it overlapped some buttons. A taller and wider computer would have prevented the enclosure’s top from closing at all.

Top view. Cover closed. Buttons and joysticks inserted.

I intend to paint the enclosure eventually, but I haven’t been in the mood to do that yet. For now, I don’t mind the unfinished wood.

To connect to a TV, the Pandora’s Box uses a normal HDMI cable. It turns on immediately when plugging in the AC adapter. No power button or switch, but you could buy one, if you prefer to leave it plugged in.

I’ve had a lot of fun with this little project! I’m excited for the full-sized cabinet upgrade too. At the time that I’m writing this, I have the cabinet assembled and everything is wired up. I need to organize the internals better, and I’m considering adding hinges in a couple of places, to create easy access panels. I’ll do another writeup with all of the details soon!

Feathers UI for Haxe and OpenFL: Now live on Kickstarter

UPDATE: Feathers UI for Haxe and OpenFL is fully funded on Kickstarter!

UPDATE: For the latest news and announcements about alpha/beta preview builds, follow the Feathers UI blog.

About eight years ago, I open sourced the code for what would become Feathers UI. I was spending my days trying to be an indie game developer at the time, and I had recently tried out Daniel Sperl’s excellent Starling library. I could see that if my games switched to Starling, I’d get smoother animations and other performance improvements. For my games, I had already created a basic set of user interface components (buttons, lists, toggle switches, sliders and things like that) that worked on both iPhone and Android. After recreating those UI components in Starling, I decided that others might find them useful for building apps too. Publishing them on Github would change my life for nearly a decade.

Today, the technology landscape has changed a lot compared to 2011, with all sorts of new mobile devices — and web browsers that no longer allow plugins. While Feathers UI was generously sponsored by a company for a number of years, they’ve now moved in different strategic directions that, sadly, won’t include Feathers. Yet, over all this time, Feathers UI has grown and matured well beyond anything that I had ever imagined. Software developers have created so many amazing apps and games, and I am constantly inspired by how they use Feathers in incredible new ways. Certainly, much has changed on the web and in the wider realm of technology, but I believe that Feathers UI still has great value for software developers building creative apps and games.

That’s why I’m launching a Kickstarter for Feathers UI, and I hope that you’ll support this project by becoming a backer. I’m looking to rebuild Feathers UI on a new foundation that will continue to make it easy to build cross-platform user interfaces on mobile, desktop, smart TVs, and even game consoles. This new version of Feathers UI will use the Haxe programming language and the OpenFL library. Developers who are already experienced with Feathers UI will feel right at home with a similar language and familiar APIs, but also new features and access to new platforms.

Support Feathers UI on Kickstarter

Additionally, I’m going to make Feathers UI into a more sustainable business that can fund itself going forward. I’m planning to introduce new premium add-ons that developers can purchase to support Feathers directly. These add-ons will include new advanced components (like charts and graphs), pre-made themes in a variety of styles, and in-depth technical educational content that teaches you the inner workings of Feathers UI. Of course, the core Feathers UI library will remain open source, and it will continue to expand with new UI components and features! These add-ons will be for developers with more specialized needs.

I may have written the code for Feathers UI, but the community gave it life. I hope that you will back the project on Kickstarter and help me re-imagine a modern Feathers UI that takes the best of the original Starling version, combines it with the advantages of Haxe and OpenFL, and makes it better than ever. Keep this excellent UI component and layout library in your toolbox by showing your support on Kickstarter.