Jaco’s Random Writings

This is neither current nor related to anything important. However, I feel like I must share my experience. A while back, my sister had gotten into an accident. Messed up her car pretty badly. So while her car was in the shop being reconstituted, the insurance company paid for a rental. There’s just one problem. My sister at the time was under 21. She couldn’t legally drive that car. So guess who had to sacrifice his car and drive the rental. This wouldn’t be that bad of thing… except that the rental was a 2007 Chevrolet Aveo.

Before I jump right into this, I’ll explain what brought about in me the need to recall this. My dad’s looking for a new car. His is pretty old and he needs a good car to last a long daily commute. So I started thinking about what kind of car I would replace my venerable Toyota with (2000 Toyota Corolla LE). I was looking at sub-compacts, as I’m a bit of an environmentalist/cheap bastard. And I ran across a review for the new Chevy Aveo. This brought back a whole torrent of repressed memories and bottled-up rage. So much so that I was filled with the immediate urge to share my experience with this car.

The version I had was the 4-door hatchback. My immediate impression was that “Hey, this car doesn’t look too bad.” Got in the car. I was immediate uncomfortable. The seats were uncomfortable. The way the inside was laid out mean that the left side of the center console was jamming into my right shin. While tolerable for short trips, anything longer than 15 minutes is painful. There are international laws against this kind of torture. Besides that, the interior was generally chintzy, with everything covered with hard plastic. The driving experience was… meh. A Toyota Yaris is more exciting than this for the same fuel economy and the same price. Besides being weak, the engine had one aspect to it that drive me up the wall. When the car idled, the engine would vibrate so much that the entire car shook. This is at idle, not when you’re moving. And since this is a recent model (relative to when I drove it), it doesn’t speak much for the quality.

Turns out that the Chevy Aveo is actually a Daewoo Kalos that’s been re-branded. A little disappointing to see that GM didn’t even care enough to design a sub-compact for the American market. Well, needless to say, at the end of those 2 weeks, I was so happy to be back in my Toyota. I hugged it and kissed it and called it all sorts of loving names.

So there. That rant was completely pointless and served no purpose other than to allow me to rant.

So my little project I’ve been working on was a slideshow in Flash, specifically Actionscript 3. I decided that I wanted to see if I could program something in Flash without actually using Flash or even Flex Builder. I decided to use the Flex SDK (free) with the Eclipse IDE (also free). Combined with the AXDT Eclipse plugin (free) and LuminicBox (also free), and I got myself a pretty powerful AS3/Flex/Air development platform* at the cost of $0. Eventually most other people fork over the cash and get either Flash or Flex Builder, I might also, but for the time being, I’ll stick to this.

There are quite literally hundreds of Flash slideshows out there. To write one from scratch these days is pretty counter-productive. However, most of them require that you use an XML form to enter the locations of the pictures. A separate XML form for myself and my clients to maintain? This will not do. So, I figured, “Hey! xHTML is XML too! Why not feed the xHTML that the SWF is embedded in back into the SWF and parse that like regular XML?” Theoretically, it sounds pretty simple and makes perfect sense. That’s one of the reasons why many people code in xHTML versus plain-jane HTML. So after about 2 weeks of coding and grinding and experimenting, I got a working slideshow together. Now, I decided to write every component of the slideshow from scratch. Well, to say it was written completely from scratch is a bit of a stretch. I copied a lot of example code and improved on it (most of the code coming from the actual AS3/Flex documentation examples).

While I would love to embed the slideshow here to show everyone, I can’t. There are a few limitations to this approach that I’ll explain in a bit. Instead, click here to see the slideshow in action. Do take a look at the page source to see how the images and parameters are presented.

So essentially, here’s how it works:

1. Loads in external parameters and saves them to global variables. This includes things like whether debug is running or not (believe it or not, you don’t want debugging to be running constantly. Slows things down a lot). Other parameters include required things like the xHTML filename, the id of the <object> containing the embedded SWF, and optional parameters** like the style of transitions and the delay between slide changes.
2. Using the xHTML filename, it loads the xHTML document, validates it as XML, applies the xHTML namespace***, and parses the xHTML document for the images. Specifically, it looks for the <object> tag it was embedded in (this is where the id for the tag comes in handy), and pulls the src attribute of the <img> tags nested in it.
3. Using the data is snagged from the src attributes, it then loads the images in, adding each image into a stack.
4. Once all images are loaded (and it checks for that), the interval timer is started. This timer sets the delay between the slide transitions to be 5 seconds. This can be changed with an optional parameter to however many seconds the image needs to be up.
5. When time comes for a transition, the slideshow checks to see what type of transition it should use. By default, it uses “none”, meaning that it simply moves the image at the top of the stack to the bottom. No frills. No animation. No pizazz. However, this can be changed via an optional parameter to 1 of 9 transition styles: slide up, slide down, slide left, slide right, fade out, fade left, fade right, fade up, and fade down. I might add more over time if people ask for it.

There are a couple of shortcomings that I’m running into with my implementation of this principle. It has to load the xHTML from the server via the .html file. This, of course, won’t work at all if the file that the page is generated from PHP, ASP, or any other server-side scripting language. For this to work with dynamically generated pages, I would have to either one of two things:

1. Contact the server via Flash or some other source that Flash can activate, and have the server run the PHP and send back the generated xHTML. If that’s even possible, then I don’t know how to do that. Will probably have to turn this into a Flex app… which I think would over-complicate this entirely.
2. Use JavaScript or some other way for the SWF to get the generated xHTML document from the browser. This may require the use of some dubious Javascript.

So the short of it is that this slideshow doesn’t work with blogs or dynamically generated pages. At least, not in its current form. I intend on doing some serious research on this and making a branch of this to handle that (and eventually merging that back into the code-base).

Basically, right now, this slideshow is good for people who don’t want to muck about with XML and want to implement a slideshow in a static xHTML page. This isn’t really necessary for blogs, since most blogs have plugins that allow for the insertion of Flash slideshows without mucking about in XML. As for dynamically generated pages… I’ll have to work on that.

Footnotes:

* If you would like to put together a setup like this one, Jake Hilton provides a fantastic tutorial on how to get it working. An important note on getting LuminicBox working: The main SWF for LuminicBox, FlashInspector.swf, needs to be running off of a web server or a local server (via a LAMP stack or similar). This has to do with how Flex SDK compiles the SWF. However, if you run FlashInspector through a local server, the slideshow page needs to be access via that server as well. I found that out the hard way so that you you don’t have to.
** Right now, the parameters are passed via a FlashVars query string. I really wish there was a better method than this, but I can’t find one that doesn’t require some pretty dubious JavaScript.
*** If you’re going to work with xHTML as XML in Flash, you really want to read this article. Turns out that all the xHTML in a document is under a namespace for xHTML. It’s declared when you type <html xmlns="http://www.w3.org/1999/xhtml"> in the document. Flash absolutely, positively will not parse xHTML if the namespace isn’t declared. Read the linked article and you’ll spare yourself hours and possibly days of painful debugging.

It would appear that in my eagerness to push through to the “Final Sketch” phase, I had neglected to do some error-checking in the anatomy of “Cerberus”, most notably in Cerberus himself (themselves… does having 3 heads make it plural?). So let’s take a look at the “Final Sketch” of “Cerberus”.

The final sketch of Cerberus

See if you can spot 10 things wrong with this picture. Ah! Too late, I’ve done it already. Now I’ll whip out my handy-dandy red pen and…. there.

Final Sketch of Cerberus with some serious red pen action going on.

Pretty much all the major mistakes happened with Cerberus. So here they are, 1 – 10:

1. The middle head’s ears are way too low for a wolf head seen from that angle. The base of the ears should be just a little above the top of the eyes.
2. The mouth is all wrong. ALL WRONG. The teeth are sort of accurate, but shape of the mouth is completely off.
3. The general shape of the head is off too. The way it is shaped now looks more like a bear than a wolf. Shape of the mouth isn’t helping this. Head should be shaped more like an upside-down pentagon.
4. The angle the teeth are seen at is somewhat off on the left-most head. Needs to be a bit more top-down.
5. Eyes are too big on right-most head. Those need to shrink. Also, their shape needs to be adjusted.
6. Snout is way too short. Also, the angle is also way off. This makes the right-most head appear more like a large cat than a wolf.
7. Surprisingly, the bottom jaws of wolves don’t really have that much fur on them. It’s much shorter and limited to the bottom of the jaw.
8. The slope of the head is also off. Too sharp of a drop. Wolves have big heads. They really do. This, combined with the angle of the snout, is what makes this look more like a large cat than a wolf.
9. I don’t even know what the Hell is wrong here, but it’s wrong! I guess it needs to curve further upwards. Makes it look like this head had a bad run-in with a sledgehammer.
10. The mad priest’s hands are too small. Need to be about 1/4 bigger.

So there you have it. Proof that haste makes waste. Instead of having Cerberus, I have a three-headed chimera with the head of a wolf’s, a bear’s, and a cougar’s. Now I have to go back into the “Red Sketch” phase and make the needed adjustments.

I’ll post the “Final Sketch” with all the corrections made… as soon as they are made.

Big news! So I brought the portfolio back up. You’ll notice a new link in the top navigation bar called “Portfolio”. It’s the old system that I had from my old, ill-fated site design. Was really hoping that I would be able to re-instate the portfolio with the new site design. But alas, with the delays and tight schedule, I decided that having my portfolio back up couldn’t wait until I ironed out the kinks out of the new site design (and new Drupal back-end). So I re-instated PortMS back there and threw up a template design I had created to originally bundle with PortMS (with some modifications). Yes, it looks different from the site and isn’t integrated in any way shape or form. I don’t like it. But until I get the new system running completely smoothly, this setup will just have to do. Still, I’ve got 3 projects that I need to add to PortMS to make it completely current. No rest for the wicked…

So, sorry for the interruption, but in a couple of hours, Part 2 of the Cerberus Process series will continue. So until then, stay minty fresh.

Oof, just in time for the Blogenning dealine. I was really worried that I wasn’t going to make it. Right, here’s the “Final Sketch” of “Cerberus”.

The final sketch of Cerberus

• Mistakes have been fixed. This is more anatomically correct.
• The roughness of the previous sketch has been cleaned up and the lines overall have been tightened up.
• Any details that were suggested in the previous phase have been more fully fleshed out.
• More detail was added in many parts.

These phases were done at 150 ppi. The reason for doing it at this low a resolution is simply that my PowerBook is 4 years old and wouldn’t allow me to do fast sketch strokes if the picture was at 300 ppi, nevermind 600 ppi. Quite frankly, this isn’t such a big deal, since resolution isn’t as important here, since this won’t be part of the final image. However, for the next phase, the “Final Inking” phase, I’ll have to ramp up the resolution to at least 300 ppi. I’d like to see it at 600 ppi, but I’ll have to see how my system perform at that resolution. Otherwise, I’m just going to have to be happy with 300 ppi.

C’est la vie…