Learn to Use GIF Loop Coder

There’s a new video-based course on using GIF Loop Coder. Check it out at https://egghead.io/courses/gif-loop-coder-for-creating-animation

Ten video lessons, adding up to around an hour of instruction by yours truly, covering pretty much all aspects of GLC. It’s a free course, so head on over and check it out. Also, check out the other stuff at Egghead. If you do any kind of programming on the web, it’s a great resource for staying up to date on the latest technologies. Well worth the cost.

GLC with external tools

With the release of the image sequence export feature, I thought I’d play around a bit with making different animations with the frame outputs to see what quality and file size I could come up with.

I started with an existing animation and exported an animated gif from that. Then exported an image sequence from the same animation and used ImageMagick to create another animated gif, and ffmpeg to create an mp4 video. Here are the results.

First, the GLC gif output:

GLC Direct Output - 473kb

That comes in at 473kb and looks decent.

Then the ImageMagick version.

ImageMagick Output - 326kb

That’s 326kb. Looks about the same to me, but significantly smaller. Actually, my initial attempts were horrible. The IM version came in larger than GLC’s output and had all kinds of horrible artifacts. Some research found some command line options that cleaned it up and optimized it nicely. Here’s the command I used to create this image:

convert -delay 3.33 -loop 0 -fuzz 2% -layers Optimize *.png isogrid_im.gif

Note, delay is in terms of 100ths of a second, fuzz cleans up the quantization and -layers Optimize brought the file size way down.

Now that I look at it closer, there’s still a bit of artifacting going on. Raising the fuzz level a bit would probably handle that though.

Onto ffmpeg.

That’s down to a whopping 50kb. But it does look a bit fuzzy. I’m not even going to begin to explain the ffmpeg command line I used, because I hardly understand it myself.

ffmpeg.exe -framerate 30 -i isogrid_%0
4d.png -c:v libx264 -r 30 -pix_fmt yuv420p isogrid.mp4

Here’s the page I gleaned that info from: https://trac.ffmpeg.org/wiki/Create%20a%20video%20slideshow%20from%20images

There are probably options that would improve the quality at the expense of some file size. Another interesting concept is the idea of including audio in the mp4. or creating multiple animations and stitching them together in a longer movie. Of course, you could just pull all the files into some video editor and do the same thing that way.

I was going to try gifsicle as well, but that requires individual gifs as input. Won’t take pngs.

Anyway, there’s some things to try. I’d love to hear any additional tools or techniques you come up with.

I had to turn off comments here. 10,000 to 1 spam to comment ratio. But tweet with the tag #gifloopcoder and I’ll see it.

Version 1.3.3 Image Sequence Export

Initially, this post was about version 1.3.2. Turns out this had a nasty bug where image export would never end. Once you exported images for an animation, every time you ran an animation after that, it would continue to pump out frame images. All fixed now.

Hot on the heels of 1.3.1 comes This adds a feature I’ve had on the list for a while – the ability to export an animation as a sequence of individual images. It also fixes the OSX version by adding in an edit menu, restoring copy, cut, paste, select all, undo, etc.


Image sequence export is somewhat similar to the sprite sheet export, but in this case, every single frame is saved out as a separate image file. You’ll get a file save dialog allowing you to choose a file name. The actual files will have sequential numbers appended to them. For example, if you had a 2-second animation at 30 frames per second and chose myanim.png as the file to save to, you’d wind up with 30 files named myanim_0000.png through myanim_0029.png. It’s best to choose an empty folder to save these in, as for longer animations, you could wind up with hundreds of images.

I was surprised how well this works and just how quick it is. I maxed out the duration and fps sliders to create an 1800 frame animation and it handled it all without a hiccup.

Having image sequence export opens up a whole realm of possibilities:

First, the GIF encoder included in GLC is not the best. Hey, it’s written in JavaScript. I didn’t write it, so I won’t complain. And it does the job. But there are better tools out there that will probably do a better job at compression and color quantization. For example, you can use ImageMagick on the command line within your export folder something like this:

convert -delay 3.33 -loop 0 *.png anim.gif

Note that ImageMagick’s delay is in terms of hundredths of a second. And it has all kinds of other options to tweak the output. You could even combine the output of multiple animations together to have a longer gif.

Gifsicle is another command line tool that allows you to create gifs from image sequences. Photoshop will also do this.

This also opens the door to formats beyond gif. There are plenty of other programs that will create video files from image sequences.

Version 1.3.1 – template, snippets, console

Version 1.3.1 is up at https://github.com/bit101/gifloopcoder/releases/tag/1.3.1. Main new items:

1. The template used to create a new sketch is now editable. Look in the config folder for template.js and edit that. On Win and Linux that’s:


On OS X it’s:


You’ll have to right-click and choose “Show Contents” on the .app file if you’re going in through the Finder.

2. Editable snippets. Snippet files are in the config/snippets folder. Same steps as in #1. The file name, minus “.snippet” is what shows up in the dropdown. The contents are the snippet itself. Object snippets are all hard coded, but you can add any custom ones you want here. If you come up with some good ones, share them and I might include them. Any ideas on a good way to share them? A separate git repo?

3. Console button. The toolbar has a console button that opens up the dev tools console on the embedded Chrome browser. Useful for debugging your sketch.

A few bug fixes and minor improvements, but those are the big items. I’ll very shortly be releasing 1.3.2 which will include exporting an image sequence. Basically, you choose a folder and file name, such as “animatons/foo.png” and it exports each frame of the animation as a separate numbered image: “animatons/foo_0000.png”, “animations/foo_0001.png”, “animations/foo_0002.png”, etc. It’s all working fine, just need to do some more cross-platform testing.

Version 1.3.0 – Standalone Executables

This post is a bit late, as this was done at the beginning of the week, but anyway, GLC is now delivered as a standalone executable program for Windows, Linux, and OSX. This means that it is a regular program, not a page that runs in your browser.

Technically it is still a page that run in a browser, but it’s packaged up with Electron. This is a packager that creates native programs from web apps. If you’ve ever used The Atom code editor, it is made with Electron (and by the same people). Other apps made with Electron include Slack, Visual Studio Code and Pixate.

In addition to just wrapping the browser and app, it gives you access to native functionality, such as the file system, menus, external processes, etc. So now GLC can load and save code files as well as animations and screenshots just like a real program.

It also runs the app with an external nodejs server, so you get a lot of security issues that you have in a browser. The biggest impact this has is that we can now have an image object in GLC. This was impossible before because once you have drawn an external image to a canvas, you cannot access that canvas’s image data to create the gif. Not a problem in the standalone version. Check out the docs for the new image object. It’s fun.

There’s no need to install the program. Just download the version from your platform at https://github.com/bit101/gifloopcoder/releases and unzip it (or untar it for Linux). For Windows and Linux, you’ll get a folder with a bunch of crud in it, but there will be one file named “GIFLoopCoder.exe” (Windows) or just “GIFLoopCoder” (Linux). On OSX, all you’ll see is the “GIFLoopCoder.app” file and maybe a couple license files. Just run that file and you’re good to go.

If you still want to run the web version, you’ll have to check out the full source and use the “app” folder in there. Currently you’ll need to do that if you want to use an external editor. But I have some improvements coming up that will fix all that too.

The current builds also don’t include the docs and the examples, but you should have those kicking around from a previous install, or just use the online docs and get the examples from github.

Again, more things coming on this soon, but wanted to get this post out of the way now.

Version 1.2.0 – Snippets


This feature just kind of fell into my lap. I was looking at the CodeMirror API and realized that the replaceSelection function could be used to programatically insert code into the editor. I’d been using Phrase Express (a text expander type program) on Windows to automate my own snippets, but saw how easily this could be built in to the program. So now there are snippets.


On the far right you’ll see two dropdowns and buttons. The first has every possible object you can create in GLC. The second has a few useful snippets I’ve come up with.

Move your cursor to somewhere in the code, select a snippet, click the appropriate insert button, and there you go.

For the object snippets, I didn’t include every possible property, but tried to include the ones I thought would be most needed, with some obvious values. Let me know if there’s anything you think should be changed there.

For the other snippets, I included a few that I’ve found useful myself. I’d like to add to this list. Feel free to send me any you think would be useful. Eventually, I’d like to get to the point where you can define your own snippets, at least in some kind of external file.

Version 1.1.0 – New UI

Well, that was an ambitious update. I ripped the whole Quicksettings library out of the project and rewrote the entire UI and all connecting code from scratch.


Important to note is that all of the core code – the renderer, scheduler, encoder, etc. all stayed 99% intact. Some minor interface changes to get it to work with the new UI arrangement, but no deep changes.

I’m not a big frameworks guy, so it’s all straight JavaScript, require.js modules that mostly act as controllers. Separate view modules for the UI pieces, all wired together with a master controller. All the UI is created with JavaScript. Not even templates, because… because. Because I wanted to do it that way. Not saying that’s how it should be done, or that you should do it that way, or that it’s best, or even that I’d do it that way again. It’s all about the journey. It was fun.

Anyway, that’s for the one or two of you who actually even look at the source code. For everyone else, I hope that it’s a cleaner, nicer UI to use. Personally, I love the way it looks and runs now. I love the integrated editor WAY more than I ever imagined I would. It’s all about instant feedback. Type some code, Control-Enter, see the result. Just like… well… you know where I’m going with this… Flash 3.

Speaking of instant feedback, I know some of you noticed that if you added a lot of objects to the list, there would be a LONG lag before the animation started. Sometimes, the browser could even time out on it. This bugged me too. I tried to think of what could be causing it. Could object creation really be taking such a toll on the CPU??? It seemed very odd to me. Failing at finding any solution by staring at the ceiling imagining what MIGHT be doing it, I finally broke down and LOOKED at the code.

What was going on was that every time a new object was added to the list, GLC was rendering the canvas. That was on purpose, so that if you didn’t have glc.loop() in your script, it would still render when the script was loaded. But hundreds of renders was NOT on purpose. I threw in a little setTimeout delay in there, so there was only a single render after ALL the objects were added. Now you can add tons of objects and it renders nearly instantly. Yay!

I was sad to see Quicksetting go, but overall, I’m super happy with Quicksettings. It totally, 100% did its job of allowing me to quickly prototype the app, creating the logic and getting everything working and not having to worry about layout and view code. Basically, I was happy with all of the logic and functionality of GLC. This update is almost totally confined to swapping out the UI. It was nice to be able to do it like that.

The last piece I had to remove was the output panel. I toyed with the idea of opening a new browser window. Not good. Or creating some new kind of internal popup similar to a Quicksettings panel. In the end, I went for a lighttable-like overlay. I think it looks pretty good.


As with the previous update, the new GLC plays very nice with external editors. There’s a config option in the HTML that shuts off the integrated editor and hides the tool bar buttons related to it. And a spot to link to your externally-edited content. Here’s the UI with no editor:


This was an important update for GLC. The next phase will be creating a standalone, cross-platform executable app using http://electron.atom.io/. I’ve already gotten most of this working. It really needed the improved UI though. Now that that’s there, I can move on to working on better OS hooks, such as real file system integration like you’d expect in a real app, but is impossible via the browser. Stuff like load, save, save as, recent file list, saving images and animations without right clicking, hopefully. Also, hopefully I’ll be able to get an image object in there – where you can load an image, position it, size it, rotate it, animate it, etc. I actually have this fully working, but due to security issues, the browser will not allow the canvas to be rendered to a gif once an image is drawn to it. I’m hopeful that running the app through electron will get rid of that problem.

Version 1.0.3: Isobox

Late last night I released Version 1.0.3 of GIF Loop Coder. The only major change is the addition of a new shape: the Isobox. This is simply an isometric box. OK, technically, it’s a dimetric box.

You can give it a screen x and y, a size and an ‘h’ for height. The size property is the width from one corner of the box to the other. The h is how far up the box extends from its base. So an h of greater than 0 will create a box of some kind, an h of 0 will create a tile, and a negative h will actually create a hole!


The colors are specified by the properties colorTop, colorLeft and colorRight. A great way to assign colors to these is with the color.hsv method. Use the same hue and saturation for all three, with varying values. Generally, the lightest value will be on the top and two darker values on the left and right, although you can change this up to create different lighting effects.

colorTop: color.hsv(90, 1, 1),
colorRight: color.hsv(90, 1, 0.75),
colorLeft: color.hsv(90, 1, 0.5),


Of course, all properties are animatable. Here, I’m animating the h and colors.


This is a great case for the color.animHSV method.

colorTop: color.animHSV(0, 60, 1, 1, 1, 1),
colorRight: color.animHSV(0, 60, 1, 1, 0.75, 0.75),
colorLeft: color.animHSV(0, 60, 1, 1, 0.5, 0.5),

The following code is extracted and simplified from the isometricgrid.js file in the examples folder, and shows how to make a grid of boxes.

    var tileWidth = 60,
        tileHeight = tileWidth / 2;
    for(var y = 0; y < 5; y++) {
        for(var x = 0; x < 5; x++) {
            var xpos = width / 2 + (x - y) * tileWidth / 2,
                ypos = 100 + (x + y) * tileHeight / 2,
                hue = 30 + Math.random() * 30;
                x: xpos,
                y: ypos,
                size: tileWidth,
                h: 40,
                colorTop: color.hsv(hue, 1, 1),        
                colorLeft: color.hsv(hue, 1, 0.5),
                colorRight: color.hsv(hue, 1, 0.75),


Version 1.0.2

What? Two releases in one day?

The last one had some improvements for the external editor crowd. Hopefully that made things easier. This release is for those who use the internal integrated editor.

Personally, I really enjoy using the new editor. But there were a few hiccups with it. One is that sometimes if you add way too many objects, or you maybe create a for loop that never exits, the whole app can freeze up. And the only way to get out is to refresh the page. And if you didn’t save your code, it’s gone.

So, to handle that, your file is constantly saved. When you restart, for whatever reason, it will be right back where you left it, even if the entire browser crashed. Now you can code away in confidence, and you only need to save out the code to an actual file when you’re really all done and want to archive it.

This change, however, necessitates one more – a way to get back to an empty template. So now there’s a “new” button on the tool bar. This will wipe out whatever’s in the editor and replace with the template. It’ll warn you first, though, to give you a chance to save your work if you need to.

So, internal or external editor user, both have improved workflows today.