Tips & Tricks – unFocus Projects – Kevin Newman and Ken Newman

Multiple LocalHost Sites

Kenneth Newman — Tue, 24 Jul 2012 14:50:12 +0000

I’ve got XAMPP installed on a Windows 7 machine. I wanted a way to test multiple sites locally.

Set up the local host file

In your host file, add (replace with the domains you want):

[code]127.0.0.1   sub.domain.com.dev
127.0.0.1   www.example.com.dev
127.0.0.1   www.unfocus.com.dev[/code]

UPDATE: Thanks to xip.io the host file edits are optional if you use the style www.example.com.127.0.0.1.xip.io (replace 127.0.0.1 with your actual IP address). This is compatible with Adobe’s Edge Inspect.

Set up XAMPP config files

In \xampp\apache\conf\httpd.conf uncomment the following at about line 140:

[code]LoadModule vhost_alias_module modules/mod_vhost_alias.so[/code]

I’ve used the folder structure of “\xampp\htdocs\www.example.com\web\content\files.php” (for example) and the following config will find the folder with the exact name in the url.

In \xampp\apache\conf\extra\httpd-vhosts.conf:

[hoops name="config"]

Fix DOCUMENT_ROOT

If you are having issues with DOCUMENT_ROOT, create setdocroot.php at “\xampp\” and put the following in it:

[hoops name="fix"]

References:
https://issues.apache.org/bugzilla/show_bug.cgi?id=26052#c27
http://stackoverflow.com/questions/138162/wildcards-in-a-hosts-file
http://postpostmodern.com/instructional/a-smarter-mamp/

SignalsLite.js, Unit Testing, and Buggy IE

Kevin Newman — Tue, 12 Jun 2012 23:12:54 +0000

I decided to finally learn unit testing, so I downloaded QUnit (after looking at the 20,000 different unit testing options), and figured I’d give porting tiny SignalsLite to JavaScript a try, and see how the process goes.

While doing that, I found a crazy IE7/IE8 JS bug, that I’m sure has had me scratching my head in the past. Here is a quick unit test to show the problem:

[sourcecode language=”javascript”]
test( "Basic Requirements", function testReqs() {
expect(1);
var T;
(function makeT() {
T=function T(){}
T.prototype.test = 1;
})();
ok((new T).test, "Instance of exported T should have prototype methods");
});
[/sourcecode]

If you run that IE7 or IE8 it’ll fail!

The cool thing is, without having created unit tests for SignalsLite.js, I would never have known that could be an issue, and instead would continue to scratch my head when stuff like that broke in IE7/8. I found this because I was trying to export SignalLite from within a closure (I try to always define my stuff inside of closures to avoid namespace pollution), with this:

[sourcecode language=”javascript”]
(function() { "use strict"; // standard header

// naming inline functions makes the debug console easier to read.
window.SignalLite = function SignalLite() {
// stuff
}
SignalLite.prototype = {
// methods
};

// The fix is to use an anonymous function, or export elsewhere:
// window.SignalLite = SignalLite;

})();
[/sourcecode]

For whatever reason, that doesn’t work in IE7 and IE8. Unit testing is crazy!

If you are interested, go fork SignalsLite.json GitHib.

P.S. You can run the SignalsLite.js unit tests here ~~to see the fail for yourself~~! I disabled that test in the SignalsLite.js tests.

Performance Benchmarks with AIR 2.7 for iOS

Kevin Newman — Sun, 03 Jul 2011 06:14:19 +0000

I’ve been working on this Benchmark based on Iain Lobb’s BunnyMark. Being a bit confused sometimes about what things speed things up or slow things down, I didn’t want to guess anymore, so I grabbed Iain’s code base (cause I’m lazy, and didn’t want to start from scratch), and added some tests for things I suspect are slowing things down (or speeding things up). I think this will also help shed some light on why some folks see a huge gain in AIR 2.7 CPU mode, while others do not.

Some caveats – this only tests instances of flash.display.Bitmap on the display list, at the size they are, moving the way they move. It’s on my list to add Blitting (I have some initial work on that done, thanks to Iain, but I need to add the rotation, and alpha settings to it), and I’d like to add a vector test, and maybe some extra sized Bitmaps (I’ve heard that makes a difference).

Enough! Here are some results – quality had no effect on GPU mode, so I included only one line:

Note: some are reporting they see a difference in GPU mode, but I still don’t. Update: It appears some users are confusing “Mobile Performance Tester” with BunnyMark, which explains the discrepancy. BunnyMark is not currently in any App Store, which is one key distinguishing feature.

BunnyMark Results – 500 Bunnies
Alpha							✓	✓	✓
Rotation				✓	✓	✓			✓
CaB		✓	✓		✓	✓		✓
CaBM			✓			✓
iPhone 3GS – GPU
FPS	24	18	17	22	13	13	19	1	19
iPhone 3GS – CPU
FPS-L	28	21	19	9	19	5	7	5	5
FPS-M	28	21	19	4	18	3	7	5	3
FPS-H	28	21	19	3	18	2	7	5	2
FPS-B	28	21	19	3	18	2	7	5	2
iPhone 4 (Retina) – GPU
FPS	25	21	20	25	13	13	16	0.5	16
iPhone 4 (Retina) – CPU
FPS-L	32	23	20	10	21	6	8	6	7
FPS-M	32	23	20	5	20	3	8	6	3
FPS-H	32	23	19	4	20	2	8	6	2
FPS-B	32	23	19	4	20	2	8	6	2

Notes about the Benchmark:

In general, the CPU mode seems pretty consistent with the way you’d expect things to work on the desktop – the same optimizations you’d apply for the browser plugin, you’d also apply to mobile for CPU mode.
Rotation in this benchmark is not continuous – the Bunny graphics are only rotated at the edge of the stage, which is why cacheAsBitmap works to speed those up. If they were constantly updated, it would likely be much more expensive on CPU mode (probably more like rotation without CaB).
Alpha is continuous – the alpha value of each Bunny is based on the y position and is updated every frame. I would like to add a mode similar to the rotation, so see what effect CaB has on alpha transparent objects that don’t constantly change.
iPhone 4 and 3GS numbers aren’t directly comparable for practical purposes. The Bitmaps on the screen on 3GS take up much more real estate, since the 3GS screen res has 1/4 as many pixels as the iPhone 4. In a normal app, we’d probably resize things to look comparable between the two devices. I’ll try to add a mode that makes this more comparable (because I suspect we’ll find that 3GS can keep up with iPhone 4 with similar looking content).
Touching the screen seems to cost about 4 fps across the board.
I think there may be an issue with returning to rotation = 0 costing some performance in GPU mode. Still have to test that.
I’m definitely getting some variance on default speeds – basically, before any settings are messed with on some runs I get the faster numbers (the baseline numbers in the tables above). Other times it runs at default settings a couple of FPS slower (on start, or after resetting the switches). With any of the settings, everything is consistent across multiple runs.

It’d be nice to have more benchmarks for more devices, but I only have the above devices available. This should run just fine on Android, Blackberry Playbook, and iPads. If anyone wants to contribute a set of benchmarks, hit the comments. Here is the source. One of these days I’ll make another post, and try to draw some conclusions, maybe wrap the bullet points into a narrative, and edit some of this, but the tables are there, and the source code, and that’s the important stuff.

In the midst of playing with this benchmark, I found (or was pointed at) some great resources. Here are some of them:

Understanding GPU Rendering in Adobe AIR for Mobile – Ton of good info here.
Mobile Performance Tester — Now Live in App Stores – This is very similar to what I’ve done, and has some of the same kinds of tests. It shows some different results though, which I’m a bit confused about. I suspect it has something to do with using larger images, which have more alpha transparency (smoother edges). I intend to look at it more closely to see what’s up in there.
Original BunnyMark by Iain Lobb
Source for BunnyMark for AIR Mobile

Here is the Benchmark to see it in action:

A Simple State Manager for History Keeper

Kevin Newman — Thu, 26 Aug 2010 16:33:58 +0000

Someone asked how to store a key value pair in HistoryKeeper recently, and this was my answer.

History Keeper does not provide any state management features beyond the information you store on the actual deep link (URL hash). However, you should be able to use the deep link information to grab the data you need out of a standard JS object (using it like a hash table):

[cc lang=”javascript”]
var storage = {
“/”: {
key: “home value”
},
“/about”: {
key: “about value”
}
};
[/cc]

Once you have your values stored like that you can use the storage object to lookup your chunk of data by the deep link string:

[cc lang=”javascript”]
function onHistoryChange(hash) {
alert(storage[hash].key);
}
unFocus.History.addEventListener(‘historyChange’, onHistoryChange);
[/cc]

You can make the “value” as deep as you want ( key: {more: “complex”} ), I only used a simple string for demonstration purposes.

This example is JavaScript, but the concepts are the same for Actionscript as well.

I hope that helps!

The Pixels Explode. Explode!

Kevin Newman — Thu, 24 Jun 2010 04:22:25 +0000

Update: I posted a follow up an exploding video!

Well I guess technically the pixels don’t explode as much as the DisplayObject explodes into pixels! I recently needed an effect that would make a bitmap image look sparkley, so I did some goggling, and game across a Firefly particle effect on a blog post belonging to Erik Hallander (at least I think so, the blog has been down for months, so I can’t double check). This pretty impressive effect looks like the following example (I hope reposting it here is not a problem).

Note: This is a modified version of the original adding the Stats.as box, and autolooping – and removes the actual firefly affect (I didn’t need that part for my purposes).

Very nice start! I don’t get an FPS problem – on my computer the example above rocks 62/60 fps (25% CPU on my Core 2 Duo)! So FPS was not the big problem. This example uses over ~19-23MB of RAM (with a lot of fluctuation)! And that is with 2×2 pixels, it goes up higher with 1×1 pixels. Additionally, this example already has an optimization in it to skip over empty (black) pixels in the DisplayObject it works on – which leads to a significant RAM savings.

Using the display list this way – and two filters per DisplayObject – it began causing the player to kick up a lot of invalid BitmapData/null reference errors (which I’m guessing is what happens when you run out of memory, since many many checks confirmed that the BitmapData was not invalid) – especially when I tried to make it work on 1×1 pixels to animate every pixel.

So the first thing I did was to clean up some of the obvious stuff, to bring down the memory usage – in the original blog post, Erik noted that this was unoptimized code, so I knew what I was getting into. I did things like remove the extra nested DisplayObjects (each pixel was a subclasses Sprite instance, with a BitmapData added to it), and cleaned up extra variables that were laying around, moved a lot of things inline, reused as many variables as I could, cutting down on object instantiation – and followed a lot of the other tips in a conveniently timed ByteArray post. Doing that really helped – I cut the memory use about in half – and on the initial animation (a black and white logo) the affect seemed worked quite well. But it didn’t scale well – larger images simply wouldn’t work.

I still wanted to use this affect, and I’ve seen many thousands of pixels being animated before – so I knew it was possible. So a radical departure. I’ve been reading about drawing directly to Bitmaps for quite a while, and that was going to be my path. So more optimizations – removed the display list code completely, changed the Pixel class to a simply property class (where are the enums?!), and used that to store information about where in the original source to look for the pixel data as well as other relevant animation data (most of which was already done for me – thanks!) for each pixel block. I also removed dependence on TweenMax – which is what the original uses for all the animations – and used the easing equations directly, within an ENTER_FRAME event.

The result is a RAM reduction by 25% and a steadier memory usage, coming in at ~5MB with 4x as many pixels (and roughly the same amount of CPU). The changes utilize copyPixels and a linked list, with an accumulation buffer like effect – for a total of 3 bitmaps (the original, which is rendered from the DisplayObject and stored, the scattered one the pixels get copied into, and the copy of that that gets blurred by the BlurFilter – a hidden memory cost illuminated by Thibault Imbert).

There are further optimizations that can be used as well (and should really be used for full image per pixel animations) – such as writing to an opaque BitmapData, rather than one with Alpha, and reducing the BlurFilter quality – getting a better handle on type marshaling, etc. It might also be faster to store the RGB value of each pixel, and draw those directly instead of using copyPixels, but I haven’t tried that yet.

I got so much help from the Flash community on this, that it would be irresponsible not to share this back, so feel free to check out the source.

Some Notes:

The memory usage applies to both swfs on this page – so you can’t see the memory usage difference in these examples. I quoted the standalone Flash Player in this post.

Also, I’m getting some kind of performance problem in plugin browsers (everything except IE) on Windows, and on every browser on mac but Firefox which is limiting both of these to around 30FPS. I have no idea what’s causing it.

On the code quality – the code isn’t all that messy IMHO, but it is not well documented, and a lot of the configuration hooks I left in are not really being utilized in a decent API – I may refactor at some point to clean that up. There is also a limitation of the skip pixel check that will keep it from working well for greater than 1×1 pixel size (since it only checks the top left corner of the size rect).

Enjoy!

3D Gaming is Awesome!

Kevin Newman — Thu, 07 Jan 2010 18:53:10 +0000

After I watched Avatar in 3D, I became curious about PC gaming in 3D. So I did some research on the subject. There are three kinds of home 3D solutions on the market today (and a few more in theaters); active shutter glasses, and polarized LCD monitors are the two full color technologies. Each have their advantages and drawbacks, which I may blog about in more detail in the future (if you want more info, I suggest reading the xbit labs reviews of the various technologies).

I wanted to try to find a solution that did not require the layout of hundreds of dollars just to test out how well (or not) the 3D of these systems actually worked, so I wondered if there was a way to test these out, with minimal cost – sure enough, both available 3D graphics drivers support anaglyph mode to preview the tech. The third option anaglyph – you may remember this trick from super bowl half time commercials, and cereal box addins. First up is nVidia’s solution is slightly

For nVidia 3D Vision Discover, you’ll need to make sure you have a beefy enough nVidia video card – ATi users are out of luck. As luck would have it, I have a supported card, an 8800GT (the lowest end card supported!). To turn it on, follow the instructions on nVidia’s 3D Vision Setup page. Make sure you have both the correct version of display drivers, and the 3D Vision drivers.

If you don’t have the correct glasses colors (as I didn’t – I used magenta/green glasses backwards from Monster’s Vs. Aliens DVD – eventually I replaced one lense with a red one from a children’s spy kit I got from Friendly’s) it may be a little tricky to enable the affect in nVidida’s drivers if you don’t have the correct colored glasses, since they don’t actually let you turn it on without testing you first. Just guess at what the answers are and press back if you get it wrong – there are not that many combinations of answers, and you’ll eventually get it right. Once you do that, you’ll have an option to turn this all on in the Stereoscopic 3D section of your NVIDIA Control Panel (right click desktop to get there), or use the CTRL + T shortcut to turn it on.

The nVidia drivers work amazingly well on Valve Source engine based games – like Left 4 Dead and Team Fortress 2. In some parts of Left 4 Dead 2, such as the sugar cane fields on the return trip level of Heavy Rain, it may even give you a bit of an advantage, since you can see the depth of the plants – it’s much easier to see where you are going. They did less well in older UT3 engine based games, like Bioshock, where you can see noticeable gaps around some objects where the fog effects just don’t line up correctly in both eyes (it’s shifted to the right or left, for each eye respectively), and certain shadows are lost. Newer UT3 games, like Batman .. Arkham Asylum, which claims out of the box support for nVidia 3D Vision, and Avatar, which has 3D support that must be enabled in game, look phenomenal. (For Avatar you need to set nVidia stereoscopic view on in the driver first and then the game to get it to work). Other Ubisoft games like Assassin’s Creed and Prince of Persia also look great.

Another option is to use the iZ3D 3D drivers – which work with any 3D card, including ATi Radeon. iZ3D sells a line of specialized monitors that actually polarize two images (similar to how many 3D movie screens work), and use passive glasses to filter out each image from the correct eye, thus presenting two different images to each eye. You don’t need a 3D monitor to use the drivers though, as they have a free anaglyph mode built in (among other modes). These drivers seem to incur a greater performance hit than the nVidia glasses – but despite many posts (seemingly little more than assumptions) I’ve found on forums and blog posts, I actually found them more compatible than nVidia’s drivers, especially in Bioshock, which is downright amazing in 3D (despite missing many shadows). These drivers don’t start out with the modest 3D settings as the nVidia’s more out of the box settings, but once you tweak these (there are more options for tweaking, and each game starts out with a tweaking guide overlay to help you out), you should be up and running.

The best part of the iZ3D drivers is that you can actually change the color settings of the anaglyph mode (apparently you used to be able to do that for nVidia, but they removed that ability). This is fantastic, because it means you can get all the colors, with less ghosting that you’d miss if you don’t use the correct glasses with the nVidia drivers. Most anaglyphs actually separate 3 colors, not just two – one channel (red) to one eye and the other two channels (green + blue = cyan) to the other. In my case, I am using green and magenta (blue + red). The fact that blue is being split to the wrong eye is why you get ghosting with the nvidia drivers and the Monsters Vs. Aliens (or Coraline) glasses.

Here’s a quick guide to change the anaglyph colors for iZ3D drivers. First find the correct config file – for me (Windows 7) it was:

C:UsersAll UsersiZ3D Driver

I can’t confirm these two, but they helped me find the location in Windows 7 – from the iZ3D forums:

XP: “Documents and SettingsAll UsersApplication DataiZ3D DriverLanguage”

Vista: “ProgramDataiZ3D DriverLanguage”

Once you have opened the Config.xml file in one of those folders, you can edit the following items to make it green/magenta:

[cc lang=’xml’]

[/cc]

In case you are interested, here is a quick key for what these values actually mean – or at least 3 of them – it’s matrix math which is hard ;-):

m00=”R” m01=”0″ m02=”0″
m10=”0″ m11=”G” m12=”0″
m20=”0″ m21=”0″ m22=”B“

There are bugs and drawbacks with each solution – most games were not made with 3D in mind, so this can be a bit of a hack. Some games are missing shadows or have misaligned affects (like Bioshock), and I couldn’t get OpenGL games to work at all with either driver (despite settings for it in iZ3D). Other games seem to perform flawlessly (like Left 4 Dead, Batman or Avatar). Another big drawback of these systems is the cost – full color 3D setups can be pretty expensive $300-$400 for the monitor, and another $200 for the glasses (and an additional $150 for each pair you want to add for group movie watching). The iZ3D solution (and Zalman makes a compatible monitor) are getting cheaper, but are still quite pricey at around $300 for the monitor and cheaper passive glasses (with no other special requirements/costs, except some kind of reasonably strong video card).

The affect is pretty convincing for me though, and since I already have a nice 120Hz monitor, and a decent enough graphics card, I’ll be adding nVidia Shutter glasses to my birthday list.

Stop All Child MovieClips in Flash with Actionscript 3.0

Kevin Newman — Mon, 07 Dec 2009 19:10:16 +0000

While trying to come up with a way to get two different movies loaded at the same time, to play at different frame rates, I came up with a method to recursively stop all child movies of an as3 MovieClip. I didn’t end up using it, but I thought it might be useful for someone, so here it is:

[cc lang=’actionscript3′]
import flash.display.DisplayObjectContainer;
import flash.display.MovieClip;

function stopAll(content:DisplayObjectContainer):void
{
if (content is MovieClip)
(content as MovieClip).stop();

if (content.numChildren)
{
var child:DisplayObjectContainer;
for (var i:int, n:int = content.numChildren; i < n; ++i) { if (content.getChildAt(i) is DisplayObjectContainer) { child = content.getChildAt(i) as DisplayObjectContainer; if (child.numChildren) stopAll(child); else if (child is MovieClip) (child as MovieClip).stop(); } } } } [/cc] The plan was to use that to stop playing movies, every other frame, and restart them on the alternative frames, but there is apparently no way to tell if a MovieClip is currently playing or not, to know which ones to restart. I did end up hacking Tweener to add support for a Timer based update method. That way I can adjust the stage FPS to match the older timeline content (at 12fps) and have my Tweener based interactions work at a silky smooth 60 FPS. I'll post more on that later.

Trace Actionscript in a Browser

Kevin Newman — Tue, 10 Nov 2009 06:57:09 +0000

Testing Flash apps in a browser can be cumbersome, but it needs to be done for some browser only functionality, such as deep linking and back button functionality – as well as checking other things that might change once you are out of the Flash “test movie” sandbox, and into the browser – things like file path issues. The convenient trace window is not available in the browser, but there are alternatives.

Flash Content Debugger and “Allow Debugging”

While it’s not essential for tracing, the first thing you should do, is make sure you are running a content debugger version of the Flash Player. You need both the Active X version for IE, and the Plugin version for everyone else (Firefox, Chrome, Opera, Safari, etc.). Both plugin types have their quirks with regards to JavaScript (and other platform differences), and really require specific testing in each, so make sure you grab both versions. Once you have those, you’ll be able to see uncaught exceptions in AS3 swfs right in the browser. You can even use the Flash Content Debugger from the browser, though I haven’t found a smooth way to do that yet. For many thing, a simple trace is all you need.

A quick tip that took me a while to notice – the “Allow Debugging” checkbox in Flash’s Publishing Settings dialog, actually causes the Flash compiler to add debugging symbols to the compiled swf, symbols that give you useful information like the actual line number of an error, in addition to the stack trace. The “Allow Debugging” verbiage, is most definately not enough to communicate that difference – I thought it was more of a locking mechanism. Hopefully you haven’t stumbled around for too long with that, like I did when I first switched to AS3..

Tracing

The easiest way to trace from Flash is to use Firefox with the FlashTracer extension from sephiroth.it. With FlashTracer, you can use the regular old built in trace method without any extra work on your part. Make sure you download the one from sephiroth.it (2.3.1), since the one from addons.mozilla.org (2.2.0) doesn’t work in Firefox 3.5. For many things that’ll be all you need. But sometimes, you’ll need information in other browsers, and will want to trace to the browsers JavaScript console. In addition to simple trace messages, you can also call a number of other methods that will out put your messages in different formats and colors, making it easier to spot what you might be looking for.

Check out the Firebug Console API for more information.

Enabling the JavaScript console

If you are already familiar with the various JavaScript consoles, please feel free to skip to this part.

Each of the major browser vendors has a JavaScript console implementation, and thankfully, the API is mostly compatible with one another. The GUI is a bit different in each (except Safari and Chrome – both are based on WebKit), so here’s a quick rundown on how to access the JavaScript console for each:

Firefox

You should get to know and love Firebug. It is currently the best developer tool available on any platform – so good the others all copied it, even if they won’t admit it (*cough*Microsoft*cough*). Firefox is oddly enough, the only browser that doesn’t ship with a JavaScript console, and requires you to install an extension. While running Firefox, you can find and install that extension at www.getfirebug.com.

Once Firebug is installed, you will notice a little bug (insect) icon in the bottom right hand corner of the browser window, on the status bar. Click that to open and enable Firebug for the page you are currently viewing. Firebug will only turn itself on, on a site by site basis, and only after you click on that bug icon. Once it has popped open, you will see some tabs, with many goodies like the fabulous “Net” tab (very useful to make sure swfs are being loaded in the browser), and the “HTML” tab, which contains a live, nested version of your html code, which can be edited in real time – it’s hard to describe how much better life is in the Web Development since Firebug. Anyway, the tab we are interested in, is the “Console” tab – click that. On the actual tab, there will be a little down arrow – click that to open a menu, then click “Enabled” to turn the console on (the onscreen instructions are a little odd, their picture is of the “Script” tab – the arrow you want is on the “Console” tab, not the “Script” tab).

Internet Explorer

You’ll need to upgrade to IE8. If you are stuck on IE6, I’m sorry for you. You will not be able to easily debug Flash apps – that browser is simply difficult to work with, and you’ll probably need to output to either a text field within flash, or to a div element using JavaScript. Go and download IE8 now, if you don’t already have it. Once you have IE8 installed, you can find the “Developer Tools” under “Tools” menu. You can also press F12 to bring them up. The dev tools in IE8 are docked to the main window, along the bottom of the screen, very much like Firebug. You will notice 4 tabs in a blue bar, below a row of link buttons – click the “Script” tab to open the script tools. You will have two panes at that point – in the left is a debugger, and in the right pane, you should see a button for the Console.

Safari

You’ll need to enable the developer tool first, before you can turn on the JavaScript console. Click on the gears icon on the main toolbar, and choose “Preferences”, then click the “Advanced” tab (the one with the gear icon). On that page, there is a checkbox labeled “Show develop menu in menu bar”. Check that, and close the window. Now under the Page icon menu, you’ll see a sub menu called “Develop”. In that sub-menu, choose “Show Error Console”. This will open the “Web Inspector” window. You can dock the window along the bottom of the main window by clicking the dock button in the bottom left of the Web Inspector window. To the right of that button, there is another button with a greater than sign, and three lines. That button will toggle the JavaScript console.

Chrome

Click the page drop down icon on the right of the main toolbar to open the main menu, then go to Developer, then JavaScript console. This will open the “Developer Tools” window, which contains the many things, including the JavaScript console. You can dock window inside of the main window by pressing the dock button on the bottom left of the popup window. To the right of that button, there is another button with a greater than sign, and three lines. That button will toggle the JavaScript console for Chrome.

Opera

Under the Tools menu, choose the “Advanced” submenu, then choose “Developer Tools”. This will open a panel along the bottom of the main window (sensing a trend here?). In that panel, click on the “Error Console” tab. If you’d like to only see JavaScript errors, you can click the bottom JavaScirpt tab (under the white output area of the Error Console). Note: Their is an alternative “Error Console” under Tools -> Advanced -> Error Console. Try them both, and use the one you prefer.

Tracing to the Console

Once you have familiarized yourself with the JavaScript console, you can start to trace to it. The JavaScript command is simple enough:

[cc lang=’javascript’ ]
window.console.log(“your message”).
[/cc]

From Actionscript you’ll need something like this:

[cc lang=’actionscript’ ]
import flash.external.ExternalInterface;
ExternalInterface.call(“console.log”, “your message”);
[/cc]

Since we are using ExternalInterface, you’ll need to make sure you have the allowScriptAccess object param, or embed attribute set to an appropriate value – either “always” or “sameDomain” (sameDomain is the default, so as long as you have your html/javascript/swf all on the same domain, you should be good to go).

You should now be able to trace (or something like it) in the browser. Next time I’ll cover some more advanced uses, as well as some more specific snafus with deep linking and browser back button functionality.

The forums are back!

Kevin Newman — Tue, 14 Jul 2009 23:38:57 +0000

I got a suggestion that unfocus.com needs forums (well, forum). So just for fun, I thought I’d dig up the old archive, and see if I could get it to work. And it did! Pretty easily too. You will have to register to post, since I can’t get the anonymous plugin to work yet – … Continue reading

MouseWheel on Mac

Kevin Newman — Fri, 17 Apr 2009 23:45:10 +0000

So for some reason MouseWheel.SCROLL events don’t work on Mac OS X. There is a fix! Gabriel over at Pixel Breaker created a script which fixes it up nicely.

The script did require some modification to get it to work with SwfHTML, since it was designed to work with SwfObject. It took very little modification to the JavaScript to make it work with any flash embedding script. The script has a register method that takes an id, and uses SwfObject’s getObjectById method to get the swf ref – I just changed the register method to take a swf reference instead of an id string, and viola! It works with anything now. While I was at it, I also took care of some errors you might get on non-mac browsers. Here’s how to use it:

[cc lang=’javascript’ ]
// with SwfHTML
swfmacmousewheel.registerObject(
unFocus.SwfUtilities.getSwfReference(“swfId”)
);

// with SwfObject
swfmacmousewheel.registerObject(
SwfObject.getObjectById(“swfId”)
);
[/cc]

You can really use any method you want to get a reference to the swf object, and pass that in.

Here is the updated swfmacmousewheel javascript file. Note, you will still need to grab the source and follow the instructions from Pixel Breaker.