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.
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.
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)
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.
For March, I’m going to work on a project that is overdue and will benefit myself along with anyone interested enough to read this. I plan on redesigning this blog that you’re reading right now. Finally.
When I first did the design of this blog, I was doing mostly flash work and just relearned how to correctly build a website from scratch. And by that, I mean building a website without using tables to place page elements. I was also working my way through figuring out how wordpress works. I was happy when I was done, but I knew that there was a lot to fix and improve. I also didn’t know if I was going to be into this whole blogging thing so I didn’t even bother to fix anything. Fast-forward a few years and I’ve rededicated myself to blogging regularly and I have experience programming in so many more languages than actionscript and have done another site on the wordpress platform that I’m ready to correct my mistakes and set up a blogging environment that I can be proud of. I don’t do nearly as much design anymore though, so I hope to get some input from some of the excellent designers that I’ve met since the initial design to help elevate this whole thing.
The goal for this month is to just work on the design part of this overhaul. The development will come later and I’m sure will span more than 1 month.
What I plan on doing includes:
Making a list of what works and what I like
Making a list of what’s not working and what I really don’t like
Gathering inspiration to help in figuring out what I want this to be, now and in 2 years from now
Figuring out a way that this blog will fit in with the rest of my online presence. For instance, I have a portfolio site that desperately needs to be updated too. So how does that tie in with this blog?
Figuring out how to tie things in with any relevant social media outlets (showing twitter feed, tumblr posts, etc).
Designing the fuckin thing
Whenever I start projects like this, I get so pumped at the beginning, only to be pissed at myself months later for attempting it. But it’s always worth it in the end. So let’s get pissed!
The furthest I’ve been able to get with this project for the month was to create a decent tool for Craig to use. I put together a quick video demo below. It’s not super flashy and is still in an early phase, but it allows us to do a ton more much more quickly than prior to this month.
So the way that this works is that there are 2 modes as you’ll see in the upper right hand corner when you first run it. Record and Read mode.
When in the default “Record” mode, you’ll see a white dot, starting in the center of the screen. When you have the accelerometer/arduino plugged in, you should see the white dot move around based on the accelerometer data coming in. There is a file in the project folder called “calibration.txt” that saves the calibration values each time to recalibrate the arduino board. To do the calibration, press ‘c’. Keep the accelerometer as flat and horizontal as you can and it will average the values over the 10 seconds that it runs. Once done, it saves that data to the text file. If that text file isn’t found, the calibration runs right away.