Arduino sketch for TFT display rendering using serial commands

I've been using a Seeed Studio Wio Terminal as an external display for a Raspberry Pi. I initially wrote an Arduino sketch that took high level, application-specific commands over serial and rendered appropriate display elements. This has the disadvantage that adding UI features required updating the Arduino code, which is more of a pain and slower to iterate on.

Instead, I'm now planning on sending rendering commands over the serial interface - turning the microcontroller into a general purpose rendering device.

I've thrown my initial code up on GitHub here:

github.com/mikeoliphant/SerialTFT

It currently only supports a small set of commands for rendering rectangles and text. I'll be adding more features as I need them.

Speeding up Arduino TFT (TFT_eSPI) writes

 I've been recently playing around with "Arduino" microcontroller stuff - specifically a Seeed Studio Wio Terminal.

Playing around with the TFT display, I noticed that drawing to it was pretty slow. After doing some research, I found out that direct TFT writes are indeed quite slow. But there is an easy way around it.

The TFT_eSPI graphics library, a modified version of which is used by the Wio Terminal, provides a Sprite class that can be used to do quick TFT writes. If you have enough memory (which the Wio Terminal *just* barely does), you can create a full screen-sized sprite.

The Sprite class supports the same drawing API as the main TFT class, so it is pretty easy to convert code that is writing directly to the TFT to use a Sprite instead.

To initialize it, do this:

TFT_eSPI tft = TFT_eSPI();

TFT_eSprite screen = TFT_eSprite(&tft);

In your setup(), after initializing the TFT, do this:

screen.createSprite(tft.width(), tft.height());

Then, use "screen" instead of "tft" for all of your drawing calls. When you want to update the TFT with the current state of your sprite, do this:

 screen.pushSprite(0, 0);

That's it! The result is a display that will update *much* faster.

One caveat is that this method uses up the vast majority of the Wio Terminal's RAM. It works fine for me, since my application is not otherwise particularly memory hungry. More complicated applications (using WiFi, for example) may run into problems. If that happens, a good (if more complicated) solution would be to use a smaller screen area sprite and do targeted writes to sub-areas of the screen.

PixelMaker - a pixel art and sprite drawing program

I've been thinking about making a sprite editor for a while now. Drawing sprites is a big part of what we do when making our games. We have been using GIMP as our primary drawing tool, and while it works pretty well, it doesn't mesh perfectly with our workflow.

So, a few months ago I finally pulled the trigger and started working on PixelMaker. In order to justify making a polished program (instead of a rough-and-ready developer tool), we plan to release it on various platforms - initially on Wii U (the GamePad and stylus are great for drawing) and then later on mobile/PC.

I'm pretty happy with how it is turning out. It loads instantly, unlike programs like Gimp and Photoshop, and is fast and lean - with the features you need for drawing pixel-y stuff, uncluttered by features you don't need (at least *we* think so - we'll see once we have more customers...)

Our initial feature set for release targets drawing individual pixel art pieces, but future planning includes frame-based animation.

On a more dev-centric note, I recently bolted on a project structure interface for us to manage the art assets for a game - designed to integrate with the custom sprite scaling/shadowing/sheet-packing pipeline we currently use:



We plan to get back to working on our already-well-in-progress next game soon, now switching over to using PixelMaker as our core art creation and management tool.

What next game is that? Well, stay tuned for more on that soon!

Fractopia - fractal rendering with the GPU on PlayStation Vita

The above video shows Fractopia, my GPU-powered fractal explorer for PlayStation Vita and PlayStation Mobile certified Android devices. Sorry about the poor focus - it's hard to film yourself playing something on the Vita!

I had the idea to try GPU-accelerated fractal rendering on the Vita a while back, but I didn't get around to actually messing with it until a few weeks ago. My initial experiments turned out quite well, so I took the time to make it into a full-fledged application.

As you can see in the video, Fractopia allows smooth panning and zooming of fractal imagery. It allows you to navigate the Mandlebrot and Julia fractals, and lets you change the Julia seed in real time to create a huge variety of interesting "fractalscapes" to explore.

Fractopia has passed PS Mobile certification, so it should come out on PSN in the next few weeks.

Block Zombies: Aerial News Footage of the Infected Zone

Here is a video using the CRT screen effect I mentioned in my last blog post.

I'm planning on using something like this as an intro scene, or perhaps as the backdrop for my game menus.

Using shaders to create an old CRT TV screen effect

I've been playing around with adding an effect to make Block Zombies look like it is playing on an old, crappy TV. It still needs tweaking, but it is starting to get close to what I want.

Using a couple of screen-space shaders, I'm blurring, adding scanlines, desaturating and adding darkened corners.

I'm not planning on using this effect in-game, but I'm thinking that the intro will be some sort of news-ticker with footage of the scene of the zombie outbreak.

Block Zombies: Dark and Stormy Gameplay

I've been working on adding darkness, thunder and lightning to Block Zombies.

I used a modified version of the technique I used for Kung Fu FIGHT! - tweaking parameters in my bloom shader to do most of the work. Because Block Zombies is 3D, I also mess with the light direction, which does fun things with the shadows when lightning strikes.

Because the effect is just manipulating lighting and bloom parameters, it is basically cost-free. I haven't added in actual rain yet, since that definitely wouldn't be cost-free, and I'm not sure I can afford the extra overhead.

The glowy zombie eyes, windows and sparks are done by reserving a section of my color palette that my shaders recognize and treat as being self-lit.

Disabling Aero From Within a .NET Application Using DwmEnableComposition

First off, why would you want to disable the Aero theme? Well, it turns out that it messes with vsync and can screw up the framerate of some applications. DirectX apps seem to be ok, but, in my experience at least, it really messes with OpenGL.

To disable it from within a .NET application you need to DllImport dwmapi.dll. To do this you need to reference System.Runtime.InteropServices:

using System.Runtime.InteropServices;

Within one of your classes - usually where you have the application entry point - you need the following:

[DllImport("dwmapi.dll", PreserveSig = true)]
public static extern int DwmEnableComposition(bool enable);

To invoke the method, simply do this:

DwmEnableComposition(false);

Kung Fu FIGHT!

Marvel at the glory of my pixel art skills!

This is the current version of the intro to Kung Fu FIGHT! - my upcoming game for Xbox Live Indie Games. The intro is still a bit rough around the edges, but at least I've got a first pass done.

Now, back to working on gameplay for a while...

Ludum Dare #19

I'm participating in my first Ludum Dare 48hr game development competition this weekend. In the spirit of trying something new, I'm also using Unity3D for the first time.

The competition theme is "Discovery". This video shows some of what I have so far. One of the tough things about this competition (other than the 48hr time limit, of course) is that you have to create everything from scratch.

I'm better at drawing planet textures now than I was this morning...

Water, Reflections and Fish

I just finished adding water/reflections back into my engine. Now I have a pond with some fish in it.

I don't think I'm going to be able to resist adding fishing to the game...

Shadows!

I've got shadows working pretty well now - they definitely add a lot to the look of the game.

I've also taking an initial shot at creating some background music.

Battling Bats in a Graveyard

The bats fly off the ground, so you have to jump and shoot to hit them.

I really need to add shadows - without them it is difficult to see the location of objects in the air.

Don't Mess with an Angry Mage

A little before/after comparison...

Doing Some Decorating

Now that my core engine is in pretty good shape for now (stuff draws, objects move, collide and explode), I'm starting to work on the "game" part of my next game. That means adding content.

These are a few screenshots of what I've got so far.



Not much, yet, but it's a start.

Throwing Rocks at Frogs

Exploding frogs - what's not to like about that?

Block Model Editor

I hate making editors. Creating an editor for a feature always takes ten times the amount of time that it took to add the actual feature itself. And it is much less rewarding code to write.

I need an intern...

Anyway, I've got a half-assed editor for the block models that I will be scattering throughout my block world. I used my mad 3D art skills to draw a tree. So there!

Block Models

I am currently working on adding more details to my Block World environment. This will be done mostly through the use of what I am calling "Block Models" - meshes generated from a 3D cubic grid of "trixels".

I started with 16x16x16 grid and did a test to see how many I could render. Quite a few, it turns out.

Another Block World Island

Here's a shot of another island in Block World.

Block World

Here is a little video to show the current state of my "Block World".

I've implemented a physics model and added some basic terrain editing. The next step will be to increase the diversity of the landscape - adding angled ramps (but still keeping things blocky) and some decorations (bushes, trees, etc.)