eyeGT is written in C++ thus its logic and operations are heavily based on the Object Oriented (OO) paradigm. Unlike most other graphic libraries, eyeGT provides a monolithic access to the whole library, the application doesn’t have to deal with objects allocation and freeing, saving pointers etc. as eyeGT itself will perform these operations when needed. The advantages of such architecture are multifold:

• Reduced memory fragmentation: eyeGT allocates a chunk of memory and uses it as a pool to allocate objects in it, performing housekeeping (garbage collection) when required. This alone guarantees that your application will never experience memory leakages owing to unreleased objects.
• Better control over memory allocation: objects are instantiated only when required and released when no longer needed. The application doesn’t have to worry about when to release memory, eyeGT will do it when most appropriate, without degrading the performance of the application.
• Reduce time to develop: programmer doesn’t need to debug the graphic library, Barefoot Software using the latest technologies in problem tracking and solving did the job already, so you can concentrate on the architecture of your application instead of solving other libraries’ problems.
• Portability: whatever the platform, processor and quantity of memory are, eyeGT can be ported to it; a C++ compiler is the only needed tool. eyeGT doesn’t uses RTTI and exceptions, as most embedded systems C++ compilers do not support them; extensive error description is returned by each API to allow for problems easy pinpointing. In case of any error, the application will never crash owing to eyeGT inability to handle an error; this is a very stringent and at the same time basic requirement for any technology that is mean to use in a production environment that can put life at risk like: airplanes displays, life maintenance machines or nuclear facilities.

The OO paradigm of eyeGT is not only used internally by the code but it is extended to all the operations and services that an application may require from it. In most of the other graphical libraries or toolkits, the application has to have total control over the drawing process: it has to call the appropriate method in the correct order with the right timing and has to respond to a series of messages coming from the hosting operating system to correctly display graphical elements. There is no way of storing graphical objects in a OO manner within the library itself and just instructing them to repaint themselves when they need to be updated. With such a scheme even simple effects like making a blinking object will turn quickly into a daunting task. Even if lately some libraries have appeared on the market (like GDI+ and others) they require an enormous quantity of resources to run and cannot be ported to embedded systems.

eyeGT takes a completely different approach:

The application no longer has access the drawing surface directly, in order to visualize something on the screen the application needs to create a visual object (like an eyeGT shape), place some drawing commands on it and finally place the shape on the screen. eyeGT uses a dictionary based system (Particle Dictionary) to keep track of every particle (shape, sound, container, button etc) created by the user application.

When a method to place a particle is invoked (i.e. egtPlaceParticleInstance), eyeGT put an instance of the selected particle in the canvas; actually, the instance is placed in the Display List and when the latter is processed using the egtProcessDisplayList method the resulting shape is drawn on the canvas.

Think about the Particle Dictionary as a list of class templates and when a particle is placed on the canvas eyeGT creates an instance of that template as in the diagram below:

Of course it is possible to place many instances of a particle on the canvas, as below:

Particle Dictionary

Concept of particle

eyeGT uses Particles and Instances of particles to perform its operation. A particle is a visible (or in certain cases not visible) ‘template’ that defines a certain object; all the particles are stored in a list known as the Particle Dictionary handled transparently by eyeGT itself. For example: a shape particle is an object template that contains drawing instruction like egtLineTo or egtQuadricCurveTo issued in a fashion  that represents, always for example, a square. Creating a particle does not mean making something visible on the screen, but merely defining its ‘template’, ‘model’ or in eyeGT parlor a ‘particle’.  To show the defined particle in the canvas, it is necessary to call the egtPlaceParticleInstance function; to give some C++ parallelism: as it is possible to create many instances (objects) of a given C++ class and change values of its members (properties), in eyeGT it is possible to call the egtPlaceParticleInstance function several times for the same particle and then modify the visual appearance (properties) of any of the instances independently from each other.

To each particle in the Particle Dictionary is assigned a unique ID. The ID is a non-signed two bytes numerical value that ranges from1 to 65,535; the value 0 is reserved by eyeGT to hold a special particle, the root particle, as discussed in the next chapter. The application may choose the ID assigned to each particle as it wishes; note that the ID is a mere identifier for the particle, so particlea that have a lesser ID number (i.e.: 10) have no special attributes (like display priority for example) when compared to other particle that have bigger ID values (i.e.: 100).

Being unique, two particles cannot have the same ID, if for some reason the application need to have a particle with an ID already being using by another particle (even of a different type), it needs to free the other particle by calling the egtReleaseParticle method and then create the new particle with the same ID. Given the limitation above, an application may define up to 65,535 different particles, but the number of instances is actually unlimited. Note that the maximum number of particle is dictated by the limitations of the system hosting the application, like memory availability, more than the range limit of the ID itself.

Particle memory allocation

When creating a particle, the system automatically reserve memory to contain it; sometime, particles require defining data to be passed as creation time, like the binary definition of a shape loaded from a disk file, as in the code below:

egtLoadShape(eyeGTCanvas, pidREDRECTANGLE, lpData, Data, true);

when this line gets executed, eyeGT will attempt to create a shape particle, assign to it the ID represented by the enum pidREDRECTANGLE (i.e.: 100) and copy the data contained in the buffer pointed by lpData into its own internal buffer. This way of operating may create some problems when dealing with devices with limited memory, as at one time there are two copies of the same data in memory. To override this situation, eyeGT provides the CopyData parameters on all the data loading functions like egtLoadShape, egtLoadFont etc. If false is specified for CopyData, eyeGT will NOT copy the data in the lpData buffer, but will save a pointer to the data itself, so the application has the responsibility of allocating and preserving the block of memory until eyeGT will need it. The memory block can be released when the particle is not being currently used (i.e.: a shape particle displayed or a sound particle being played) and has been removed from the Particle Dictionary using the egtReleaseParticle method. If true will be specified for CopyData, the application may free the buffer pointed by lpData as soon after the data loading functions have been executed.

Ok, so if I tell you that eyeGT + b.Tween will make it possible to port Flash and FlashLite content to the iPhone/iPod Touch as native applications, you don’t need any more explanation right?

Maybe not, judging from the huge number of emails I’m getting and the posts I read on the various blogs.

The lack of information is completely our fault however….. until today Barefoot Software has been dealing almost exclusively with telecoms and handset manufacturers to deploy custom applications on mobile platforms. We have never had to explain too much detail on our website as executives generally don’t know how to use a web browser right?…. Just kidding of course!!!

Everything started with a very cool application made by Thomas Joos of Boulevart, a mobile guide to the Rock Wechter concert that will take place in Belgium from the 3rd to the 6th of July. Thomas designed and created the original Flash Lite version running on Nokia phones. Using b.Tween it has quickly been adapted and compiled by Barefoot - directly from the Flash Lite version into an iPhone/iPod Touch native application…. we were supposed to just briefly touch on the b.Tween process in this blog as for the moment our main web site is not yet ready to be assaulted by flash and iPhone enthusiasts but Thomas could not resist [bless his soul] and things are now moving very quickly….

What is eyeGT? (short for “Enhance Your Experience - Graphical Toolkit”) - this is explained in the post below but as a short summary: “eyeGT is a highly efficient graphic renderer, capable of handling vector graphics and bitmaps. Beside the basic services of rendering, eyeGT provides a very extensive API that allow to define: buttons, animations, hierarchical containers, color and special effects, static text, editable fields and much more; think about it as a Windows GDI+ or Mac OSX Quartz2D on steroids, heavily optimized and designed from the ground up … for mobile.”

You may have heard a lot about of other toolkits available that perform similar sorts of things on desktop PCs (my favourite is AntiGrain) but eyeGT is very different and not only in terms of speed.

eyeGT is completely self contained. It does not use 3rd party code like FreeType for fonts (like AntiGrain) and offers a “flat” interface to developers: it never returns pointer to objects, requires you to setup complex classes or intricate design scheme. It is impossible to create applications with eyeGT that have memory leaks or crashes (this is a big claim…… I know, but let’s just say that you really have to apply yourself to crash an eyeGT based app).

• eyeGT comes in the form of a single DLL, Shared Object or FrameWork depending on the platform. [by the way we support many other platforms - not just iPhone/iPod Touch
• Nokia 2nd Edition (6600, 6680, 6630 etc)
• Nokia 3rd Edition (whole range including Feature Pack 1 & 2 models)
• Sony Ericsson UIQ2.x e UIQ3.x (including P800, P900, P910i, P990, W850, W950, W960, P1 and others)
• Motorola Z8 e Z10
• Microsoft Windows Mobile (every smartphone and PDA based on Windows Mobile 5, 6, 6.1 e 6.1 Pro)
• Apple iPhone e iPod Touch
• Nintendo DS (original and Lite)
• Sony PlayStation Portable
• GamePark’s GP2X F100
• Many phone models based on MontaVista Linux and is available to be ported on other embedded platforms as the base requirements are very minimal.

What eyeGT is NOT..

NOTE:: eyeGT is NOT a Flash compatible player or Virtual Machine. It doesn’t pickup a SWF file and “play” it.

Not making it as a “player” was a design decision we took over 8 years ago when we first produced our graphical engine designed to display vector nautical chart with quite stringent constraints: 256 KB ram and 33 MHz processor (I can hear somebody laughing..).
Over the years eyeGT has evolved and scaled considerably without compromising speed and quality and although we had more than a few request in the past to implement a sort of integrated scripting engine, and although we generally liked the idea, we resisted doing it. The reason is simple: when an application is written for a player or VM, it is effectively “trapped” inside the environment and has no possibility of accessing the outer world. Sure it is possible to expand the player with new capabilities to provide those services from within the player - but only VM producers can do it. This solution is also very painful to maintain across all supported devices and unless you can invest in making a JIT compiler, the scripting language can be very slow. Further more, the player already needs to be present on the hosting platform before your app can be deployed and be able to be executed can be problematic to have different versions of the same runtime installed in the same device. That’s exactly what we wanted to avoid at all cost.
Given our long experience in the mobile field, we have noticed that the vast majority of code that makes up an application is GUI related code and that code is NOT portable. So, as you may guess, our intuition was: what if we have something that can leverage and abstract GUI code, making it portable across various embedded systems and we can produce fully native and fast applications without compromising with the typical problem of “closed” player solutions? eyeGT was born!

Does Flash play any role into our application design/making process? Absolutely! We generally start by sketching up the app following customer requirements using Flash, we then produce a quick mockup right on the handset showing the look & feel and some basic interactivity. The application is then refined, tested and the the Flash content is translated into resources that eyeGT can use; finally the logic of the application is coded in C++. Simply put - by following some simple rules we are able to keep the application “platform independent” - so while we don’t enjoy the only theoretical “Write Once Run Anywhere”, we properly enjoy a model of “write once - compile many and deploy everywhere”!

The final application is then packaged, eventually signed and released with no dependency whatsoever. EyeGT is so small that it can be deployed along with the application and the user is unaware of its presence. We put your brand forward not ours…

The first real test was in 2006 when Nokia was looking for an application capable of downloading and displaying so called "e-zines" or "mobile magazines" for their platform; I wont list here their requirements but trust me when I say they were VERY stringent. Together with PocketNET of Taiwan, a cross project between major magazine publishers likes Condé Nast, Financial Times, Vogue, GQ [and many others] and Nokia itself, the PocketBook Store saw the light only a few weeks after its design. The application has been released pre-installed not only on the original phone model it was designed for (Nokia N73) but also every Symbian 3rd and 2nd Edition phone that Nokia has released since then in Taiwan, with very minimal changes only dictated by the ever changing Symbian Signed criteria [more on this later]. For the official presentation over 200 journalists from all over China were invited to the press conference organized by Nokia itself; it was a very exciting time for us and a final verification that eyeGT is a very really solid and sound concept.

So what b.Tween has to do with all?

Even if eyeGT relieves a lot of the pain of coding the GUI by hand and then porting it across many devices, we felt that something was still missing. Quite a few developers that worked with us and eyeGT agreed that while it was great, there was not enough abstraction between GUI related code and the underlying “business logic” code. We then took the chance of designing a framework on top of eyeGT that could further enhance it. By this time Flash 9 was announced with support for ActionScript 3. This new version of AS was much closer to a full OO language and the underlying framework of classes was more or less what we were looking to do on our own. In the mean time Flash developers habits were changing also. Flash Developers were less and less relying on the ‘classic’ Flash timeline to make animations and applications using the infamous quantity of GotoAndPlay() and Stop() statements plastered throughout the movie and moved more to the scripting language to manipulate the appearance and GUI. So the idea was to recreate more or less the underling framework of AS3 in C++ and use eyeGT as the final renderer for the application. This model immediately provided several notable advantages:

• The code that uses the framework is compiled to machine code, this means performance several orders of magnitude faster than the ActionScript equivalent. (AS3 in Flash 9 is JIT compiled but we are talking about mobile platforms here where there is NO AS3 and no JIT compilation.. certainly for the moment at least)
• Parts of the code that are unused are left out of the final compiled application so size and time to transmit/load are reduced to a minimum
• Native code can access ANY feature of the hosting platform: need Bluetooth? Want to process received SMS? Want to read the phone book? This is all possible from native applications BUT not so from a player based version.

Simply put - b.Tween sits between eyeGT and the application’s business logic and provided for the rapid converting of AS3 based applications into native applications with minimal changes.

There is a lot more to document - and in future posts later this week I will explain how the process actually works. i.e. how we move from a Flash/FlashLite application to a native iPhone application.

When I started to look at the gaming handheld field, the first device I came across has been the Nintendo DS. From a games prospective I’m not an expert, actually not even a player so I can’t comment on the quality of the gaming software, what I was looking for was the ability of producing software that could transform this device in something more than “just” hardware to run games; in fact even Nintendo packs it by default with a wireless chat program called Pictochat. Unfortunately while I found the touch screen a neat addition to the system, the lack of any storage media (without external add-ons at least), incompatible WiFi with actual standards quickly pointed out that I could not achieve many of the things we generally look for in an embedded system. In many other blogs and forums with focus on the current trends in handheld devices, I quite often come across discussions on which of the two is longer, faster and better but I should say the programmability of the Sony PSP is quite superior not to mention the fact that is totally open to expandability whether this is memory or a GPS sensor, keyboard and other.
 

The Sony Play Station Portable (PSP)

Beside this, the processor of the PSP is very fast as well as the graphics and audio subsystems which are working very harmoniously together to spit out very nice performance. Of course without a license from Sony there is no way you can produce software for it, the so called “homebrew”. That hold true until some very cleaver guys started to hack and patch the GGC to produce code for the Allegrex MIPS processor that power the PSP and some other (or probably the same people) actually build a PSP SDK from scratch by reverse engineering the system. I believe that some similarities between the PSP and the PS2 actually helped the creation of the SDK. You can find everything on the PS2 Developer Forums at [Just a little note: don't go there if you are looking for cracks, hacks, copied games and so on, they do not really tolerate those kind of things.....]

The only real limitation is that in order to be able to run homebrew software you need to have a PSP with firmware version 1.0 or 1.5 which have some security holes that make possible to run unsigned code on the system, something that is not possible with later firmware revisions (like 1.51, 1.52 or the latest one 2.0).

So after downloading and installing the SDK (which runs under Linux or Cygwin) I was able to port the entire eyeGT platform is less than 1 week (including running the over 200 regression tests that come with the suite) and the first demo was ready in about half hour.

Very impressive, I never saw eyeGT running so fast in any other embedded system, especially considering that the port doesn’t currently include any specific PSP optimization either at system levels or processor level.

A few demos will come in the next few days.

You probably want to know what eyeGT is all about as it is going to be mentioned quite often in this blog; I have to deal with eyeGT on a daily basis and I can tell you one thing: it is fun!

eyeGT is the first display and rendering system and application platform for embedded hardware that has been designed from the ground up to deliver superior display quality and interaction. It provides a high level and intuitive API to control and customize all aspects of the final rendering as well as being totally independent from the underlying hardware and software layer. Finally, it is very, very small and very, very fast.

eyeGT’s revolutionary approach to graphics for embedded systems allows engineers to treat the display as an advanced and sophisticated canvas where graphical data is arranged in independent and/or correlated shapes and organized into prioritized layers. eyeGT allows total control over the way shapes and layers are transformed (rotation, translation, skewing and scaling) and displayed (normal, translucent, alpha channels etc).

IntelliShape™ technology allows shapes to decide for themselves how they are to be displayed on the canvas depending on user defined parameters like zoom factor, position, user selection etc. It is possible to create, delete and rearrange the contents of a particular layer, its properties, display priority and even the ability to temporary hide layers at any time are also definable thus providing full control of how the application is presented.

A three fold super sampling aliasing reduction algorithm finally allows for the highest display quality achievable. This all comes with the smallest memory footprint knowingly achieved to date - only184KB for the basic modules compiled for a 32 bit processor and just 280KB for the full library including all multimedia support.

eyeGT’s modular design provides the ability to decide which components have to be included i.e. sound (raw and ADCMP compression), editable text, bitmaps, multiple scalable fonts, stroked fonts, automatic animation sequence and much more.

 
A functional diagram of eyeGT

eyeGT was originally conceived to run on very small embedded hardware like the ones that power in-car navigation systems or boat’s chart plotters, so the hardware capabilities were basic: a 56 MHz processor, 256 KB (kilobytes…) of ram and a 8 bit paletizzed screen of 160 x 120 pixels. It is easy to imagine that when ported to currently available hardware the performances of eyeGT literally skyrocketed.

eyeGT uses the concept of a canvas (a rectangular zone of the screen of a given width, height and color depth) in a similar way to some CAD programs: the canvas is basically a container where shapes, containers and other objects, called ‘Particles’ in eyeGT, are positioned and displayed. The application has no direct access to the canvas which is the first big difference with the bitmapped mode of other graphical toolkits. The application places visual particles on the canvas and eyeGT renders them; the application can’t draw directly on the canvas.

In order to visualize something on the screen the application needs to create a shape, place some drawing commands on it and finally place the shape on the screen. eyeGT uses a dictionary based system (Particle Dictionary) to keep track of every particle (shape, sound, container, button etc) created by the user application. When a method to place a particle is invoked (i.e. egtPlaceParticleInstance), eyeGT puts an instance of the selected particle in the Display List. The Display List then gets executed when the user application invokes the egtProcessDisplayList method. At this point eyeGT will process all the particles and render to the canvas the anything that has been modified since the last invocation. It is best to think about the dictionary as a storage place for the particles templates and the Display List as a list of particles templates instances. The application can place the same particle multiple times by invoking multiple egtPlaceParticleInstance and give to each instance of the particle its own specific properties.

 
eyeGT Particle Dictionary and Display List

eyeGT allows the user to modify the Display List at any time as well as altering the particle’s appearance (position, rotation, shear, scale) and properties (alpha, colorization, brightness, visibility) at any time.

End of part one

I want to be more relaxed about my blog, I hope I can post things that can be nice, cool and why not sometimes useful too. My background is programming, I’ve been doing this since I was 14yo and many moons have passed since then. I spend most of my time maintaining a graphical application platform called eyeGT and licensed by my company.
This platform allows us to create some unusually easy to use, pervasive and sophisticate looking interface for any kind of computing device that has some memory, a decently sized CPU (56 Mhz….. yes megahertz) and an LCD screen with a bunch of colored pixels.

We actually use it to power our application and port them to a variety of hardware and embedded platforms, irrespective of the OS and graphical capabilities they have.

This blog will concern about applications, demos, libraries and so on written using eyeGT and running in possibly all platforms we currently support. Don’t worry; it is going to be fun…..

Since all work and no play makes Jack a dull boy, I will feel free to post anything else beside programming as well, whether this include special achievements (like homebrew beer) or the new high percentage caffeine chocolate block just launched on the market.

Hope you will like it and never mind to post your comments to anything you see here.

Cheers,
Emanuele Cipolloni aka Blinky