23 |
|
|
24 |
Add the following methods to ``VobScene``:: |
Add the following methods to ``VobScene``:: |
25 |
|
|
26 |
/** Clip a rectangle. |
/** Intersect the clipping area with the given cs's "unit square". |
27 |
* This changes the currently clipping area to the intersection |
* This changes the current clipping area to the intersection |
28 |
* of the given rectangle (as interpreted in the given |
* of the old clipping area with the "unit square" of the given |
29 |
* coordinate system) with the old clipping area, and pushes |
* coordinate system, and pushes the old clipping area onto |
30 |
* the old clipping area onto a stack of clipping areas. |
* a stack of clipping areas. |
31 |
* All vobs placed into this VobScene until ``unclip()`` |
* All vobs placed into this VobScene will be rendered |
32 |
* is called will be rendered with the new clipping area. |
* with the new clipping area, until ``unclip()`` is called, |
33 |
|
* restoring the old area. |
34 |
* <p> |
* <p> |
35 |
* The clipping area is the area where graphics are drawn. |
* The clipping area is the area where graphics are drawn. |
36 |
* Note that the stack of clipping areas is a way to |
* Note that the stack of clipping areas is a way to |
37 |
* specify the semantics of this method, and is not required |
* specify the semantics of this method, and is not required |
38 |
* to be implemented through a stack data structure. |
* to be implemented through a stack data structure. |
39 |
*/ |
*/ |
40 |
void clipRect(int cs, float x, float y, float sx, float sh); |
void clip(int cs); |
41 |
|
|
42 |
/** Pop the topmost clipping area off the stack. |
/** Pop the topmost clipping area off the stack. |
43 |
* The last pushed clipping area is popped off the stack and |
* The last pushed clipping area is popped off the stack and |
73 |
to ``VobCoorder``, which has ``GraphicsAPI``-dependent |
to ``VobCoorder``, which has ``GraphicsAPI``-dependent |
74 |
implementations currently? |
implementations currently? |
75 |
|
|
76 |
RESOLVED: They will be directed to ``VobCoorder``, since this |
RESOLVED: They will be directed to ``VobCoorder``, since this |
77 |
results in less changes to the architecture. There will be |
results in less changes to the architecture. There will be |
78 |
``clipRect()`` and ``unclip()`` methods with the same signature |
``clipRect()`` and ``unclip()`` methods with the same signature |
79 |
in ``VobCoorder``. |
in ``VobCoorder``. |
80 |
|
|
81 |
- VobCoorder doesn't know which VobScene it is in, or which VobMap |
- VobCoorder doesn't know which VobScene it is in, or which VobMap |
82 |
it's using. This makes it impossible to implement this functionality |
it's using. This makes it impossible to implement this functionality |
83 |
for OpenGL changing only GLVobCoorder, since the OpenGL state is altered |
for OpenGL changing only GLVobCoorder, since the OpenGL state is altered |
84 |
by placing a new Vob in the VobMap. |
by placing a new Vob in the VobMap. |
85 |
|
|
86 |
|
RESOLVED: The ``VobCoorder`` methods will be passed the ``VobMap``. |
87 |
|
(This is slightly ugly, but having API-specific ``VobScenes`` |
88 |
|
seems uglier.) |
89 |
|
|
90 |
- How deep a stack is allowed / required? This makes a lot of difference |
- How deep a stack is allowed / required? This makes a lot of difference |
91 |
for the OpenGL implementation which has native stacks of fixed depth. |
for the OpenGL implementation which has native stacks of fixed depth. |
92 |
|
|
93 |
|
RESOLVED: Ultimately, stacks should be arbitrarily deep, with GL |
94 |
|
switching to a different implementation method when the native |
95 |
|
stack depth is exceeded. For now, it's acceptable to throw an |
96 |
|
exception if the native stack depth is exceeded. If we run into |
97 |
|
real-life problems with this, that'll be a good time to switch to |
98 |
|
a more advanced system. |
99 |
|
|
100 |
- Should clipping with this method work with nonlinear coordinate systems? |
- Should clipping with this method work with nonlinear coordinate systems? |
101 |
This is a very fundamental issue for OpenGL, since if the answer is no, |
This is a very fundamental issue for OpenGL, since if the answer is no, |
102 |
we can use clip planes and get rid of much unwanted geometry, getting |
we can use clip planes and get rid of much unwanted geometry, getting |
103 |
better performance; otherwise, we need to use stencil and draw everything. |
better performance; otherwise, we need to use stencil and draw everything. |
104 |
|
|
105 |
|
RESOLVED: This method should work with nonlinear coordinate systems. |
106 |
|
This ensures that we can use nonlinear coordinate systems for all |
107 |
|
things we draw in OpenGL. For example, we can put a window into |
108 |
|
a fisheye view without getting problems with clipping used on |
109 |
|
that window. |
110 |
|
|
111 |
|
This method should be safe to use as the general case; it is |
112 |
|
optimizations that should be the special case, used if necessary. |