DreamEngine allows designers to make bots that can design things automatically, such as logos, websites, or artwork. Customers can use these bots via the DreamEngine website, or an API.

Note: none of the logos in the image gallery were commissioned by those companies!

Currently under development, GigaDraw is a tool for professionals to use for designing logo and brands automatically. It uses the DreamEngine API to generate different output.

An experimental emulator for glsl fragment shaders that runs on the CPU. shdr is useful when standard GPU debugging methods won't cut it; it lets you inspect variables on a standard CPU debugger. The shader output can also be exported to a png file.

Motivations

To debug glsl, the usual method is to simply dump suspect variables out to gl_FragColor. This provides fast visual feedback for where things might be going wrong. It is usually the best method for debugging glsl, and is particularly useful in conjunction with a tool like ShaderToy.

This debugging method stops being effective when your shaders become more complex, particularly when you need to debug multiple variables. Sometimes, you just want to look at your variables in a standard debugger, or to dump them out to the console.

I think the Visual Studio Code javascript debugger is the best available for any IDE or programming language, and it's what I've been testing this on. Javascript is also a good choice as an emulation language, since it already has very similar syntax to glsl.

This library may also be useful as a server-based program that can be used to generate static images with glsl, particularly in cases when an OpenGL context is impossible to create. ... (See full article)

This project was a prototype for the later DreamEngine project that allows designers to design things using algorithms.

A VR app to help people design their own VR and AR experiences.

A node js wifi manipulation utility for Ocean devices that run Debian Jessie.

Ocean devices must be setup with either BlueTooth or a USB serial cable. This library was used to help automate the process.

This is a derivative of tlhunter's excellent node-wireless library: https://github.com/tlhunter/node-wireless.

Ocean MDM was a React/Node web app for interacting with Ocean devices, specifically for managing mobile phones.

Not dissimilar to Android, the Ocean OS was a linux-based OS for running on Ocean devices. The Ocean CPU used ARMv7.

I should write about this in more detail, but here are some highlights:

• There were actually TWO OSes, the second being firmware for an onboard chip for power and USB management - the MCU.
• We had an API so the linux OS could communicate with the MCU: (https://github.com/GetOcean/ocean-mcu-comm-api)
• We had additional drivers for a hardware test fixture for Ocean devices.
• We had our own linux kernel, open sourced on github.
• To get our WiFi/BT/BTLE chip working, we had to do lots of tedious Bluetooth and WiFi linux backports.
• We created an OS build server, with test scripts and unit tests for verifying the OS build on an Ocean device.
• Sourced chipset firmware with dubious binaries (https://github.com/GetOcean/ocean-os-bt-firmware)
• Wrote a C++ library for talking to iOS devices without blowing up the CPU.

And so on. Just because we didn't have to write the kernel doesn't mean building an OS is easy! ... (See full article)

From 2014 to 2016 I worked at iCracked in Redwood City, California, on the Ocean project. I was overall leader on the project.

Ocean was a combined hardware and software project, with the aim of bridging the gap between mobile phones and desktop computers. At the core of the project was a small handheld general purpose computer that we designed from scratch. The computer ran Ocean OS, a custom OS, along with a lot of custom software. We also built a suite of cloud software to support the devices: a core api, and various web and iOS apps. The complexity of the different pieces of project was - at times - difficult to deal with for our small team. But we got there in the end, shipping the product out in 2016.

Our initial unique selling proposition was that you could put several Ocean devices in an office, and then you could instantly manage any mobile phone or IOT device in the office. It could also detect potential intrusion threats or blacklisted devices.

Ocean was also billed as a mobile computing platform, designed to interact with mobile phones in whatever way possible. The primary interest was that iCracked's 5000 strong iTech network would carry an Ocean with them, and use it to automate various tasks on the customer's iPhone. These tasks included backups and restores, detecting hardware errors on the device, and so on.

The scope of this project was vast, and very technically challenging for me and the people on the ... (See full article)

This was the first VR app prototype I worked on. It allowed you to listen to music while in VR, with the environment around you flashing and pulsating in rhythm to the music.

It never really worked properly because rapidly moving objects in VR tends to overwhelm your senses very quickly, and thus I had to drastically tone down the effects until they were almost negligible. This was a surprising limitation about VR -- close objects must remain relatively stationery. If they are pulsing and gyrating the human brain appears to get confused very quickly.

I developed this app using the VastDevKit, which I sort of developed in parallel.

Difont is a font rendering library for OpenGL 3, OpenGLES 3, and DirectX. The library is a hard fork of ftgles.

Still currently maintained.

League of Shadows was a game for iOS and Android. We started development on it in late 2012 and ultimately shipped it in the second half of 2013.

It was probably one of the more complex pieces of software I've ever worked on, because it combined so many different elements together.

• Rasterized 3D artwork
• Complex character animation
• Asynchronous multiplayer (and thus server infrastructure).
• Detailed particle effects
• The first version of our social network

There were numerous challenges to solve with this game. Firstly, we had to take the huge quantity of character animation files and compress them into a format that allowed us to stay below the 50mb total file size. We ultimately had to build our own file format for this.

Secondly, we had to build out server infrastructure to support the multiplayer gameplay elements. We used a service called Parse to help with this, but we also had services running on Heroku, AWS and so forth. Building out this infrastructure was new to us and we had to learn a lot about how to best go about it. While asynchronous multiplayer was easier to implement than real-time multiplayer, it could still cause multiple fires, when you have 100k concurrent players.

The game was ultimately inspired by a facebook game called "Backyard Monsters", which also inspired "Clash of Clans" by Supercell. They beat us to the market with their game, and we had a hard time competing with them. ... (See full article)

Little Dragons was a game for iPhone, iPad, and Android devices, developed when I was at PlayCoMo. We both started development and released the app in 2012.

It was featured prominently on the Android app store in 2012, which resulted in the game getting millions of downloads on Android.

Core game engine and tools for making PlayCoMo's iOS and Android games.

I was "co-founder" and CTO at PlayCoMo. "CTO" doesn't really cover it: I did everything from product management, game and level design, tools engineering, talking to artists, hiring, and so forth.

We were a small team (never greater than about 20 people by my estimation) spread across five different countries. We worked on over ten games for both iOS and Android, shipped six, and got millions of downloads.

Madbrix is a puzzle game that combines physics with match-3 gameplay. Uniquely coloured blocks would fall from the top of the screen into an arena. The player had to connect similarly coloured blocks together in chains of three or more. They do this by dragging the blocks around the arena, taking care not to collide with other blocks or chains. Creating a chain will clear the blocks from the arena and earn the player points. As the player cleared more chains, the blocks would fall from the top of the screen more quickly. Blocks could fall off the arena into a dead zone at the bottom or side of the screen. When this happened, the player lost a "life". When the player lost all their available lives, it's game over.

I had already built a lot of infrastructure to support Smashed (as well as a large number of other unreleased games) and so I was able to build and ship the game quickly in 2010. This is also the first game I developed to run on an iPad.

I might re-release the game: watch this space! ... (See full article)

Smashed was the first game I shipped for iOS. It was a physics game, where you had to smash down the architecture on each level to achieve certain goals. There were 8 episodes, with each episode containing 8-10 levels a piece. My brother helped create an awesome soundtrack for the game.

This is just a couple of random thoughts about the development of the game.

Custom Engine

I ultimately decided to write my own game engine for Smashed. There were a couple of reasons for this:

• I wanted to learn how to do it, and thought I had the skills to do it.
• There were no decent game engines or dev tools for iOS at the time. I don't even think Unity supported iOS until 2010, and it wasn't really worth using for iOS until 2013.
• I would have complete control over tooling, optimizations, and so forth.

Optimizations for iPhone Floating Point Chips

It was basically impossible to predict how players would approach the game. I had to plan for the most complex possible physics interaction on each level. But this proved to be a problem; the complexity of the physics interactions caused extremely slow frame rates on basically all the iOS devices. This was true even with all of the gcc compiler optimizations turned on. Back then, the compiler wasn't really tuned to take advantage of the available hardware.

Ultimately I had to dive into ARM assembly, writing matrix calculation functions that could take advantage of the SIMD instructions. This ... (See full article)

I wanted to see if my old painting skills could be revived. With a tablet, a couple of tutorials, and some stock photography, I went ahead and painted some portraits.

The idea was to print out each stock photography photo, and then attempt to recreate it as best as possible in photoshop, with the tablet, without tracing anything. I followed a pretty standard method of drawing a contour outline, and then block out colour within that outline. I would add a new layer when I wanted to work at a different level of detail.

I've added a gallery of each of the layers I used for each portrait. The layers don't really convey the trial and error I went through for each one to get it looking right. Often the hardest step was the initial contour image.

I ended up using the portraits in an iOS game, Smashed

FTGLES is an OpenGLES C++ library for rendering TrueType and OpenType fonts on mobile operating systems. FTGLES is a port of FTGL.

I wrote the library to render fonts in mobile phone games. I've used the library myself in apps that have been downloaded millions of times, not to mention apps made by others (which I don't have much information on). The heavy use means that the library has been battle-tested fairly well and is very efficient.

I periodically update FTGLES but it has mostly been superseded by DiFont which has better shader support.

See the Demos folder for several comprehensive sample iPhone apps. The demo apps include a unicode demo, as well as a demonstration of how to use layouts to easily align and position text.

FTGL

"Unlike other OpenGL font libraries FTGL uses standard font file formats so doesn't need a preprocessing step to convert the high quality font data into a lesser quality, proprietary format."

"FTGL uses the Freetype font library to open and 'decode' the fonts. It then takes that output and stores it in a format most efficient for OpenGL rendering." ... (See full article)

This was my first proper game development studio. Over 18 months I prototyped ten games, build two game engines, and shipped two games.