Difference between revisions of "Nodal geometry"
m |
m (Caretaker: categories, headings) |
||
| Line 1: | Line 1: | ||
| − | [[Category:Glossary]][[Category:Interface]][[Category:Nodal Concepts | + | [[Category:Glossary]][[Category:Interface]][[Category:Nodal Concepts]] |
At this stage the conceptual structure of the project's interface is a 2D layer model, where layers are stacked in z-order and can exhibit transparency. | At this stage the conceptual structure of the project's interface is a 2D layer model, where layers are stacked in z-order and can exhibit transparency. | ||
| − | ==OpenGL== | + | |
| + | == OpenGL == | ||
Layers are arranged as nested data structures allowing each to be composed from a list of ''n'' child layers. The position and clipping area of a child layer are governed by its parent. The interface uses [[SDL]]'s [[Wikipedia:OpenGL|OpenGL]] context for final rendered output, but composes the root-child layers into surfaces and then transfers the surfaces to OpenGL textures. | Layers are arranged as nested data structures allowing each to be composed from a list of ''n'' child layers. The position and clipping area of a child layer are governed by its parent. The interface uses [[SDL]]'s [[Wikipedia:OpenGL|OpenGL]] context for final rendered output, but composes the root-child layers into surfaces and then transfers the surfaces to OpenGL textures. | ||
| − | ==Textures== | + | |
| + | == 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 ''[[Wikipedia:Sprites|sprites]]''. | 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 ''[[Wikipedia:Sprites|sprites]]''. | ||
| − | ==Nodal reduction== | + | |
| + | == Nodal reduction == | ||
The root-level layers are hooked into the reduction loop permanently, and they in turn hook in various children (based on redraw or collision queries) or metrics updates which must be resolved: these queries are guaranteed to be resolved by the end of the frame. The queries exhibit workflow and so are passed around amongst the nodes to be processed, and passed on again until resolved. | The root-level layers are hooked into the reduction loop permanently, and they in turn hook in various children (based on redraw or collision queries) or metrics updates which must be resolved: these queries are guaranteed to be resolved by the end of the frame. The queries exhibit workflow and so are passed around amongst the nodes to be processed, and passed on again until resolved. | ||
<table class='expandable' title='Technical details'> | <table class='expandable' title='Technical details'> | ||
| Line 13: | Line 16: | ||
*If sprite invalid, render background colour and or bg image | *If sprite invalid, render background colour and or bg image | ||
*If collision query, calculate and pass on if unresolved | *If collision query, calculate and pass on if unresolved | ||
| − | ==Sprites== | + | |
| + | == Sprites == | ||
:''Sprites are runtime caches, device specific and represented non-nodally (as a '''spriteInfo struct''' in [[interface.c]], or a '''symbol''' in [[peer.as]])'' | :''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]] | *in [[interface.h]] | ||
| Line 42: | Line 46: | ||
</table> | </table> | ||
| − | ==Collision and Blitting== | + | == Collision and Blitting == |
[[w:bit blit|Bit blitting]] is the low-level method of building [[w:Sprite (computer graphics)|sprite]] functionality. The details of blitting aren't currently necessary since our two first target interface environments are [[w:OpenGL|OpenGL]] and [[w:SWF|SWF]] which both include sprite-like functionality. | [[w:bit blit|Bit blitting]] is the low-level method of building [[w:Sprite (computer graphics)|sprite]] functionality. The details of blitting aren't currently necessary since our two first target interface environments are [[w:OpenGL|OpenGL]] and [[w:SWF|SWF]] which both include sprite-like functionality. | ||
| Line 49: | Line 53: | ||
Both blitting and collision detection are similar processes and are both [[nodal workflow]]s which propagate amongst children and siblings in the [[current loop]]s of a [[node space]] until resolved. There's no actual movement involved in this "passing around" process though, because its all achieved by adjusting [[node references|references]] to the workflow node, not manipulating the workflow itself. The workflow is guarunteed to be resolved by the end of the frame. | Both blitting and collision detection are similar processes and are both [[nodal workflow]]s which propagate amongst children and siblings in the [[current loop]]s of a [[node space]] until resolved. There's no actual movement involved in this "passing around" process though, because its all achieved by adjusting [[node references|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== | + | == 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 [[w:collision detection|collision detection]] issue which although modelled nodally (so that execution recursion can be shared amongst recursive processes), it is essentially just the usual [[Wikipedia:Octree|Octree]] method. | 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 [[w:collision detection|collision detection]] issue which although modelled nodally (so that execution recursion can be shared amongst recursive processes), it is essentially just the usual [[Wikipedia:Octree|Octree]] method. | ||
Revision as of 17:27, 10 November 2006
At this stage the conceptual structure of the project's interface is a 2D layer model, where layers are stacked in z-order and can exhibit transparency.
OpenGL
Layers are arranged as nested data structures allowing each to be composed from a list of n child layers. The position and clipping area of a child layer are 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.
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.
Nodal reduction
The root-level layers are hooked into the reduction loop permanently, and they in turn hook in various children (based on redraw or collision queries) or metrics updates which must be resolved: these queries are guaranteed to be resolved by the end of the frame. The queries exhibit workflow and so are passed around amongst the nodes to be processed, and passed on again until resolved.
|
Each layer receives a quantum and does the following single operations set (considered reasonably atomic):
Sprites
typedef struct {
int x,y,w,h,t;
double scale,rotation;
Uint32 fill;
GLuint texture;
} spriteInfo;
|
Collision and Blitting
Bit blitting is the low-level method of building sprite functionality. The details of blitting aren't currently necessary since our two first target interface environments are OpenGL and SWF which both include sprite-like functionality.
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)
