The canvas with the van is not very nice, but just to show you a demo of the spray can. sorry for my bad spraying skills. see a description of the project here.

example

Sprite: w=8191, h=2048

FP10 BitmapData: w=8191, h=2048 with snapshot of the Sprite

workaround

A workaround for that problem would be to draw everything directly to the BitmapData or if you have to snapshot a Sprite greater than 4096px you could draw it to 4096px BitmapData chunks and copy them to the huge BitmapData afterwards using copyPixels().

Update December 14th, 2008

I added a draw method to the BitmapDataUnlimited class to bypass the 4096px limit.

In order to receive tags, the RFID reader has to be activated through a click on the image. After that, the different RFID tags (sorry for my tiny tags) are used to create different forms.

The previous post was all about wiring the RFID reader ID-12 and an Arduino board. Now I want to show you how to use this setup within an ActionScript application.

As you don’t have the possibility to access the hardware respectively the usb/bluetooth serial port directly, you have to use a Socket server which redirects the network socket connections to or from the serial ports. Fortunately there are already ready-to-use solutions like serproxy or TinkerProxy (win, osx) available. Personally I prefer serproxy, but if you want to have a nice GUI I would recommend TinkerProxy.
These proxy servers are not made specifically for the use with Flash and therefore they don’t implement a cross-domain-policy file. As you probably know this is needed for not getting a security error in your flash application. As a workaround for that problem you can get lessrains policyserver and start it on port 5334 (java -jar policyserver.jar 5334). It will return an appropriate policy file when requested by the flash application.

With these things in mind we can go for some code now.

...
public function connect() : void
{
	if(_state != DISCONNECTED) return;
	_state = CONNECTING;
 
	addSocketEvents();
 
	// load policy file from localhost, port 5334
	Security.loadPolicyFile("xmlsocket://" + SOCKET_HOST + ":" + String(POLICY_PORT));
	// connect to proxy localhost, port 5333
	_socket.connect(SOCKET_HOST, PROXY_PORT);
}
 
public function disconnect() : void
{
	if(_state != CONNECTED) return;
	_state = DISCONNECTING;
 
	sendDisconnect();
	processDisconnect();
}
 
public function finalize() : void
{
	...
}
...

My RFID class implements basically 3 public methods + the EventDispatcher stuff.

...
private function connectSocket(event : Event) : void 
{   
	// send ping to arduino
	_pingTimer = new Timer(100, 0);
	_pingTimer.addEventListener(TimerEvent.TIMER, handleTimer);
	_pingTimer.start();
}
 
private function handleTimer(event : TimerEvent) : void
{
	sendPing();
}
...

The Socket class dispatches Event.CONNECT when the connection to the proxy server is established but that doesn’t mean that the hardware is connected as well. To really know when the arduino is listening I use a timer to send a ping to the Arduino board. When I get the ping back, I know that the Arduino is ready to use.

...
private function processRfidTag() : void
{
	_cachePosition = _cache.position - 1;
	var bytesIn : int = 0;
	var val : int;
	var rfidTag : String = "";
 
	while (_cache.bytesAvailable > 0 && bytesIn < 10) 
	{                        				
		val = _cache.readByte();
 
		// if ETX or STX before the 10 digit reading -> stop reading
		if((val == STX) || (val == ETX)) break;
 
		// Do Ascii/Hex conversion:
		if ((val >= 0x30) && (val < = 0x39)) 
			val -= 0x30;
		else if ((val >= 0x41) && (val < = 0x46))
			val = 10 + val - 0x41;
 
		rfidTag += val.toString(16).toUpperCase();
 
		// ready to read next digit
		bytesIn++;                                
	}
 
	// read complete
	if (bytesIn == 10) 
	{ 
		if(rfidTag != "0000000000" ) _tag = rfidTag;
		else _tag = null;
 
		_cachePosition = -1;
		dispatchEvent(new RFIDEvent(RFIDEvent.TAG_CHANGED));
	}
}
...

When I receive some data from the socket, I look for the STX byte which is the header or marker of the RFID tag and get the tag via processRfidTag(). Beyond that I don’t read the bytes directly from the socket but write all the incoming data in a cache first to not loose any information coming in in different ProgressEvent.SOCKET_DATA events.

Download the full source of my ID-12 demo and don't forget to replace my tag ids with yours otherwise your RFID tags won't draw any form.

VandalSpray features includes:

• exchangeable caps
• color display
• digital valve system to vary the amount of »paint« coming out of the cap
• different colors
• wireless

The spray can is built upon the Arduino platform and uses different sensors and electronic modules like a RFID reader, a super bright RGB LED, a Rotary Encoder, a Bluetooth module, a force sensitive resitor (FSR) and loads of wires and solder to implement the desired behavior. For tracking the spray can I use a Wiimote and the WiiFlash ActionScript 3 library and server, but this could also be replaced by a standard webcam and an adequate tracking implementation.
Because I didn’t want to put some kind of speaker in the spray can (there was no space left anyway) the spray sound is generated from the AIR app and output on the speakers of the notebook.

VandalSpray vs. Montana spray can

VandalSpray electronics

More
http://blog.formatlos.de/2008/12/12/digital-spraycan-edemo/
http://blog.formatlos.de/2008/12/19/digital-graffiti-spray-demo/

Error #2180: It is illegal to move AVM1 content (AS1 or AS2) to a different part of the displayList when it has been loaded into AVM2 (AS3) content.

There are a few options to avoid this error:

• Don’t load AVM1 content respectively create the assets in Flash to get AVM2 swfs
• Don’t move the assets in a different part of the displayList
• Change the SWF header on-the-fly

The last solution seemed to be perfect and remembering the AVM2Loader class someone created in the upcoming AS3 times it was the easiest solution without changing the workflow. Even if the author Fladdict removed the class, you can still find it on the internet at Troy Gardners blog.

Update 20.11.2008

To use this workaround in an AIR application you have to set allowLoadBytesCodeExecution = true in your LoaderContext otherwise you aren’t allowed to load the bytes of the swf.

...
var loader:Loader = new AVM2Loader();
var loaderContext:LoaderContext = new LoaderContext();
loaderContext.allowLoadBytesCodeExecution = true;
loader.load("file.swf", loaderContext);
...

This post is all about using the right SDK. With the release of AIR 1.5 some of you might switch and run into the same problems I did when I set up my first AIR project. Compiling for AIR is a little bit more strict and bound to the SDK than compiling for FlashPlayer. If you want to target for instance FlashPlayer 9 you could use Flex SDK 3.0, 3.2 or even a beta release of Gumbo (4.0), as long as you don’t use any of the classes or functions that are related with FlashPlayer 10 (e.g. the Vector class).
Compiling for AIR is a little bit different. The SDK is more or less bound to the version you want to target, so you have to use the right SDK in combination with the right definition in the application descriptor file.

<application xmlns="http://ns.adobe.com/air/application/1.1">
...
</application>

As you can see this descriptor is for AIR 1.1. If you try to compile with the SDK 3.2 which targets AIR 1.5 you will get a compile error (“error while loading initial content”).

Just keep that in mind and use the right SDK:

• AIR 1.0 – Flex SDK 3.0
• AIR 1.1 – Flex SDK 3.1
• AIR 1.5 – Flex SDK 3.2

You can find a list of milestone releases, stable and nigthly builds at the Adobe Open Source site.

Try the following in your document class and your cursor is gone, hopefully!

stage.nativeWindow.activate();
stage.nativeWindow.orderToBack();
stage.nativeWindow.orderToFront();
Mouse.hide();

Basically this sends the window behind all the other windows and brings it to the front again immediately. You won’t see the change or any flickering. After that you can hide your cursor.

Update 17.11.2008

Adobe just released AIR 1.5 but seems like this problem is still there. The workaround is still working so keep on rockin’ or should I say hiding

...
public function Main()
{
	stage.nativeWindow.addEventListener(NativeWindowBoundsEvent.RESIZE, resize);
	stage.nativeWindow.maximize();				
}
private function resize(event : NativeWindowBoundsEvent) : void
{
	// show window + set keyboard and mouse focus
	stage.nativeWindow.activate();
}
...

Apparently this works on OSX but not on Windows. There the window has to be visible in order to maximize it. I didn’t do many tests so prove me wrong if you have other experiences.