There is a lot of tricky logic in this application that is not so obvious just by looking at some screen shots. There are the delicious differences between Windows XP and Vista on how they deal with shared native libraries. There are minimum two gotchas. One, if you link against stuff like Visual C++ or MingW32 G++ you must add the C++ library to your application base path on Vista. It will not work the way it does on XP, where the DLL can just be on the system path. Second, any custom JNI library must be added to the system path before a VM is created. Just setting java.library.path will not work on Vista -if- the path is not the base path (“.”).

Then there are the lame GlibC problems on Linux. It appears that closed software is not really supported, because the abundance of GlibC versions makes it hard to create some executables that work for “most people”. Also, most Linux forums consist of nothing more than “your distribution sucks” comments, so finding a solution to this problem might take some time. There are limits on how much intellectual drivel I can absorb on any given day.

Microsoft only web camera's is another problem. Because of the built in web camera on new Mac's a lot of web camera vendors seem to have gone Microsoft only. I am not sure if this is a new concept, but is hard to find something that works on both Vista and OS X and that is not a toy. It would have been nice to check the performance and image quality independent of the operating system.

Finally there is the reality that JOGL might not work everywhere. People on 64bit platforms are a bit of a headache. It is really hard to test every possible combination of software and hardware while at the same time move forward feature wise. In Teppefall Capture I have been experimenting with asynchronous loading of native code and trying to make the UI stay together if something is missing, but it is proving to be a hard challenge. A Linux user with the wrong GlibC will just get a corrupt Swing layout and a ton of exceptions when running the application as it is now. I might have to probe the system before launching the OpenGL view and hope that the probing itself does not cause a problem.

These screen shots show you the application in final assembly. Notice the margin differences and the red hit code area. Hopefully the Sun scene graph projects will make it easier just to create a simple button on some custom background graphics. My own code is fast enough, but is not reusable, it does not support the keyboard focus cycle and it is hard to understand. I am thinking about adding some vector based animation to the top, but it might be too cheesy and is high on my cut list for 1.0.

And yeah. No Java 1.6 for my Powerbook, so who knows what happens there. Also, Server/client mode X11 might bite me in the ass because of all the raw data I am moving around. Sun kind of forgot the whole “oh... you want video with that ?” debate of 1999.

Posted by JP at 02:32 PM | Permalink | Comments (0) | TrackBacks (0)

This application is still a work in progress, but I am tired of keeping it a secret so here is the dirt. Teppefall Capture is a simple Photo Booth clone. By simple I mean it is built on the FX/Layout stack, has an OpenGL powered live preview (JOGL + TextureRenderer) and gets its video feed from a custom video capture library.

The video library just wraps JMyron and Quicktime API's, so it can't be used for anything fancy, like movies etc, but is fine for web cameras. I wrote it so that Capture can support third party decoders in the future. Also, the pathetic reality of Java media forces me to support several code paths per platform just to have a slight chance of being able to extract images from a web or video camera. My focus is simply on images and maybe some filters. Video would force me to step into the world of Quicktime madness where nothing works on Windows if the moon is in the wrong alignment. And Java Media is in the stone age, so I doubt that will work any better.

These screenshots show Teppefall Capture under the Substance Graphite look and feel running on Windows Vista. The video feed is provided by a JMyron decoder.

This application has something like 30 threads, 10Mb of dependencies and is extremely volatile. It might still be shelved since it has a high number of problematic bugs. This application not only takes down Java VM's... it can crash Windows XP if there is a driver problem. Blue screens for everybody ! This is usually because my primary video decoder is based on Jmyron, which is a native library with zero tolerance for sloppy coding. Just a small change in the threading or start/stop code can crash the entire application.

Capture was built using Teppefall FX/Layout and has only a few lines of JFC/Swing layout code. Everything else is done in Teppefall Layout JFC – my homegrown XML format. The 2D renderer on top was prototyped in Javascript and then converted to Java, but it still runs in the same SurfacePanel component (the one used in FX). I though about compiling the Javascript into a Java renderer, but I doubt it will work as well - or at all. I also need all the performance I can get. I had to do my own hit code for the RSS tag and stuff like that is easy to mess up.

Performance is a big problem in an application like this. The current version eats up 98% CPU when showing a live video feed (no restrictions on FPS or JOGL). Because of this I am forced to shut down the live preview when an image is being written to disk. There might not be enough CPU power available on my machine to do both things at the same time. I am primarily worried that Capture will make media players skip on single core systems. So a lot of thought has to be put into the way you move data around. Telling people that “it works on my system” might not be the best route.

Anyway. I have no release date. Before summer I think.

Posted by JP at 08:42 PM | Permalink | Comments (0) | TrackBacks (0)