Ok, no excuses. I should have updated you on my progress earlier...
I have been working on Venus, and progress has actually been really good. I have an initial version of the graphics library created, and have integrated it into TextQuick. This has allowed me to implement some really cool features. - But more about that later.
First, let me tell you about Venus. Based on my last post Venus is based on a set of graphical elements arranged in layers, or by Z order. I place these on top of each other, and draw them in the correct order to create an image in the screen. This basically creates a simple
scene graph representing the image on the screen. Each element or node in the scene graph has a set of common properties. These include everything from the basic, X,Y,Z right down to alpha values, background colours and so on.
Although this allows me to create objects and display them on the screen, it does not allow me to animate them. Let's assume that I want to move an image across the screen horizontally. To do this I need to change the images X position. Using my scene graph, all I need to do is change the X value of the object and image will have appeared to have moved.

The beauty of this approach is its simplicity. The scene render takes care of redrawing the screen, and the object simply appears to have jumped from its original location to the new location.
While this does make things move, it does not provide a sense of animation, or fluid movement. To do this I need to modify the X value from its original position to the new position slowly over a period of time. If I play back these changes it gives a sense of animation, as the image appears to update over time.
If all the nodes within the scene graph have the same basic set of properties, and if these properties can be updated in the same way then it would be possible to easily change, not just one property, but many properties all at the same time. For instance, by changing the X and Y values of the image we can make the image move in a diagonal direction.

Complex animations can now be built up, with one node being manipulated in many ways at the same time. Indeed if there was a way to manipulate multiple properties on multiple objects all at the same time then this would create very complex animations.
Concentrating on AnimationOnce I created the scene graphic render, I concentrated on creating an animation player. Of course no one would want all the objects on the screen at the same time, instead we would need some way to chain together actions or events. Basically to construction a timeline of actions to play back events on the screen. Some of these timeline events we would want to occur at the same time, like changing the X and Y values of the image to create diagonal movement. There are other things however, that we would want to happen sequentially. So for instance the image could move to the top right of the screen and then slide back down the screen.
To support this I created an active object based animator. The animator plays a set of timeline commands, and the commands can be chained together. You can chain the commands together sequentially, so each plays out after the other. Alternatively you can chain the events together simultaneously making them all happen at the same time. Allowing different combinations of these time line commands allows for some really complex behaviour.
I created a
test harness to test Venus. This allowed me to try out some of the base functionality, simple rendering and animation. Of course, after all of the talk of Amiga's and Bitblt operations, I simply had to use an iconic image from the Amiga as the basis of the test harness. The following image is taken directly from the test harness.

This gave me the basic functionality I was after, but of course... there was still more to do.
Multiple ImagesIn any given scene there may be multiple copies of the same image, for instance a collection of stars on a background. To do this with the initial version of Venus would have required the me to load multiple copies of the image, created a scene node for each star. Loading multiple copies of the same image would waste memory, which is something of a limited commodity on a mobile phone. A better approach would be to have each of the nodes refer to a single image, and then have the rendering engine use the same image in many places to create the star field.
To enable this I created a referenced counted image handler within Venus, I called this the ImageBox. Just as a children's toy box contains toys, the imagebox should contain all the images Venus needs to render.
Vector GraphicsNow even with bitmap graphics being displayed there is still the need for some form of Vector graphics. This is really handy on mobile phones when the screen resizes. To support this I created a special vector graphic node within my scene graph. This could contain any number of polygons. The vector graphic node would then render these polygons within it's layer. This provided Venus with vector graphic support.
One of the really powerful things about vector graphics is that they can be resized, and rotated. Both the scaling and the rotation can be exposed as properties of the Vector graphic node. Once I did this I was able to use my animator to animate the contents of the vector graphic node. For instance rotating polygons to produce a spinning wait symbol.
Event NotificationNow that I've got a scene renderer, an animation control, the imagebox, and vector graphic support (phew), I still don't have enough to create the user experience I want. User Interfaces are based on responding to input from users, signals from other parts of the application or other events that are triggered throughout the system. I need the nodes within the scene graph to listen for and respond to events. So the next major development effort was adding support for events, both user generated and system generated. I ensured that each node was capable of receiving and generating events. Events can be signalled between objects, with a source and a destination. They can also be broadcast to a collection of nodes. This now allows the whole user interface to respond to user input!
Basic UI building blocksOk, so now Venus has event notification, a scene renderer, and animation control, the imagebox and vector graphics support... I am still not ready to produce a UI. Typically in a user interface I will need to display textual information to users. To allow me to do this I added a new node, specifically for rendering text. In creating this node I added event handling support, allowing the text node to respond to special events containing text. This way I can generate a special event which will trigger the text node to update and display new text!
This then gave me the basic building blocks of a new user interface.
TextQuickSo back to TextQuick, I integrated my completed Venus graphics library into TextQuick and the first major, rocking, area of functionality I focus on was... (dramatic pause).... the splash screen!
OK, OK, I know the splash screen is hardly a major area of user interface functionality, so let me explain. The splash screen is a fantastic integration experiment, as it would allow me to go to town using the functionality that Venus provides. One of the first versions of the splash screen I implemented is shown below. This also helps to show the majority of Venus' features off. The image below shows the splash screen along with some notes regarding the features that are visible.

This is not the final version of the Splash Screen, as that is still under development. However I do think it shows off some of the basics of what Venus can achieve. In my next blog post I want to cover some of the new features I've added to TextQuick.