Nodal geometry

The conceptual structure of the initial interface is a 2D layer model, where layers are stacked in z-order and can exhibit transparency. Layers are arranged as a tree allowing each to be composed from a list of n child layers. The position and clipping area of a layer is governed by its parent.

The interface uses SDL's OpenGL context for final rendered output, but composes the root-child layers into surfaces and then transfers the surfaces to OpenGL textures. Later we'll allow any layer to be cached as a texture, rather than only the layers at the root level. This way processing load would be reduced by utilising the large unused resource of texture memory on the video card - usually around 256MB. These cached layer-composites are 32bit having alpha and are called sprites.

The root level layers are hooked in to the reduction loop permenantly and they in turn hook in various children based on redraw or collision queries or metrics updates which need to be resolved. These queries are guarunteed to be resolved by the end of the frame. These queries exhibit workflow and so are passed around amongst the nodes to be processed and passed on again until resolved.

Each layer receives a quanta and does the following set of operations which is considered reasonably atomic:

• If absolute metrics are invalid, set from state of relative metrics
• If sprite invalid, render background colour and or bg image
• If collision query, calc and pass on if unresolved

Sprite

Sprites are runtime caches, device specific and represented non-nodally (as a spriteInfo struct in interface.c, or a symbol in peer.as)

• in interface.h

typedef struct {
	int x,y,w,h,t;
	double scale,rotation;
	Uint32 fill;
	GLuint texture;
	} spriteInfo;

• x,y,w,h (pixels)
• scale (float)
• rotation (float)
• dynamic (if dynamic, sprite is root of new texture structure at runtime)
• tile, next (maybe move these into container)

Container

Containers are device-independent nodal structures with no language-specific representation

• x,y
• w,h (min,cur,max)
• units (%|px|mm...)
• layout (U|D|L|R|none)
• align (L|R|C|J) - relative to layout direction
• wrap (bool)
• clip (bool)
• fill (colour, alpha)
• sprite

Collision & Blitting

Bit blitting is the low-level method of building sprite functionality if not already included in the environment as it is with OpenGL and SWF.

Collision detection is a means of determining which items rectangular bounds intersect with a given rectangle. Collision detection is used for determining which object should receive mouse-click events, or which objects are encompassed by a selection rectangle.

Both blitting and collision detection are similar processes and are both nodal workflows which propagate amongst children and siblings in the current loops of a node space until resolved. There's no actual movement involved in this "passing around" process though, because its all achieved by adjusting references to the workflow node, not manipulating the workflow itself. The workflow is guarunteed to be resolved by the end of the frame.

Event model

The interface aspects of the event model are handled by Geometry because its oriented around which container exhibits the keyboard input focus, and which containers bounds the mouse pointer is within. So this is essentially a collision detection issue which although modelled nodally (so that execution recursion can be shared amongst recursive processes), it is essentially just the usual Octree method.

---

See also:

• Box Model (W3C)
• Layout Engines (Wikipedia)