Saturday, 22 June 2013

New birth

Finally back from Cannes Lions festival, was doing visual application in collaboration with Arcade Studio and Microsoft for Soft Array (Structure hold an hefty 39 surface pros and 4 all in one Asus).

Software runs real time distributed 3d audio reactive visuals, all synchronized of course.

That project will deserve it's own blog post, I'll do a write up once I'm done

For this project it was the first time I use my new shiny in house tool, called FlareTic.
It's basically written from scratch (almost).

So most people like to explain why they do something, I'm normally not like that (I just tend to say : because it's cool / because I can ;)

For once I have a decent rationale about it, so I decided I would share it :)

So why starting to write your own tool and not using some pre-made framework (like vvvv/openframeworks/cinder) ?

  • I need an executable : original idea is to use it as demo tool, I need to be able to export, that removes vvvv
  • I need source code : I am a programmer, I can read/debug code, and when you have lot of devices any bug in your framework can turn things into hell (when you on crunch time for final installation day/night). So I need to be able to run a full debug ... period.
  • I want to use DirectX : No offense to OpenGL, but their API is clunky. Of course you always end up having an abstraction layer, but starting with already a clean API makes your life easy. So that means for OpenFrameworks or Cinder I need to write a DX rendering layer. Ofx I way too verbose for my taste (so that discards it out of the box), Cinder I already wrote a Directx11 Renderer for it (I should publish it at some point).
  • I want Metro Export : For my phone mostly, that gives point 1 and 3 ;)
  • I want dynamic compilation for shader/script, and some graph editing : Don't want to recompile/copy 43 times an app each time I tweak something. I could use lua and cinder, but dynamic c# compilation is easy and I already got lot of routines in c#, so I might as well reuse them.
  • Showing off your tool and tell you wrote it yourself is cool ;)
Also since I didn't do any gui programming for a while, that would be a good exercise ))

When you start a new tool you have plenty of ideas, organizing them is not as simple. I normally tend to write fast, refine later. I need fast iterations so I can quickly test a new idea, which can make it into the tool and means I adapt rest of the code because it's so awesome, or can just end up in the recycle bin.

First thing you need is some form of gui (code editor window, graph editor, main form).

So I already have a small graph editor, written using Direct2D, which is pretty nice and has all the features I need for it : good font rendering engine, basic shapes, bezier for links, and hit test functions. Please note that hit testers was a bonus, it's plain easy to do, but saves you time since it's already there. So I added undo/select/smart link/zoom/pan features, which where all pretty easy.

Also I had a minimal inspector with basic controls (sliders, toggles...)

Code editor was some simple window with a TextBox. It's was super minimal, but enough for early dynamic compiler tests. So I moved to ICSharpCode.Editor so at least I could have syntax coloring. Intellisense support will be for later (only for the c# version, I don't like it for hlsl, I ditch the file right away anytime I install a new vvvv version ;)

Now last (but not least). Patches were into a TabPanel and scripts were separate windows. That can turn your desktop into a big mess quite fast. So I moved to the awesome DockPanelSuite so I can arrange everything I want Visual Studio style ;)

Here is early version of the tool:

New version (graph didn't changed that much except few refinements, but more on user side) :

Still needs some polish, but already quite nicely useable.

I'll speak about evaluation model in next post (eg: likely today), and two things to finish (and make things clear):

  • This is an in house tool, and I have NO plans to release it in the near future. So please don't ask for a beta answer will be a polite no ;)
  • I am not leaving VVVV (I could see some users to be a bit worried about that). VVVV is still an integral part of my workflow.
  • A decent part of the codebase is shared (vlc player/kinect/dx11 rendering...) so lot of improvements will be beneficial for both softwares at the same time.
  • Some nice new features come from ideas I had with the tool, like the up and coming JSON scene exporter was done so I could design scenes in VVVV and import them in FlareTic. But importer is also in VVVV.

No comments:

Post a Comment