I’ll admit to being one of those people that, until recently, considered Javascript to be substandard and barely a “real” programming language. My opinion began to shift with the rapid advancement of JS engines like V8 and introduction of powerful HTML5 API’s like Canvas and WebGL. I find myself playing more and more in JS and utilizing my Java/AS knowledge to build experiments. Recently, there has been quite a bit of buzz surrounding Javascript size competitions like JS1k and 10K Apart. JS1k alone has hundreds of quality entries. Of course the cynical Flash developer in me wants play down the excitement of these competitions. After all, very similar results have been produced in even stricter Flash contests for years (look at what @piXelero did in just 140 characters). But we’re talking about frickin Javascript here, and the new plugin-less API’s really are something to get excited about, so count me in.

JS1k only allows one entry, so I had to omit earlier attempts. The first was a Roguelike game that I couldn’t compress enough (best result was 1.35k). The second attempt was a 3D Lorenz attractor which evolved into my actual submission, a 3D twisty Sierpinski Gasket. I used several hacks to fit the entry under 1k, but most of the compression was done in Google’s Closure Compiler.

Update: I’ve implemented the gasket in WebGL as an experiment. The result is amazing, with a cloud of over 1 million points (10 iterations) and a much better FPS.

WebGL Mandelbox Explorer

Note: This demo requires a WebGL capable browser. Installation instructions can be found at Learning WebGL or the WebGL Wiki.

This weekend I put the finishing touches on a WebGL Mandelbox explorer I’ve been tinkering with for the past week or so. If you’re interested in the mathematics, Tom Lowes who wrote the Mandelbox formula does a good job explaining it in detail on his site. I’ve been captivated with the pattern ever since watching Krzysztof Marczak’s amazing Mandelbox trip on YouTube (a must-see).

Traversing a 3D Mandelbox in real-time is intensive on any platform, but WebGL does a fairly good job thanks to the GPU. I still need to lower the fractal iterations upon interaction, but that was expected. Rrrola was nice enough to post some source for his real-time explorer, which I ported to this version. I’ll add my own refinements over time as I get more comfortable with the formula.

There is plenty of room for refinement, but basic mouse and keyboard movement controls make exploration fairly simple. Things like camera viewing angles will be patched in over time.

This will be an evolving project. If you stumble upon any bugs or have suggestions, I’d love to hear them.

I tend to stay away from the HTML5 vs Flash "debate", principally because I think it's inane. Both platforms offer certain advantages over the other and some interesting results can be achieved by utilizing their strengths. Case in point, Flash's built-in webcam support and WebGL's hardware-accelerated 3D graphics are features that only exist in their respective platforms (for now). Bridging the technologies produces something unattainable by only using one, as the following quick examples illustrate.

Simple interactive cube.

Plane deformation (Kaleidoscope shader by iq ported from Shader Toy).

Raytracing (Kinderpainter by iq ported from Shader Toy).

Passing webcam data to Javascript involves a few steps. The BitmapData drawn from the Video object needs to be compressed to JPEG and encoded to Base64 for the data URI to read it. This can be a very taxing process in native ActionScript, but is nearly negligible when done in haXe or Alchemy. In this case, I'm using both. The JPEG compression is performed by metalbot's Alchemy JPEG encoder, while the Base64 encoding is handled by Bloodhound's haXe crypto library. ExternalInferface passes the resulting string to the WebGL's texture Image source with the following method:

Not only is it possible for HTML5 and Flash to peacefully coexist, but they can also help each other achieve a result not possible on their own. Kumbaya.

Check it out!
view source

In an effort to explore some of the emerging interactive development environments, I decided to look at the canvas element at a deeper level. When the tag first debuted, I mucked about with some basic bitmap operations to get a feel for it, but nothing significant. Recently, the modern browsers have begun to demonstrate much faster JS engines, and this warranted a closer look. I'm fortunate enough to know Christopher Emirzian, whom allowed me to port his fantastic liquidjava experiment. We both thought it'd perform significantly worse than the result. Of course there are still several bugs, but Javascript is proving to be much faster than expected. Perhaps Mr.doob is actually onto something!

If you're in or around Cleveland next weekend stop by Notacon, an annual hacker conference with a creative twist. In their words, it "explores and showcases technologies, philosophy and creativity often overlooked at many hacker cons". I'll be giving a talk about my experimental work in Flash with a focus on Alchemy. Notacon is also the venue for Blockparty, a North American demo party organized by Jason Scott and Christian Wirth (RaD-Man). I worked with Jac from Evoflash and musician Coda to build this years invitation for the party. Should be a great time!

Check out the invitation.
Note: All effects are real-time, so this is best viewed using the latest build of Flash Player 10.1.

Today I finally launched ASCIImeo (asciimeo.com), a personal project I've been working on irregularly for the past few months. In a nutshell, it renders Vimeo videos in different textmode's. I hope everyone enjoy's the site; it's simple and generally useless, but a ton of fun to explore. I'd love to hear your feedback, rants, and bug reports (I was after all the only person working on this).

Here are some of my favorite videos in ASCII:
Metamorphosis by Glenn Marshall
MOTOR / AMBIENT REEL by KU-SCHNEIDER
Magnetic Ink by flight404
Still Run by DANTE NOU
Look At Me by Patrick Lawler

The player is an evolution of earlier video experiments I was doing in Alchemy. Still using Jari Komppa's TextFX7 engine for the glyph conversion and AS3ANSI for the rendering, this version features improved speeds and a control UI including fullscreen mode.

When this project was first conceived, I had considered using the Youtube API, but after reading through their TOS that idea quickly vanished (obstructing the video is a violation). Vimeo didn't pose the same problem, and in retrospect, it was a wiser choice considering the greater quality and style of most of their videos. Tying it to Vimeo was straightforward given the ease of their API and liberal cross-domain permissions (truly there is no better online video community). The only real challenge was brushing up on my rusty CSS skills to get the site displaying correctly cross-browser.

Speaking of challenges, there are still a number of unresolved issues that I hope will be ironed out in the future. The worst one occurs when the player encounters a redirected cross-domain policy file on one of the video servers (specifically vimeo.o4.bitgravity.com). Adobe states: "since version 9,0,115,0, however, Flash Player has treated redirected policy files as though they had originated from the final, post-redirect URL". This means there's no way to invoke the BitmapData.draw method for content on the pre-redirect URL without being thrown the dreaded #2122 error (sandbox violation). There's no current workaround. Regardless, this only happens to a small percentage of videos and occasionally their location is shuffled around.

ASCII video players aren't new, they've been developed on countless platforms including Flash (VLC Media Player had an ASCII filter, and even Apple released an ASCII Quicktime player). With ASCIImeo I really wanted to take advantage of the environment Flash can live in: online, interactive, and social. In the end, I think I've created something new from an old idea. You can be sure I'll be rambling about this at FITC.

UPDATE: Thank you to the many individuals that reported the flakey search results. I've tightened up the calls to the Vimeo API and everything seems to be working well now.

Getting into the Christmas spirit, I thought I'd play around with raytracing reflective spheres to produce the fractal known as Wada basins. It's an old technique that can be easily reproduced physically by using four mirrored Christmas ornaments stacked in a pyramid. To be honest, the idea came from seeing the mirrorball Ralph picked up to use as a lightmap for Triangle3D.

I bought a set of mirrored ornaments for our tree and set them up in a pyramid:

The fractal appears through the center:

I've been wanting to write a simple raytracer (the Alchemy version I posted a while back was a port of PixelMachine) in pure AS3 for some time. This experiment marks the first steps towards that goal. You can check out the source code. It'll grow over time as I clean up the structure and add optimizations.

The first AS3 test draws the image line by line to avoid some serious stack overflows. Camera positions, lighting, reflectivity, and other values can easily be changed within the source. I'll draft an API over time. The result is a 4K swf:

An Alchemy version of the same logic achieved much faster render speeds (minus the line drawing), but the resultant swf was well over 100k:

An attempt at simple interaction with the Alchemy version:

1000x1000 pixel render:

The next step will be to write a WebGL version and compare it to the Flash speeds.

Check out Viewtronics!

The best things in life are often silly, and in this case gloriously retro. Blocktronics, a collective of the best textmode artists around the world, have released their second art pack entitled "Codename Chris Wirth" in homage to the legendary ANSI artist RaD Man. No, it's not 1995, and yes, this kind of art is still being produced in stunning fashion.

Along with the pack, this marks the debut of a textmode viewer I've been working on for some time called Viewtronics. The project is a refinement of my AS3ANSI engine which powers Flashterm, and includes features such as multiple fonts, zooming, and image generation.

Great job B7! Make sure to check out a special FITC piece by enz0:

Check it out!

NOTE: You'll need to use a Mozilla trunk nightly build (switch webgl.enabled_for_all_sites to true in about:config) or Chrome developer preview version (use "--enable-webgl" and "--no-sandbox" command-line switches). A video is included in this post if you're having trouble installing.

After learning the basics of fragment and vertex shaders in my last example and using the Spore creature viewer as reference, it was fairly straightforward to implement texturing and lighting. Take a look at the source to see how it was done, and how the positioning matrix has evolved.

Having limited OpenGL knowledge, the learning experience with WebGL has been very good since it requires JavaScript to supply all the shader parameters. I have some concern with JS being able to handle a more intensive implementation, but further experimentation will expose that. Regardless, I'm loving the current performance results, especially when compared to Flash alternatives.

 

View on Vimeo.

UPDATE: Perspective added to the example. Thank you, Giles.

Check it out!

NOTE: To view WebGL, you'll need to use a Mozilla trunk nightly build (starting September 18th). Once installed, switch webgl.enabled_for_all_sites to true in about:config. Your OpenGL drivers will also need to be up-to-date. A video of the experiment is included in this post if you're having trouble installing.

A couple weeks ago, Vladimir Vukicevic posted the first working sample of WebGL, which gives us a glimpse of how JavaScript will access OpenGL ES 2.0. Since then, we've seen a number of impressive demos, and it seems GPU accelerated 3D in the browser is finally becoming a reality. This technology deserves attention.

Of course with WebGL in its infancy (even though they've been working on it for years), and the spec still in flux, no documentation exists. Learning the API involves scouring sample source and the nsICanvasRenderingContextWebGL interface reference. My OpenGL programming knowledge being limited, I had to use iPhone OpenGL ES 2.0 guides to get me up to speed with the spec. Jeff LaMarche has a fantastic series on the subject, and I decided to use his icosahedron example as a starting point.

It's a simple low poly test, but I'm rather impressed with the result. And really, who can complain about finally having access to the GPU? Hopefully there aren't too many roadblocks (ahem, Microsoft/DirectX) in the way before this spec becomes official. Next step for me will be texturing.

Amid the discussion caused by my memory allocation problem on the Adobe Alchemy forum (which I summarized in a previous post), it was confirmed by Cod3 Monk3y, Inc. that std::string is broken in Alchemy. Specifically, the copy constructor does not seem to be functioning properly resulting in very unusual behaviour and rendering the class unusable. This is very bad news for developers like myself who have plans on porting C++ libraries over to Flash, and certainly throws a wrench in my hopes of seeing an online version of ASCIIpOrtal.

For those unfamiliar with copy constructors, they're a special constructor used in C++ used to create a new object as a copy of an existing object. They are essential in heavy operations with the class since they are called when an object is created from another object of the same type, when an object is passed by value as a parameter to a function, and when an object is returned from a function. In the case of std::string, its copy constructor definition can be found in /avm2-libc/include/c++/3.4/bits/basic_string.h as follows:

Cod3 Monk3y, Inc. wrote and excellent example, which works in standard g++ but fails in Alchemy, that illustrates the bug (below). Following the bug confirmation, he wrote his own string class which forced copies, but uncovered another nasty bug with std::ifstream.

It's not exactly shocking that an unsupported alpha research project like Alchemy has bugs. Hell, we all expected them. What I'm concerned about now, is how silent Adobe has fallen. We're nearly a year into the Alchemy announcement, and there is still no public bugbase or patches. Though I doubt Adobe would abandon such a promising and well received project, I'm worried about the speed at which it's progressing. Hopefully I'm just being too pessimistic and need to be more patient. With MAX right around the corner, we could be in for an update shortly (fingers crossed).

Further reading:
BUG: std::string serious problems
BUG: std::ifstream serious problems

Here's a simplified example of what I'm trying to do:

This should give me a multidimensional vector (in this case rawmaps[0][0] gives me the first line of the first map), but the values are getting overwritten in 'memory'. That calls for memory allocation, which I assume means using the reserve method or defining the blocks to reserve in the constructor. For example:

But it doesn't work. The methods fire correctly and are stored correctly directly after their assignment operation, but over time the earliest values are being overwritten as if memory is not being reserved.

I had the same problem with my metaball experiment where I was using the following structure for vertex information:

Over time the earliest values were getting overwritten. Here is a link to a very early build where the problem can be seen in action (it's super slow because I had papervision drawing the triangle mesh and still had not written any optimizations). In this case, I solved the problem by restructuring the data back to pointer types:

This method works, but there still seems to be major issue with the memory allocation of std::vector, and possibly other data types. I've put together a simplified example of the string vectors I'm working on in an effort to demonstrate the problem. You can download it here. The example loads a text file into Alchemy, and reads/stores the length of each line in a vector, and then stores that vector inside another. You can see the values getting modified in the trace log.

If anyone has insight into this problem, I'd love to hear your feedback. I'm hoping it's just a case of my noobish C++ understanding, but likely it's not, and we'll need to make the Alchemy team aware.

UPDATE: An excellent post on the Adobe Forums confirming a major bug with std::string in Alchemy.

I've been talking about adding a textmode view to Alchemy for quite a while. In fact, it was the single reason I started playing with the technology in the first place. After seeing Flashterm, Scott Petersen (the lead engineer behind Alchemy) challenged me to port the classic NetHack, a roguelike text game. Since that time, I've played with text convertors, particles systems, and 3D graphics, but never managed to get a reasonable result for textmode - until now, that is.

The project has always been at the back of my mind, but it wasn't until I saw Joseph Larson's ASCIIpOrtal video, that I resolved to take another stab at it. Incidently, Joe runs a great site that has a collection of C/C++ text games that I could test against.

Adding a textmode view to Alchemy means interpreting curses, the terminal control C library for Unix-like systems, with its typical header being curses.h. There are textmode libraries for DOS and other operating systems, but curses and its cousins (ncurses, pcurses, PDcurses, etc) are the most popular. This was my starting point.

Of course porting curses is not straight forward since visually displaying text glyphs is machine specific. Fortunately I wrote AS3ANSI, an AS3 textmode interpreter which was used for Flashterm. So naturally my first approach was to write proxy C functions that send commands (e.g move cursor left 3) back to AS3ANSI to visually display. I used a simple game by Ido Yehieli called Crypt Rove for testing and here's the result:

Check out Crypt Rover

It worked, but the game only used the most basic curses commands and establishing a standard would involve flushing out many more curses functions, some of which are very challenging. This approach also has a major problem with speed since every function is marshaled to AS3, but we're dealing with textmode so it was only slightly noticeable.

After seeing this demo, Joe made a great comment, "Why reinvent the wheel? Just use PDcurses." I was still realitively unfamiliar with PDcurses (short for Public Domain Curses), but did know that it had a SDL extension. Luckily, Ed McManus had already coded a basic port of SDL to Alchemy, so using his code as the visualizer, it just took a bit of work to attach PDcurses and I got my first 'Hello world'. I used Jakub Wasilewskis' roguelike game AJTH for a proper demo:

Check out AJTH

Awesome! With this working demo, I knew I had finally achieved a solution that requires minimal modification of native textmode programs. I wanted to try a more complicated game, so I decided to try Ascii Invaders by Thomas Munro. I love the result:

Check out Ascii Invaders

This is just the beginning. NetHack still hasn't been ported and I have my eyes fixed on OpenCP, but with the foundation laid, I expect to have them working soon. The source will be released once I figure out how I want it organized. It may come as a fork to Ed's SDL work.

Check it out! (note: requires FP 10.0.22)

I thought I'd give an early demo of a 3D metaball system that I've been working on in the lab for the last week. As fate has it, Frank Reitberger also posted a fantastic metaball experiment today with great results. Where our systems differ, is that I've written mine entirely in C++ through Alchemy with the intention of eventually tying it directly to my particle emitter, ensuring the least amount of data marshaling possible.

Keep in mind, this is an early preview and some glitches still exists, namely some forward facing triangles are being rendered in the incorrect order. I plan on sorting the indices in C++ once I find a suitable technique.

Of course, what would a blob simulator be without the necessary webcam support?

For the Alchemy coders, I thought I'd mention an important lesson that was learned with this experiment. Originally I had the vertices, normals, and uvts stored in a value object that looked like this:

The problem is that that blocks of the Alchemy RAM ByteArray are overwritten unless explicitly allocated, and therefore the start of the vertices data was getting written over by indices. The solution is simple and obvious, allocate memory:

UPDATE: Added reflection and Frank's Pixel Bender Fisheye filter to the webcam view.
 

One of the main reasons I started playing around with Alchemy a while back was to experiment with some of my favorite textmode libraries, specifically AA-Lib, which is the most commonly used image-to-ascii-art library of the bunch (has been used with Quake, VLC Player, and many other desktop programs) . It's a frequently requested port among ascii art fans, and I'm glad to finally release it for everybody to use.

Check out the demo!

Download source code

AA-Lib is a low level gfx library written in C. Its API is designed to be similar to other graphics libraries, but its renderer outputs ascii-art. I'm not going to go into any coding detail with this post, as the source is available for download. Programmers with even limited C experience should find the routines fairly straight forward (Alchemy routines can be found in /alc-src/main.c).

The important thing to note, is that AA-Lib will pass back a text buffer ByteArray, and a text-attribute (Bold, Dim, Normal) ByteArray. A flash developer can do whatever he wants with those. For the demo, I've used my own AS3ANSI library to interpret those buffers. I've also included a "Save to Text File" option that allows you to download the raw text buffer to a file.

AA-Lib has many cool features, including the ability to control brightness, contrast, and gamma. Sometimes an image needs to be tweaked in order to achieve the desired output. Play around with the sliders I've hooked up. You can get some pretty crazy results.

There's also an option to invert the image, incase you're dealing with something on a white background or want a negative ascii.

I'll probably evolve this demo into a more substantial app, but for now all the requested features have been added, including uploading, saving to JPG, saving to text, and size parameters. Enjoy!