I recently got my digital hands on a review copy of Packt Publishing’s new book Cinder – Begin Creative Coding by Krisjanis Rijnieks, the first of what will hopefully be many books centered around Cinder.

The book begins with a brief description of what creative coding is and eases into how Cinder fits into the equation. Before jumping into any actual code examples, the author does his due diligence and walks through how to get Cinder downloaded and set up on both OSX and Windows, showing how easy it is with the release version of Cinder. To get your first glimpse into seeing Cinder in action, the book guides you through some of the included samples. It’s an exercise that every first time Cinder user should go through anyway and continues to be a good resource when playing with a feature for the first time.

This is the first tutorial in a series designed to help Flash developers transfer their skills to the C++ creative coding framework Cinder. I’ll provide links to sample code at the end of the post. There’s a lot to learn, so lets get started.

Timing events to happen in a repeating loop is a common technique used in games and applications. It’s commonly used in games when for instance, you want a missile to attack you’re hero every 2 seconds or in an application when you want to remind the user where to click if they haven’t touched anything in a few minutes. I recently used a timed event loop for an installation that required an image transition every 30 seconds.

I’m about to start putting together a series of short tutorials dedicated to helping Flash devs get up to speed with using Cinder. Since there seems to be a wave of Flash developers making this move, I wanted to share some useful bits of code that are a result of research that I’ve done myself and put together into something that someone else might find useful. Cinder can be an intimidating environment to get going with, especially if you’ve never touched C++ at all before (as was my experience). My hope is to try and take some of the intimidation out of the process and maybe even save some of you some time so that you can go ahead and start using those flash skills to make some cool shit in Cinder too.

If anyone has requests for things you’d like to know how to do with Cinder, let me know. I hope to put one of these out every couple of weeks. The first one should be out shortly.

I’d like to share a nifty little project that we just completed for our first roofies party of the summer here at TBG. We’re calling it InstaScope. InstaScope is an installation that was made to entice partygoers to take photos with instagram so that they can feed the live kaleidoscope that was being projected right there at the party. All they had to do was tag their photo with “#TBGRoofies”.

I created and released my first cinder block and wanted to put it out there to see if it’s useful to anyone else.
https://github.com/gregkepler/CinderPathFitter

What it does is simplifies and returns a smoothed out, simplified Path2d object based on a vector of Vec2fs that you pass to it. It uses the same algorithm that paperjs uses, but c++-ified. It’s a slightly modified version of An Algorithm for Automatically Fitting Digitized Curves from “Graphic Gems.”

There are 2 samples in there.

• PathSimplification: Drag to draw a line on the screen. Once the line is finished, it analyzes and smooths out the line, letting you know how many lines you saved. It’s based on this paperjs example.
• ContinuousPath: Analyzes and smooths a path as you draw it. Could be good for making a drawing application.

As the year rolls along and I continue learning and exploring new things, I’ve come to realize that my initial challenge of creating a complete project each month isn’t working. It’s not for a lack of wanting to do it or lack of time really, but more in that it’s not conducive to allowing me to explore everything that I want to explore. There could be projects that only take a week to put together, while others may take months. Trying to fit it into a 1 month limit doesn’t make sense for me anymore. Especially when a large chunk of my time may be spent learning the next thing, such as the last 6 weeks or so devoted to just learning C++. No projects are coming out in the that time on top of learning a new language.

For this month’s project, I set out to redesign this blog a bit. Well not a total redesign, but more of a facelift. I wasn’t able to get to everything that I wanted to update, but I came up with an overall updated design for the blog posts, side bar, and footer. I’ll have to revisit the design again when it comes to some of the other pages, such as my about and contact pages. I’ve also decided that I’ll move my work from my old flash site into something a bit more relevant and updated in the work section here.

Next will be finding time to actually implement the update. It might not come until May. It would be nice to have something a little less embarrassing to look at by the time the Eyeo festival rolls around. But for now, baby steps. This will end up being my side project to my side project, which I’ll talk about in the next post.

I’m so sick of looking at this current design. Maybe it’ll come sooner.

Related Post:
March 2012 Project – A Redesign

This post is really for myself so that I have somewhere that I can look this up again. Maybe it’ll be helpful to someone else in to the future too.

When working in flash (which I find myself doing less and less now a days), one of my favorite ways to work with assets is through the use of swc files. That’s what they’re there for anyways right? Well what’s not so obvious is how to use swc files to load assets at runtime without using the import command. There are times that it’s useful to refer to an asset at runtime by name that you may or may not use, so you don’t want to explicitly go through the hassle of writing the lines to embed it. This often happens with sounds or items that are easier to loop through to use, such as when using a map of the US. It’s much easier to write a loop vs writing 51 embed statements (yes, I know that there are a million different ways of doing this without writing all of that).

When you do something like going through a loop and saying getDefinitionByName(“state_”+i) to grab a library item that resides in the swc asset file, there are no compiletime errors because Flash Builder can find that swc in the library. But once it runs, the debugger will yell at you. To fix this, you need to embed the swc file at compile time. In Flash Builder, this is done in the Actionscript Compiler settings and all you have to do is add this line (replacing it with the path to your asset swc file obviously)

-include-libraries /assets/assets.swc

Now when you run your swf, it’ll work like a charm and you’ll have those assets available without having to import them in the head of your class file. That being said, be sure to only do this when it makes sense. This embeds the swc file into your swf. So if there are assets in the library that are outdated and set to export at compile time, they’ll be included adding extra senseless bloat. As I write this, I’m using this method for a prototype where bloat doesn’t really matter, but just be mindful of that.