[Gzz-commits] gzz/doc/pegboard/1013 PEG_1013.rst

[Benja Fallenstein]

CVSROOT:        /cvsroot/gzz
Module name:    gzz
Changes by:     Benja Fallenstein <address@hidden>      03/03/22 07:35:17

Modified files:
        doc/pegboard/1013: PEG_1013.rst 

Log message:
        resolve issues

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/doc/pegboard/1013/PEG_1013.rst.diff?tr1=1.5&tr2=1.6&r1=text&r2=text

Patches:
Index: gzz/doc/pegboard/1013/PEG_1013.rst
diff -u gzz/doc/pegboard/1013/PEG_1013.rst:1.5 
gzz/doc/pegboard/1013/PEG_1013.rst:1.6
--- gzz/doc/pegboard/1013/PEG_1013.rst:1.5      Sat Dec 14 03:11:33 2002
+++ gzz/doc/pegboard/1013/PEG_1013.rst  Sat Mar 22 07:35:17 2003
@@ -3,8 +3,8 @@
 =============================================================
 
 :Author:       Benja Fallenstein
-:Last-Modified: $Date: 2002/12/14 08:11:33 $
-:Revision:     $Revision: 1.5 $
+:Last-Modified: $Date: 2003/03/22 12:35:17 $
+:Revision:     $Revision: 1.6 $
 :Status:       Current
 
 
@@ -23,20 +23,21 @@
 
 Add the following methods to ``VobScene``::
 
-    /** Clip a rectangle.
-     *  This changes the currently clipping area to the intersection
-     *  of the given rectangle (as interpreted in the given
-     *  coordinate system) with the old clipping area, and pushes
-     *  the old clipping area onto a stack of clipping areas.
-     *  All vobs placed into this VobScene until ``unclip()``
-     *  is called will be rendered with the new clipping area.
+    /** Intersect the clipping area with the given cs's "unit square".
+     *  This changes the current clipping area to the intersection
+     *  of the old clipping area with the "unit square" of the given
+     *  coordinate system, and pushes the old clipping area onto 
+     *  a stack of clipping areas.
+     *  All vobs placed into this VobScene will be rendered
+     *  with the new clipping area, until ``unclip()`` is called,
+     *  restoring the old area.
      *  <p>
      *  The clipping area is the area where graphics are drawn.
      *  Note that the stack of clipping areas is a way to
      *  specify the semantics of this method, and is not required
      *  to be implemented through a stack data structure.
      */
-    void clipRect(int cs, float x, float y, float sx, float sh);
+    void clip(int cs);
     
     /** Pop the topmost clipping area off the stack.
      *  The last pushed clipping area is popped off the stack and
@@ -72,20 +73,40 @@
   to ``VobCoorder``, which has ``GraphicsAPI``-dependent
   implementations currently?
 
-  RESOLVED: They will be directed to ``VobCoorder``, since this
-  results in less changes to the architecture. There will be
-  ``clipRect()`` and ``unclip()`` methods with the same signature
-  in ``VobCoorder``.
+   RESOLVED: They will be directed to ``VobCoorder``, since this
+   results in less changes to the architecture. There will be
+   ``clipRect()`` and ``unclip()`` methods with the same signature
+   in ``VobCoorder``.
 
 - VobCoorder doesn't know which VobScene it is in, or which VobMap
   it's using. This makes it impossible to implement this functionality
   for OpenGL changing only GLVobCoorder, since the OpenGL state is altered
   by placing a new Vob in the VobMap.
 
+   RESOLVED: The ``VobCoorder`` methods will be passed the ``VobMap``.
+   (This is slightly ugly, but having API-specific ``VobScenes``
+   seems uglier.)
+
 - How deep a stack is allowed / required? This makes a lot of difference
   for the OpenGL implementation which has native stacks of fixed depth.
 
+   RESOLVED: Ultimately, stacks should be arbitrarily deep, with GL
+   switching to a different implementation method when the native
+   stack depth is exceeded. For now, it's acceptable to throw an
+   exception if the native stack depth is exceeded. If we run into
+   real-life problems with this, that'll be a good time to switch to
+   a more advanced system.
+
 - Should clipping with this method work with nonlinear coordinate systems?
   This is a very fundamental issue for OpenGL, since if the answer is no,
   we can use clip planes and get rid of much unwanted geometry, getting
   better performance; otherwise, we need to use stencil and draw everything.
+
+   RESOLVED: This method should work with nonlinear coordinate systems.
+   This ensures that we can use nonlinear coordinate systems for all
+   things we draw in OpenGL. For example, we can put a window into
+   a fisheye view without getting problems with clipping used on
+   that window.
+
+   This method should be safe to use as the general case; it is
+   optimizations that should be the special case, used if necessary.
\ No newline at end of file