Moving on...

Well it looks like my efforts to fix the problem haven't worked. I've re-installed the software and basically done everything I can think of bar re-installing my operating system to fix the problem. Mysteriously this bug has arisen with no major alterations BUT I do think a few MS updates may be the culprit.

Thankfully I found a set of flash files that do the job I am trying to do for me and I know they already work because I did a test run on these files before using tbeta. So this will be my method of delivery for the time being, though I'm hoping when I migrate to a laptop it will fix my issues, as the code I had looked pretty neat.

So now I have to set up the final bit of this project, with a projector and laptop free standing so it can be taken a part and moved around easily. I also need to test the software on some level, so this is going to be undertaken as well.

Ultimately conclusions and outcomes are purely qualitative and very subjective, but one thing I have seen so far with this software is a massive movement toward a new type of electronic art, which is quite amazing and has endless possibilities. I see the medium moving less toward technical areas like games design or production and more toward this free flowing creative area, though I think that really both areas would come to fruition if the right people were interested in using this hardware/software. However Autodesk are working with Multi Touch screens so we will see!

Touch Sensing Woes

For the past few days I have been trying to get one of three examples running effectively.

I'm having big problems getting my touch sensing software (Tbeta) to work in harmony with the application. When I build and run the executable I get an error where it won't even load the opengl window, it just stops in DOS stating the same error code.

I'm switching now to touchlib and praying that works. I've also added some forum posts to the NUIG group and OpenFrameworks forum, but most of this software works in the Xcode C++ coding application on a mac, not on a win32 machine. But this isn't the culprit.

I've made extensive changes to the code, just got a working re-install of code blocks on the go tonight to try and rectify a litany of issues. Other issues concerned where major problems with VideoGrabber.cpp and quicktime, but these were localised around a set of functions which had not been initialised. Commenting seemed to do the trick, but I think it only broke the file to be honest.

The annoying thing is that this has all started to happen even though the workflow worked a month ago, but now it seems to have stopped working altogether. My deducement is that the FLOSC java application that is part of Tbeta (It sends out touched coordinates from tbeta to a localhost server which then fires them back out to any program that asks for them) is the culprit causing a networking crash. A thread on the openframeworks forum appears to back all this up.

More to come...

openframeworks

I've managed to get tbeta to work with openframeworks the C++ framework for touch interfacing. But interactivity is an issue. I learnt openGL 2.0 a few years ago before I went to University, but my understand is a little to basic.

I have to find a way of allowing the user to switch modes (To do different things), though I could have this interactivity placed onto a key on the keyboard. But even if I did I wouldn't be sure how to change modes, as this involves looping and use of boolean (true false) arguments...which I used to get wrong.

Hopefully I'll find some working code for an image loader, or something similar soon. I will post more when that time comes.

It works!...again

Right, so I've fixed the first programming problem. First of all I should say that the screen is working properly now and I can configure it properly as well. I am still missing a projector, which isn't great and I am also missing a laptop for portability, but that can wait. One less thing to worry about though.

The hardware interfaces with the infra camera, which is interpreted by the software on the computer. I had already been notified of an API framework (Call it what you will) called openFrameworks by developers at Autodesk and so I went to check it out. To cut a long story short I chose this as my end solution. I used tbeta and mtmini software to configure the hardware and test the principles of infra red hardware, before progressing.

Yesterday I found out that I couldn't just interface directly with openFrameworks (Which is built in C++) without having something else handle the multi touch interaction, which was being picked up by the infra red camera. Thankfully the community is fantastic and someone had already had this problem.

Tbeta software handles multi touch movements on screen and configures them and it has a facility to send these movements out through a localhost service (This basically picks up the movement information sent out by tbeta and waits for another application to ask for it) using a specific port. So this was the fix to my problem, because it would do all the hard work for me...famous last words! haha

Well it wasn't so bad in the end. After a full day of tweaking and trying to figure out why the libraries weren't linking properly in Code:Blocks (The C++ shell I am using), I finally got it to work. But I had to update the framework, the addons that I needed to get it to work and my project links.

So now I have a lovely blank window, but hope to have paint or something much more interesting to show for it, very soon!

Waiting on the hardware...

After buying slightly the wrong kit, not the wrong parts but the wrong specification, I'm now waiting on an Infra red 8 megapixel web camera, to see the infra red distortions and interface with the software. A piece of acrylic 450mm by 500mm and the infra red 850nm LED's which are being shipped from america.

Fingers crossed there are no new problems until I try and get the software working again! That's not to say I havn't compiled Openframeworks in Code::Blocks, but I need to see if the software interfaces with the web cam properly. So that is the next test.

I'll keep you updated on the parts and I should have some picture progress to follow quite soon.

The Intuitive Interface

So what is this all about then?  Well this blog charts the progress of my efforts to find a solution to the problem of interface design in computer game studio development pipelines.  What are those?  Well computer games or video games, are made up of a series of creational steps, or building blocks.  These make up the pipeline.  To broadly summarize them, you could say they're, pre-alpha or concept design, alpha development, beta development and release.  But this summary doesn't really point out all the key areas.

What I am trying to do is build a device modeled on Multi Touch Screens like this one (Multi Touch), and then attempt to prove the hypothesis that an organic (Off the cuff, no rigid structure or thought process) intuitive interface such as this one, would allow developers enhanced modes of function, when designing games.  Like doodling in real time and playing back quick animated scenes, adding video, pictures and sound from a hard drive or external storage location to prototype ideas.  There are in short, many many things you can do with the software.  I have to thank the people at Openframeworks because they're the people who developed the software under the LGPL 3.0 license, which means it's free to use, but there are catches further down the line, though I think these only apply to rigid commercial bodies.  Everything runs on a very simple C++ shell called Code::Blocks, though it will run on others as well and so the solution is cost effective (Even if the hardware might not be!!)

So I will be updating this blog hopefully every day with updates about what's going on, until then, happy reading!

Dominic Took