Difference between revisions of "Nodal geometry"
m (→Layers) |
m ({{legacy}}) |
||
| Line 1: | Line 1: | ||
| − | [[Category:Completed Milestones|2]][[Category:Glossary]][[Category:Interface]][[Category:Nodal Concepts]] | + | {{legacy}}[[Category:Completed Milestones|2]][[Category:Glossary]][[Category:Interface]][[Category:Nodal Concepts]] |
__NOTOC__ | __NOTOC__ | ||
| − | + | == Layers == | |
| − | = Layers = | ||
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. 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 [[peerd.c]] interface uses [[SDL]]'s [[Wikipedia:OpenGL|OpenGL]] context with an orthographic projection matrix. | 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. 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 [[peerd.c]] interface uses [[SDL]]'s [[Wikipedia:OpenGL|OpenGL]] context with an orthographic projection matrix. | ||
| Line 12: | Line 11: | ||
The next milestone is [[recursive rectangles]] which integrates the [[layer]]s (rectangles) with the [[nodal model]] giving them containment as a (tree of layers), and integrates the mouse input with tree allowing a particular rectangle in the tree to be clicked on. The render method of rectangles and the collision-detection test method for the mouse click are both [[nodal workflow]]s passed around the tree until completed. | The next milestone is [[recursive rectangles]] which integrates the [[layer]]s (rectangles) with the [[nodal model]] giving them containment as a (tree of layers), and integrates the mouse input with tree allowing a particular rectangle in the tree to be clicked on. The render method of rectangles and the collision-detection test method for the mouse click are both [[nodal workflow]]s passed around the tree until completed. | ||
| − | = 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 ''[[w: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 ''[[w: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. | ||
| Line 25: | Line 24: | ||
*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 40: | Line 39: | ||
*tile, next ''(maybe move these into container)'' | *tile, next ''(maybe move these into container)'' | ||
| − | = Container = | + | == Container == |
:''Containers are device-independent nodal structures with no language-specific representation'' | :''Containers are device-independent nodal structures with no language-specific representation'' | ||
*x,y | *x,y | ||
| Line 53: | Line 52: | ||
</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 60: | Line 59: | ||
Both blitting and collision detection are similar processes and are both [[nodal workflow]]s which propagate amongst children and siblings in the [[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 [[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. | ||
| − | = Mouse click event = | + | == Mouse click event == |
When a mouse click is detected by [[communications]], the ''click'' process is hooked into the first child of the [[desktop|desktop node]]. When a click first occurs, the ''recipient'' which should act on it is unknown, so the ''collision workflow'' described above is first resolved which results in a known recipient. If this recipient node has no ''click'' [[association]], then check parent and so on up to [[desktop]]. | When a mouse click is detected by [[communications]], the ''click'' process is hooked into the first child of the [[desktop|desktop node]]. When a click first occurs, the ''recipient'' which should act on it is unknown, so the ''collision workflow'' described above is first resolved which results in a known recipient. If this recipient node has no ''click'' [[association]], then check parent and so on up to [[desktop]]. | ||
| Line 66: | Line 65: | ||
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. | ||
| − | = See also = | + | == See also == |
*[http://www.w3.org/TR/REC-CSS2/box.html Box Model] ''(W3C)'' | *[http://www.w3.org/TR/REC-CSS2/box.html Box Model] ''(W3C)'' | ||
*[[Wikipedia:List of layout engines|Layout Engines]] ''(Wikipedia)'' | *[[Wikipedia:List of layout engines|Layout Engines]] ''(Wikipedia)'' | ||
Revision as of 08:10, 6 June 2007
|
Layers
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. 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 peerd.c interface uses SDL's OpenGL context with an orthographic projection matrix.
This milestone was completed some time back and "retro-fitted" for motivational reasons! It has extended the basic IO functionality up to allow the ordered stacking of rectangular layers which can each exhibit a fill colour and image.
The next milestone is recursive rectangles which integrates the layers (rectangles) with the nodal model giving them containment as a (tree of layers), and integrates the mouse input with tree allowing a particular rectangle in the tree to be clicked on. The render method of rectangles and the collision-detection test method for the mouse click are both nodal workflows passed around the tree until completed.
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;
Container
|
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 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.
Mouse click event
When a mouse click is detected by communications, the click process is hooked into the first child of the desktop node. When a click first occurs, the recipient which should act on it is unknown, so the collision workflow described above is first resolved which results in a known recipient. If this recipient node has no click association, then check parent and so on up to desktop.
Interface 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)
