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.
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 a recent motion graphics project that I was working on, I needed to use a sucking-in vacuum effect where some logos were being sucked into a TV. Not being a motion graphics expert and jumping into after effects for the first time in a while, I first went searching some forums to see if anyone else asked the question and had gotten answers. Indeed people have asked how to get this affect, but not too many useful answers were out there. Fortunately, I was able to put together something I was happy with and wanted to show anyone that’s interested how the effect was achieved.
Have you ever completed a flash project and started testing it online only to realize that the swf is looking for assets either in a different directory than the one you specified? Or that the folder that you have all your media stored is not in a relative directory like it was when working on it locally?
The solution that I mustered up in the past was to create a flashvar called something like “mediafolder” and put that in the embed code. From there, I would go back into my actionscript code and make sure all external media had the passed “mediafolder” variable appended to the beginning of the url for each external asset and then republish my swf.
This always worked well, so I usually plan for this, but my latest project didn’t have that built in. When it came to testing and we realized that the media folder was going to be in a different location than the base swf file and it was supposed to launch soon, it was time to see if there was another alternative to the usual solution. That’s when I discovered the “base” attribute in the swf object embed code.
The “base” attribute is actually an href attribute that specifies a base URL for all relative URLs on a page. Traditionally, you should be able to put it in the head of an html page and have all links on a page link relative to the string specified in the base attribute. For this it’s just specified for the swf, which picks it up when passed as a param and picks up any external asset from that folder by default instead of the folder that the actual swf is in.
With the example above, any asset that the main swf is trying to load relative to itself can now be placed in “../project/subfolder” without having to change any actionscript and republishing your swf. This is a tip that has saved me hours of work and would have saved me even more time had I discovered it in the past.