the HYPE framework
 download / 3.3 mb zip
version : 1.1.9
updated : February 18, 2011
installation & setup
change log
open all | close all
blog
HYPE google group
upcoming HYPE events
No events.
the HYPE framework is a collaborative visual framework developed in FDT and AS3 by Branden Hall and Joshua Davis.
let's keep in touch.
Keep us informed what you're working on using HYPE by connecting with us, either via e-mail or through twitter.

hype@hypeframework.org
twitter.com/hypeframework
Branden Hall

automatastudios.com
twitter.com/waxpraxis
Joshua Davis

joshuadavis.com
twitter.com/joshuadavis
flickr.com/photos/joshuadavis
let's keep in touch.
Keep us informed what you're working on using HYPE by connecting with us, either via e-mail or through twitter.

hype@hypeframework.org
twitter.com/hypeframework
Branden Hall

automatastudios.com
twitter.com/waxpraxis
Joshua Davis

joshuadavis.com
twitter.com/joshuadavis
flickr.com/photos/joshuadavis
HYPE v1.1.1 released!

That’s right ladies and gentlemen, after a short hiatus for the holiday season HYPE is back with a brand new release! And boy howdy, what a release it is!

First off, the large PNG output is in there and as Josh put it “it’s scary easy to use”. Check out the new examples in the ContextSavePNG folder and the update docs for more information. There were a lot of structural changes made to support making this feature – be sure to check out the hype.framework.canvas package if you’re interested in seeing how it all works.

Speaking of scary easy to use, we made a new rhythm – FilterCanvasRhythm, that makes running filters over time on a BitmapCanvas even easier (our readme has been updated to use it rather than FilterRhythm). A nice by-product of FilterCanvasRhythm is that you can use it with the new PNG output feature. If you do try to FilterCanvasRhythm on a BitmapCanvas that has been setup for large output it will make your code run crazy slow, but what do you expect trying to blur a 6400 x 3600 (or bigger!) pixel image?!?!

We’ve also updated ObjectPool so it’s constructor can accept either a single class or an array of classes. If you pass in an array of classes each time an object is requested from the pool it will be randomly chosen from that array.

Finally, and maybe most importantly to the geeks out there HYPE is now on GitHub, so fork away!
Leave a Comment
Brett Forsyth said, on January 17th, 2010 at 4:05 pm

Great work guys. The array of classes is awesome and output and filter features will be really handy.

hans said, on January 17th, 2010 at 5:44 pm

This is big news. The missing link between flash generated animation and the printer! Really, really, great work! 2010, a hype odyssey! Nice, very nice! Thanks!

hans said, on January 17th, 2010 at 6:36 pm

Just tried the ContextSavePNG in an old hype test file. You are absolutely right: it is scary easy to use. It is amazing. I am playing around with the Hype framework without understanding the lines of code! Well, just a basic bit to be honest. Copy, paste, trial and error, mixing with bits of personal really old as1 and as2 code not really knowing what I am doing like the old days. And on opening the png file: big smile! Great!

dave said, on January 17th, 2010 at 8:05 pm

AWESOME!!! Thanks for ContextSavePNG & enabled arrays in the ObjectPool…
Gonna check out the FilterCanvasRhythm…

GREAT WORK…

Ken Huxley said, on January 18th, 2010 at 1:06 pm

Hi Josh and Branden,

Thanks for the awesome work on the PNGEncoder. This is a really elegant solution for print resolution BitmapData output. I can’t believe you guys made such a hellish process so easy. Kudos dudes!

A problem I’ve run into is running out of system memory when PNG encoding. I want to print a 40 inch wide, 300 dpi image from Photoshop. For that I need a source PNG from Flash 12000 pixels wide. This requires a scale factor of 20 on a 600 px X 300 px FLA:

clipCanvas.setupLargeCanvas(20);

However, when I export this critter, my progress bar hangs around 30 % and I get the following error message:

Error: Error #1000: The system is out of memory.
at flash.utils::ByteArray/writeUnsignedInt()
at hype.framework.canvas::CanvasPNGEncoder/encodeOverTime()
at hype.framework.rhythm::SimpleRhythm/run()
at hype.framework.rhythm::RhythmManager/processEnterFrame()

I’m running a pretty beefy Windows box:

Intel Quad Core Xeon E5440 2.83 GHz, 3.25 GB RAM, XP Pro 2 SP 3

I’ve also increased the page file in XP: min: 8184, max: 16368

No dice. Do I just need to buy a truckload of RAM? (If so, any idea how I’d calculate how much RAM is required to PNG encode a 40 x 40 inch 300 dpi image?) Can I use a scratch disk? Any other ideas?

In any case, this is a huge breakthrough for those of us who want to print from Flash. Thanks again for all your hard work and generosity, gentlemen.

Ken

Branden Hall said, on January 18th, 2010 at 2:26 pm

Ken – you’re running into the edge (well, actually over – quite a bit over!) of what the PNGEncoder can do as it is constructed right now. More RAM will probably get you a bit further along, but the ByteArray.compress method that we trigger after the image has been read tends to crap out with around 100,000 pixels worth of data. That being said I’ve been trying very hard, over the past few months, to remember that perfect is the enemy of good – so I decided to release the current version and then work on improvements so that over time we can export bigger and bigger images.

The first fix, which I hope to get out over the next few weeks, will simply export the grid that’s internally being used. For your image it will be 60-70 1024×1024 PNGs that you’ll have to manually stitch together. Not fun I know, but it will work.

The longer term solution is to rewrite, from scratch, both the large canvas support and the PNG encoder so that it can do an incremental solution that will never overflow memory. This is a LONG term goal since it will require me to do a bunch of reading on both the PNG and zLib specs and do a lot of very slow testing. I hope it will be in HYPE eventually and am already doing some of the ground work to make it happen.

Ken Huxley said, on January 18th, 2010 at 4:20 pm

Hi Branden,

Wow, no wonder you guys have been working so hard on this.

Thanks for explaining what actually happens with ByteArray under the hood. I wrote a crude AIR app for PNG export a few months ago that kept hitting a wall around 6500 x 6500 pixels and I could never figure out what the heck was going on!

The stitching method you describe will still be totally awesome. Any way to finally composite some huge Flash bitmapData in Photoshop will be well worth the wait.

Meanwhile I’m going to thoroughly enjoy playing with the creative possibilities opened up by ContextSavePNG.

Thanks for your informative reply and best of luck with the next iteration.

Rock on,

Ken

Branden Hall said, on January 18th, 2010 at 6:44 pm

Thanks Ken! I got another idea today that I’m already starting on! I think it has a decent chance of working… If it does then if you can get the SWF to run at the scale you’ve inputed, then you will be able to get it outputted to a file (though it probably won’t be a PNG).

Joshua Davis said, on January 18th, 2010 at 8:58 pm

an hour later and Dr. Hall is ripping 42 x 24 300 DPI Targa files… hello NURSE. expect 1.1.2 soonish. with our 2 contest winners packaged in community extended.

Branden Hall said, on January 19th, 2010 at 1:23 am

42″ x 24″??? That’s so 3 hours ago! Current record is 64″ x 36″ (Yeah – 5 FEET x 3 FEET) @ the mystical, magical 300dpi.

Ken Huxley said, on January 19th, 2010 at 10:19 am

Holy crap, don’t you guys ever sleep? This is awesome!!!

Thomas said, on January 20th, 2010 at 3:41 pm

I have to admit I haven’t really had a close look on it, but with all this wiring Adobe Apps together Dr. Woohoo did wouldn’t it be a possibility to output the grid and let Photoshop automatically do the stitching? I know, dependencies, but in the end does anybody with Flash not have Photoshop? And I guess Photoshop could do the job way faster and more reliable than Flash will ever do, right?

Branden Hall said, on January 20th, 2010 at 7:55 pm

I’m sure that route would be possible. I just don’t know, at this point, how fast the conduit is between the apps.

That being said, I was able to get Flash to output HUGE images (see above) and the only limit seemed to be RAM.

hans said, on February 3rd, 2010 at 3:44 pm

I seem to have the same problem as Ken.
My output says:

Error: Error #1000: The system is out of memory.
at flash.utils::ByteArray/_compress()
at flash.utils::ByteArray/compress()
at hype.framework.canvas::CanvasPNGEncoder/encodeOverTime()
at hype.framework.rhythm::SimpleRhythm/run()
at hype.framework.rhythm::RhythmManager/processEnterFrame()

First I thought, well maybe to many vectors on screen. But when I reduce the amount drastically, I always get broken png output (png’s of 4 KB). Strange thing is that I had perfect png output some days ago with exactly the same swf.
Also set the script limit higher.
Might be another software eating my RAM. Nope, only Flash was running. Well, and Mail, and Safari. And Flash of course… So I closed Flash and ran the swf in the flash player. And then everything is ok!
Beefy Adobe!
Looking forward to HYPE 1.1.2!

Branden Hall said, on February 4th, 2010 at 1:33 am

Yep, that’s just Flash running out of memory. The player can’t swap to disk so if you’re out of memory, you’re out of memory!

Again though, the upcoming build will support TGA out that can export anything you can display!

Victor said, on February 11th, 2010 at 12:41 am

The ObjectPool update is great! and love reading the progress being made on the Targa output. Time to stop reading and start building! Thanks, guys.