Archive for January, 2006

Macromedia Director MX04: Great looking Image Scaling Code

Thursday, January 26th, 2006

Recently I wrote about looking for a better way to scale images in Director. Well, Josh Chunick came to my rescue on Direct-L (actually Robotduck posted Josh’s code, but Josh posted about it shortly after). Read the rest of this entry

Scaling images in Macromedia Director MX04

Friday, January 20th, 2006

I’m looking for a method to scale images down in Director that provides better quality than CopyPixels or sprite scaling.

Here’s an original:
scale-original

Read the rest of this entry

Macromedia Director: Find in all scripts function

Thursday, January 12th, 2006

Director Message Window I often find myself using ctrl-F in Macromedia Director to look for a piece of code. It’s quite useful and I use it to hop around from script to script a lot instead of finding and clicking on them in the cast window.

However, occassionally I’m searching for a needle in a haystack, and Director’s Find and Find Again (ctrl-g) aren’t very good for that. Especially when the needle I’m searching for is a common word that occurs a lot in comments.

I wrote this piece of code to solve that problem. It’s a find command that’s run from the Message Window. It will search through all the scripts in the movie looking for the word you entered, and by default it excludes comments. It outputs its results in the message window, which makes it easy to scan, and you won’t lose your place in your current script. Read the rest of this entry

Adobe’s own web problems

Tuesday, January 10th, 2006

I find it hilarious, and perhaps a tad embarrassing, that Tom Higgins at Adobe/Macromedia had to delay the Shockwave 10th Anniversary contest results because it’s “in the queue for some web team attention

In the queue for some web team attention? This is the company that makes Dreamweaver, Cold Fusion, Contribute, GoLive, Acrobat, Flash, and Shockwave. You know, the web and print publishing specialists? They should be the last company in the universe to have a web publishing bottleneck. I’ve been worried about the Adobe/Macromedia merger since the day it was announced, and I hope this isn’t a sign of more bad things …

Taking Screenshots for your Blog

Monday, January 9th, 2006

The blurry Google Desktop screenshotAre my eyes failing me? I was visiting Google’s site after their CES announcement and looking at a lot of their different apps when I came across Google Desktop. But their screenshot was looking very blurry. Then I took a closer look. I was shocked. Even the mighty Google is capable of making rookie mistakes, and the blurriness I’m seeing is one of them.

It’s actually not-that-rookie of a mistake. In fact it’s often hard to detect if you’re the one taking the screenshots. In Windows XP there’s a technology called Cleartype which makes text appear to look smoother on your monitor. However, the key part of what I just wrote is your monitor. Cleartype is monitor-dependent, meaning that what makes a font look smoother on your monitor might actually do the opposite on other people’s monitors. The short version of this tale for people who want to skip the back story is: turn off Cleartype before taking screenshots. It can look horrible on other people’s monitors.

Here’s why. You may be familiar with “anti-aliasing”, which smooths out graphics so they don’t look stair-stepped. What you may not know is that proper anti-aliasing is based off of sub-pixel resolution. That’s right, splitting pixels in half, a third, or even smaller. Check out this image of a black circle on a white background, with a magnification right next to it:

anti-alias

In the magnification you can see the edge of a circle passing through pixels creating shades of gray. The gray is not picked arbitrarily though, it’s calcluated. The shade of each pixel is determined by analyzing the volume of the pixel, and how much of that volume is taken up by the black circle versus the white background. The percentages of colors are then averaged together to determine the entire pixel’s color. (You didn’t think we could really sub-divide a pixel did you?) A pixel whose volume is 90% circle and 10% background will be a dark gray. A pixel split 50/50 will be exactly medium gray.

That’s how traditional anti-aliasing works, and that works the same regardless of what monitor the image is displayed on. Cleartype anti-aliasing is different. It actually divides your monitor’s pixels into sub-pixels. No, I’m not kidding. Here’s how.

Cleartype relies on the fact that each pixel in an LCD monitor is actually three individual sub-pixel elements: a red one, a green one, and -- you guessed it -- a blue one.

an LCD pixel

The image above shows a solid pixel on the left, and what that same pixel would look like if you were to magnify one on an LCD monitor. The sub-pixel elements are aligned side by side, usually left-to-right. By varying the brightness on each of these three individually they can appear as one cohesive pixel of any desired color. So a single pixel of RGB value #c9a347 is actually three sub-pixels valued c9, a3, and 47, respectively.

Cleartype takes advantage of this and does something tricky: when it anti-aliases a font, it actually subdivides the pixel into it’s three sub-pixels and treats them each independently during the anti-aliasing process. (You didn’t think we could actually sub-divide a pixel, did you?) Here we go through the process on a single pixel magnified hundreds of times:

LCD ClearType Steps

  • In Column A we have pixels divided in half, diagonally (one right to left, the other left to right). With normal anti-aliasing both would both end up as medium gray.
  • In Column B the pixels have been split into it’s three RGB elements; you can clearly see how some sub-pixels have more of the black half cutting through them.
  • In Column C each element is analyzed independently based on how the black edge intersects their actual physical location in the monitor. Sub-pixels with more of the black in them are darker while sub-pixels with more of the white in them are lighter.
  • In Column D the RGB value of the pixel is set based on that weighting.
  • In Column E the actual color of the pixel is shown. This technique introduces some color bias (notice one pixel is kinda red while the other is blue) at the expensive of spatial accuracy, but with small pixels in text the color bias tends to go unnoticed, and column C shows the best representation of how it affects pixels by actually making a single pixel fade from light-to-dark (or vice versa).

Why does Cleartype do this? Because it’s taking advantage of the sub-pixel’s physical left-to-right positioning in order to render anti-aliasing that is smaller and more spatially accurate than normal anti-aliasing alone. It is effectively giving an LCD more pixels in the same amount of space. Many people say it makes text look clearer and sharper than was possible before, even though it introduces some color bias. Not only does Microsoft do this with Cleartype, but Apple has an equivalent in OSX.

So what’s the problem with taking screenshots with Cleartype turned on?

The problem is that not everyone has LCD monitors. When you take a screenshot with Cleartype on, it’s bias is baked into that screenshot forever, regardless of where it’s displayed (or printed out). And many people are still using those heavy, clunky, bulbous, flickery things known as CRTs. A CRT does not benefit from Cleartype because it does not have sub-pixels, but will still be affected by Cleartype in the negative with a more-pronounced color bias.

Some users are using Tablet PCs with their screen rotated 90 degrees for portrait mode, while others have LCD monitors with sub-pixels in the opposite order (BGR)! BGR pixels don’t make a lick of difference when viewing normal images and text (if you don’t believe me, flip your laptop upside down and take a peek) However, a screenshot taken with RGB Cleartype turned on but displayed on a BGR monitor will have text that will look extra-blurry and the color will look off as if it were on a projection TV that is out of alignment. Yuck.

Blurry Google Screenshot magnified.And I see that quite a bit on screenshots in blogs and on professional websites like Google’s. In fact the blow-up on the right shows the Google Desktop screenshot magnified, and you can clearly see the red pixels on the left and the blue pixels on the right. While the screenshot looked fine to the person who made it, for a lot of users out there it’s looking far worse than if Cleartype had been turned off. That’s why the best bet for anyone taking screenshots it to turn Cleartype off while taking it. It might make the screenshot look a little less perfect to you, but it will make it look a whole lot better for a lot of the people out there.

How to turn Cleartype off

Cleartype can be turned off by going to Control Panel then Display then click the Appearance tab then choose Effects. Then change “Use the Following method to smooth edges of screen fonts” to Standard. This will provide non-Cleartype anti-aliasing. To remove anti-aliasing all together uncheck the check box above it, but Remember that normal anti-aliasing looks the same no matter what monitor it’s displayed on, so you don’t need to turn it off to get a good screenshot.

Mac users: I don’t use a Mac too often so I really can’t say how to disable it on one. But I hear the Mac is so much easier to use than Windows that I’m sure it needs no explanation.

Note: my description of how Cleartype works is not 100% accurate, but it’s a fair estimation that gets to the root of what Cleartype is attempting to do, which is sub-divide an LCD’s pixels into their RGB components.

Macromedia Director: Stepframe and Me

Sunday, January 8th, 2006

Previously I blogged about using Stepframe instead of EnterFrame with sprites and I discussed the why and how of making it work.

After using it a bit I have an update to explain a tick to using it.

The trick is to make sure that when adding to the Actorlist, that “me” is a behavior instance. Check this out. When a behavior is started, “me” is a behavior instance:

On Beginsprite me
    put me
end

result:
-- < offspring "behaviorName" 4 307f148>

While the numbers at the end may vary, that result tells you that “me” is an instance of the behavior called “behaviorName”. If you’re not used to working with instance variables like this, then you should read up on them because they are pretty handy. Read the rest of this entry