-
Hello,
Wanted drawing some vector graphics on X-Y CRT screen, so I was thinking about how to achieve a constant drawing speed, while drawing vector graphics at an XY display screen (such as osmelloscope). Constant drawing speed should achieve uniform brightness of the whole screen.
After reading about opamp slew rate limiters in TIDU026 application note, I came up with the idea below. Thought how smart that was, with even the two-transistor detector of "finished drawing stroke" to initiate a next point to draw... and then the reality struck - this will not work, at XY mode, where the speed is the vector sum of the speeds of X and Y components. I mean, square root of a sum of both X and Y speeds squared. So to trashbin my smart circuit goes.
It takes different times to travel deltaX and deltaY, or respectively X and Y must travel at different speed to achieve constant speed of the two vector-combined. One would need to estimate the speed of travel for X and Y at the begining of the stroke. Seems not trivial task to do in analog circuits.
So how this could be solved? Using the X and Y DACs to approximate lines at a proper speed would suck, as the lines would be visibly stepped (unles the DACs would have large resolution and high enough samplerate). Low pass filtering or slew limiting the DAC outputs would distort the picture, due to different times required to travel the deltaX and deltaY distance.
I know, that you can easily these days get a FAST microcontroller, heck even an FPGA with fast enough hi-res DACs to do it all in the digital domain, but my thoughts were "back in the 80s or 90s" mode, how it could be done with a simple 8bit DAC and old 8bit MCU. Say an vectorscope accessory addition for an old 8bit system.
With the circuit above, my idea was to use the transistor output to trigger a next "DMA cycle" to feed DACs with next coordinate position and leave the constant speed drawing to analog circuitry to do its magic.
So is there any clever trick, how to deal with this "constant speed" drawing? Was is ever that much of an issue for vector displays, to be solved as a "problem" at all?
//LTSpice sim in the attachment, if you want to play with it. Ignore C1, i was just fooling around with the circuit for a bit.
-
Using two differentiators, two squarers and summing the result gives you the speed-squared, so in theory set up a feedback network to maintain this constant and you've done it - however there is no clear variable to be the driven signal, horizontal lines cannot be driven from the y-signal, vertical lines cannot be driven from the x-signal, so you need a parametric variable to drive this which represents progress. Stability analysis isn't going to be easy.
And how you control the signal rate smoothly without creating noise in the differentiators isn't clear.
So much easier to do in the digital domain by simply using the "distance" between successive samples to set the DACs' next update time. -
Consider the electron beam having x-axis slew rate \$k \Delta_x\$ and y-axis slew rate of \$k \Delta_y\$, such that the rate correction factor \$k \gt 0\$, and the overall velocity is \$1\$, i.e.
$$1 = \sqrt{(k \Delta_x)^2 + (k \Delta_y)^2}$$
The solution is obviously
$$k = \frac{1}{\sqrt{\Delta_x^2 + \Delta_y^2}}$$
If \$-1 \le \Delta_x \le +1\$ and \$-1 \le \Delta_y \le +1\$, then \$\sqrt{1/2} \approx 0.7071 \le k \le 1\$, i.e. at diagonal lines, \$k\$ decreases 30% from what it is in axis-aligned lines.
If we were to generate the slew rates using a direction \$\varphi\$,
$$\begin{aligned}
\Delta_x &= \cos \varphi \\
\Delta_y &= \sin \varphi \\
\end{aligned}$$
then the solution is constant, \$k = 1\$.
If we have a line segment swept from \$(x_0, y_0)\$ at time \$t = 0\$ to \$(x_1, y_1)\$ at time \$t = T\$ at a constant overall velocity of 1, then
$$\frac{\sqrt{(x_1 - x_0)^2 + (y_1 - y_0)^2}}{T} = 1 \quad \iff \quad T = \sqrt{(x_1 - x_0)^2 + (y_1 - y_0)^2} = \frac{1}{k}$$
because the square root is the Euclidean length of the line segment. The slew rates are then
$$\begin{aligned}
\Delta_x &= \frac{x_1 - x_0}{T} \\
\Delta_y &= \frac{y_1 - y_0}{T} \\
\end{aligned} \quad \iff \quad \begin{aligned}
\Delta_x &= \frac{x_1 - x_0}{\sqrt{(x_1 - x_0)^2 + (y_1 - y_0)^2}} \\
\Delta_y &= \frac{y_1 - y_0}{\sqrt{(x_1 - x_0)^2 + (y_1 - y_0)^2}} \\
\end{aligned}$$
or alternatively \$\varphi = \operatorname{atan2}(y_1 - y_0, x_1 - x_0)\$ using the two-argument form of arcus tangent (traditionally calculated using CORDIC). In any case, the electron beam sweep follows \$\tau = t / T\$, \$x = (1-\tau) x_0 + \tau x_1\$, \$y = (1-\tau) y_0 + \tau y_1\$.
Is this necessary? In CRTs, the perceived intensity is not a linear function of the beam dwell time, because of how the phosphorescence works. There is even an absolute maximum above which the intensity changes very little. -
MarkT: I was thinking not about using differentiator, but rather begin with a difference amplifier to obtain deltaX and deltaY at the beginning of the stroke (while holding old XY coordinate position in some kind of sample&hold maybe?), as inputs for calculating speeds and then use an integrator with voltage-controlled time constant. Anyway, this leads to yet another variant of likely over-engineered nonsense.
Nominal Animal: Thank you for the equations. Even though the math is relatively simple, the circuit solution seems anything but simple.
I was thinking, whether there were used any clever tricks back in the old days. If all that they relied upon is the saturable (non-linear) characteristic of the phosphor, then it will probably be fine. Need to try some tests, as I wanted to try some more complex graphics, but god knows when I will have the time to try it in practice. :-/
Guessing, the characteristic of the screen phosphor will also depend a lot on the type of CRT tube, so different may achieve very different result.
-
A few decades back there was an arcade game which I think was called space wars. It had a 19" monochrome vector monitor with a 12 bit Burr-Brown bipolar DAC for vertical and horizontal. The monitors were unreliable because the game computer board would get goofy and force the CRT beam way off center which required huge current in the yoke windings and the deflection circuits would burn up. Also the high voltage flyback (which was not part of any deflection circuit) would also burn out due to poor manufacturing quality control. The flyback driver HAD TO BE a TIP41C. Any generic replacement would get screaming hot in seconds and short out. Anyway, all drawing speeds were controlled by the game board in the digital domain and sent via ribbon cable to the monitor. Due to deflection being electromagnetic there were a lot of constraints on the vector drawing to avoid harmful currents in the yoke. This would not be a problem with electrostatic deflection. Basically, if you are drawing a 1 inch line from point A to Point B it will have the same number of pixels no matter what direction it is drawn in so the step 'rate' remains the same however, with an angular line something less than the 'total' number of steps will be applied to the X axis, something less than the total number of steps applied to the Y axis and in some cases the steps will occur simultaneously and in some cases only the X or the Y will increment (or decrement). B.T.W. the resolution of a 12 bit DAC is better than the resolution of the beam of most C.R.T.'s remembering at 650 lines the lines will overlap each other giving the appearance of no lines / no individual pixels. In other words the line pitch could be .001 inch but the beam diameter could be .002 inch so the lines or individual pixels can't be discerned. Hope this rambling gives some insight. Cheers!
-
Methinks screen (trace) brightness is much less an issue than the distortion of the vector if you're drawing anything other than horizontal (delta Y = 0), vertical (delta X = 0), or 45 degree (delta X = delta Y) lines with the same slew rate for X and Y. For example, suppose delta X is 1 and delta Y is 2. If the two DACs have the same slew rate, the X value will reach its endpoint when Y is only half way to its end point. The result is not the intended straight line.
I've run into this problem myself and don't have an answer, but I'd like to hear one if anyone knows a simple trick
-
Basically, if you are drawing a 1 inch line from point A to Point B it will have the same number of pixels no matter what direction it is drawn in so the step 'rate' remains the same however, with an angular line something less than the 'total' number of steps will be applied to the X axis, something less than the total number of steps applied to the Y axis and in some cases the steps will occur simultaneously and in some cases only the X or the Y will increment (or decrement).
Yes, I did that - made a quick calculation to determine the length of the line and therefore how long it would take to draw. This merely avoids getting a hot spot at the end of the line if you waited the same amount of time for short lines as long ones(*) (and this all assumes that you don't have an interrupt from your DAC when it reaches its terminal value). But you still get distortion.
(*) The slew rate is basically matched to the display, so that it gives a nice visible line on the display. And that's independent of the line length. But then you have to know when the line is complete to control the Z value - again, to avoid a hot spot at the end of the line. -
The slew rate problem can be solved by using a variant of Bresenham's line algorithm, where on each iteration (at maximum slew rate) each axis is incremented or decremented by one.
If you do diagonals (where both axes are incremented or decremented at the same iteration), then the diagonal velocity is \$\sqrt{2} \approx 1.4142\$ times that of the axis-aligned velocity.
If you do not do diagonals, then the diagonal velocity is \$\sqrt{1/2} \approx 0.7071\$ times that of the axis-aligned velocity, and non-axis-aligned lines will appear thicker than axis-aligned lines.
In all cases, that pesky \$\sqrt{2}\$ or its reciprocal, \$1/\sqrt{2} = \sqrt{1/2}\$ raises its head for the diagonal lines.
If we consider how audio potentiometers are implemented typically using just two linear segments concatenated, I think just about any kind of compensation for non-axis-aligned lines would work, if needed at all. I suppose that in vector displays, the beam intensity could easily be adjusted to account for the velocity difference to obtain less than 10% of direction-dependent variance, which ought to be sufficiently imperceptible. For CRT scopes, there is no such control, so controlling the combined slew rate is the only option. Do any such scopes adjust beam intensity depending on deflection rate so that curved signals appear equally bright to a flat signal? The intensity variation does not need to be that big to compensate, just say a quarter of the total power, with minimum when signal is flat, and maximum when signal varies the fastest. A simple differentiator on the beam deflection would suffice, so perhaps some scopes do it; I do not know. -
All my analog oscilloscopes have a Z axis input for beam intensity. It's a simple extension of the blanking circuitry that is otherwise required during beam retrace. It seems like the Z input value could be based on the length of the stroke per unit time, yes?
-
The intensity issue, as well as the distortion issue, goes away (except for possible blanking a the end of the stroke to allow computation or retrieval of the next vector) if slew rate is controllable individually for the X and Y values (either in the DAC or a buffer external to the DAC). I don't see Bresenham's line algorithm being relevant here, as the point is to draw a line from point (X0,Y0) to (X1,Y1) in a single stroke.
The question remains: is there such a thing as a "programmable slew rate" (for lack of a better term) buffer? -
A move of (x,y) should take time t where t =v*d, where d is the distance. So the required X and Y velocities are respectively are simply x/t and y/t, right?
This could all be computed at each point update, and the X and Y component velocities fed into independent slew rate limiters -- or really, programmable fixed-slew-rate buffers. You could also recompute at arbitrary points in the travel by sample-and-holding the current and target positions and computing based on the distance to go. -
The question remains: is there such a thing as a "programmable slew rate" (for lack of a better term) buffer?
Sure. A ramp generator would be a good point of reference: feeding a constant current into a capacitor will generate a fixed rate of change in voltage. Changing the current changes the slope. The difference here is that the starting and ending points are arbitrary, corresponding to the starting and ending coordinates. Essentially you'd just need a two-quadrant programmable current source, where the sign corresponds to the direction and the magnitude corresponds to the desired velocity. -
All my analog oscilloscopes have a Z axis input for beam intensity. It's a simple extension of the blanking circuitry that is otherwise required during beam retrace. It seems like the Z input value could be based on the length of the stroke per unit time, yes?
For constant intensity, yes:
$$Z = Z_0 \sqrt{\Delta_x^2 + \Delta_y^2} = Z_0 \sqrt{(x_1 - x_0)^2 + (y_1 - y_0)^2}$$
where \$Z_0\$ is the intensity at unit length.
For the Bresenham's algorithm variant, you can use axis-aligned steps at \$Z_0\$ and diagonal steps at \$\sqrt{2} Z_0 \approx 1.4142 Z_0\$, or adjust the intensity for the entire line segment as above.
Interestingly, if we want constant intensity for a curve, just use \$\Delta_x\$ for \$x\$-axis slew rate, and \$\Delta_y\$ for \$y\$-axis slew rate.
One interesting approximation would be
$$\sqrt{x^2 + y^2} \approx 0.7071 \lvert x \rvert + 0.7071 \lvert y \rvert + 0.2929 \bigl \lvert \lvert x \rvert - \lvert y \rvert \bigr \rvert$$
which is off by less than 8.24%, and could be implemented using ideal diodes and some opamps. (The coefficients are just \$\sqrt{1/2} \approx 0.7071\$ and \$1-\sqrt{1/2} \approx 0.2929\$, which yield -0% +8.24% relative error bars depending on the direction. The function \$z = \sqrt{x^2 + y^2}\$ is a right circular cone with apex at origin, and the approximation is an octagonal pyramid. What I do wonder is if there are/were CRT-based scopes having this kind of slew-rate-to-intensity auto-adjustment in hardware, since slew rate is just the derivative of the signal; doesn't sound like too many opamps to implement, although me being hobbyist I could easily be wrong about how complex it would be to implement in analog hardware.) -
I know nothing, but I don't remember ever hearing or reading of a scope with automatic brightness adjustment. Maybe I missed it. I do know the 2467 as all about the clever micro-channel plate CRT to make really fast sweeps brighter. I also know all my analog oscilloscopes have brightness knobs right there on the front! Not enough... turn to the right. Too much... Turn left.
I think maybe with Bresenham, and such ideas, it's a bit like walking around the back of the building to come around and go in front door -- extra work to implement a digital algorithm in analog. Sometimes you can do that, but generally, it seems better to find a feedback-based solution that sorta does the "algorithm" in continuous real time, than thinking in discrete steps. Maybe. Sometimes. -
I think maybe with Bresenham, and such ideas, it's a bit like walking around the back of the building to come around and go in front door -- extra work to implement a digital algorithm in analog.
I was thinking more along the lines of an external conditional adder performing the actual stepping, controlling the two DACs, while the processor calculates the constants for the next line segment. Early discrete logic style.
Just like PDM can be generated by a single unsigned integer adder (the output being the carry or overflow bit), a rasterized line can be drawn by using a counter; on carry/overflow, the step is diagonal, and otherwise axis-aligned. If the counter has as many bits as your DAC, it generates correct lines. Essentially, the input to the line-generating DAC is the octant and the counter additive constant. Such a simple circuit can run at much higher frequency than your real processor, as the line-drawing is independent of the processor. (The diagonal step signal could be combined with the beam intensity signal to boost intensity by 20%-40% (to be adjusted in real life) at diagonal steps or so.)
That constant is $$2^N \frac{ \min(\lvert x_1 - x_0\rvert, \lvert y_1 - y_0 \rvert) }{ \max(\lvert x_1 - x_0\rvert, \lvert y_1 - y_0 \rvert)}$$
for an \$N\$-bit unsigned integer adder.generally, it seems better to find a feedback-based solution that sorta does the "algorithm" in continuous real time, than thinking in discrete steps.
Sure; that's exactly how I imagined the beam intensity compensation to be done in practice: if the two input signals are \$x(t)\$ and \$y(t)\$, then
$$Z(t) = Z_0 \left( 0.7071 \left\lvert \frac{d x(t)}{d t} \right\rvert + 0.7071 \left\lvert \frac{d y(t)}{d t} \right\rvert + 0.2929 \biggl\lvert \left\lvert \frac{d x(t)}{d t} \right\rvert - \left\lvert \frac{d y(t)}{d t} \right\rvert \biggr\rvert \right)$$
approximating \$Z_0\$ times the Euclidean 2D slope of the two signals. Assuming the absolute value is taken using an ideal diode circuit (say, an opamp and two diodes), this should only need some opamps, diodes, capacitors, and resistors, I believe. (That is, I think I know how it could be done in theory, but I don't have enough practical experience to say if it would work in practice.) -
Long ago I used the following to simplify the issue in the digital domain (I.e. in TTL)
(Edited for accuracy).
1 realize CRT phosphor persistance is non linear in time e(-something ?) Adjust to suite.
2 you can simply pick the longer component (dx or dy) to approximate the intensity factor, good enough.
3 you can clock the sweep speed with a binary rate multiplier, one for dx, one for dy. I have built this as a student. You need at least twice the D/A resolution for the BRMs to get smooth vectors.
In the analog world maybe something like that can be done. Tektronix never bothered as strokes were tight characters or mostly short lines. Here is a close up of a tek 222 without any compensation, it's OK.
https://groups.io/g/TekScopes/photo/292881/3745625
-
you simply pick the longer component (dx or dy) to approximate the intensity factor, good enough.
Yep. In the mathematical sense, we're approximating \$\sqrt{\Delta_x^2 + \Delta_y^2}\$ here.
\$\max(\lvert\Delta_x\rvert, \lvert\Delta_y\rvert)\$ has relative error bounds -29% +0%. It never exceeds the true Euclidean length; it is always either correct or an underestimate. In math, this is called \$L^\infty\$-distance or maximum norm. This is when we just take the magnitude of the longer axis or faster slew rate.
Edited to add: You can scale the above by \$\sqrt{8}/(1+\sqrt{2}) \approx 1.171573\$ to get symmetric 17% error bounds.
\$\lvert\Delta_x\rvert + \lvert\Delta_y\rvert\$ has relative error bounds -0% +40%. It is always at least the true Euclidean length; either correct or an overestimate. In math, this is called \$L^1\$-distance, 1-norm, Manhattan distance, or taxicab distance. This is when we sum the axis-aligned distances, or the slew rates.
You can scale the above by \$2/(1+\sqrt{2}) \approx 0.82843\$ to get symmetric -17% +17% error bounds. This is then an underestimate when axis-aligned, and overestimate when diagonal.
\$0.7071\lvert\Delta_x\rvert + 0.7071 \lvert\Delta_y\rvert + 0.2929\bigl\lvert \lvert \Delta_x \rvert - \lvert \Delta_y \rvert\bigr\rvert\$ has relative error bounds -0% +8.3%. This is when we calculate a weighted sum of the axis-aligned distances or slew rates and the magnitude of their difference. Using this approximation, constant-distance curves are octagons instead of circles.
\$0.67913\lvert\Delta_x\rvert + 0.67913 \lvert\Delta_y\rvert + 0.28130\bigl\lvert \lvert \Delta_x \rvert - \lvert \Delta_y \rvert\bigr\rvert\$ has relative error bounds -3.96% +3.96%. These coefficients are obtained by shrinking the above approximation a bit to get symmetric error bounds. -
Plus / minus 4% would be an excellent solution, easy enough to implement in a small FPGA.
P.s. I just had to dig out my Jr College book on Taxicab Geometry, E Krause, 1975. There is now much more on the web than in this book. It was eye opening then and 50 years later neet to see how much further its been taken.
-
Bravo, Nominal Animal !!!
Start Page Here: https://www.jmargolin.com/
Then https://www.jmargolin.com/vgens/vgens.htm
Then https://www.jmargolin.com/xy/xymon.htm
https://www.jmargolin.com/uvmath/uvmenu.htm
https://www.jmargolin.com/uvmath/euler.doc
Mr. Margolin's work has helped me over the years, although my work is with moving masses with inertia, Ie Galvanometer Scanners, which use a constant point rate.
"The Secret Life of Vector Monitors" is what you seek, in addition to the beautiful CRT math mentioned above. Mr. Margolin has other vector graphics and vector math related papers on his site.
The old method was a DAC buffered by a strong follower, followed by a timed analog switch for each axis charging a capacitor via a resistor to obtain a more constant velocity of the beam. A second analog switch could "dump" the capacitor charge for a reset. This was used for "Stroke Writing", with a second set of DACS for course positioning if needed. Basically a charging RC sample and hold. The DAC would be updated and switched in again for movement to the next point.
Kind Regards,
Steve -
Is this really worth the trouble?
-
Is this really worth the trouble?
With respect, YES!
Steve -
Is this really worth the trouble?
I don't know. I asked the same question myself, because the light emitted by the phosphorescent surface is not a linear function of the beam intensity or dwell time at all. That is, some variance in the beam intensity or velocity on the surface likely causes much smaller variance in the light emitted.Mr. Margolin has other vector graphics and vector math related papers on his site.
Thanks; I found them very interesting – except for the Euler angles for 3D rotation, which I consider a loaded footgun with a hair trigger loaded with bullets constructed by a gun nut using very unstable explosives.
What I like to use, is either unit quaternions or bivectors; the actual math turns out to be the same in both cases.
The idea is rotation is described by an unit axis vector \$(x, y, z)\$, \$x^2 + y^2 + z^2 = 1\$, and a rotation around that axis by angle \$2\varphi\$, using four variables:
$$w = \cos \varphi, \quad i = x \sin \varphi, \quad j = y \sin \varphi, \quad k = z \sin \varphi$$
This can be described as a versor (unit quaternion) or as a three-dimensional bivector, with \$w^2 + i^2 + j^2 + k^2 = 1\$. You can always divide the four variables by \$\sqrt{w^2 + i^2 + j^2 + k^2}\$ to normalize it to unit length. Unlike with e.g. rotation matrices, this causes no distortion.
No rotation can be described by \$(w=1, i=0, j=0, k=0)\$ (which is recommended to be used when the sum of the squared components is too close to zero when trying to normalize it to unit length).
The inverse of rotation \$(w, i, j ,k)\$ is \$(w, -i, -j, -k)\$ or \$(-w, i, j, k)\$. When \$w\$ is positive, the rotation is less than 180° ("short way around"); when \$w\$ is negative, the rotation is greater than 180° ("long way around"). \$(w, i, j, k)\$ and \$(-w, -i, -j, -k)\$ represent the same orientation; as rotations, they are the two opposite ways of achieving the same orientation by rotating around the same axis.
To rotate an orientation, you apply Hamilton product, with the initial orientation rightmost, and applied rotations progressing to the left. (That is, last rotation is leftmost, initial orientation rightmost.) It is 16 real multiplications and 12 additions or subtractions. If we use \$(w_0, i_0, j_0, k_0)\$ for the orientation, and \$(w_1, i_1, j_1, k_1)\$ for the rotation to be applied to it, the result is
$$\begin{aligned}
w &= w_1 w_0 - i_1 i_0 - j_1 j_0 - k_1 k_0 \\
i &= w_1 i_0 + i_1 w_0 + j_1 k_0 - k_1 j_0 \\
j &= w_1 j_0 - i_1 k_0 + j_1 w_0 + k_1 i_0 \\
k &= w_1 k_0 + i_1 j_0 - j_1 i_0 + k_1 w_0 \\
\end{aligned}$$
If you normalize the final four to unit length before turning it into a matrix, you can chain any number of rotations without any issues, unlike when using matrices (where tiny rounding errors will compound).
To apply a rotation or orientation to 3D points, you normalize the four to unit length, then construct a 3×3 rotation matrix using
$$\mathbf{R} = \left[ \begin{matrix}
1 - 2(j^2 + k^2) & 2(i j - k w) & 2(i k + j w) \\
2(i j + k w) & 1 - 2(i^2 + k^2) & 2(j k - i w) \\
2(i k - j w) & 2(j k + i w) & 1 - 2(i^2 + j^2) \\
\end{matrix}\right]$$
and do matrix-vector multiplication with column vectors on the right side, \$\mathbf{R}\vec{v}\$.
For camera movement and similar, you can interpolate between two versors/bivectors by interpolating the four components, and normalizing the result. It approximates the minimum or maximum rotation path. Let's assume you want to interpolate between two orientations \$(w_0, i_0, j_0, k_0)\$ and \$(w_1, i_1, j_1, k_1)\$. First, choose the minimum rotation path by negating all four components if the \$w\$ component is negative, for both orientations. Then, linearly interpolate the components using \$0 \le \lambda \le 1\$,
$$w = (1-\lambda) w_0 + \lambda w_1, \quad i = (1-\lambda) i_0 + \lambda i_1, \quad j = (1-\lambda) j_0 + \lambda j_1, \quad k = (1-\lambda) k_0 + \lambda k_1$$
and normalize the result. -
Is this really worth the trouble?
With respect, YES!
Thanks. Your experience with it tells me that it probably is.
I was more asking about looking to get as constant a speed as possible, which was the original point and also what Nominal looked to achieve (but he said himself he didn't know if it was worth it).
The solutions you mention, that were used with vector monitors, look simpler and clever.
Now going for complicated real-time calculations for this may look a bit overkill, but it's certainly an interesting challenge, if just that. -
Concerning 3d display calculations back then, I had issues with determining 3d to 2d visibility with random objects in a display list. After calculating all the cross products etc. of a set of polygons, one had to do a search to determine who was ultimately in front and visible. I never found a fast way to do that. Anyway, with modern GPUs using massively fast ray tracing, it's all a moot point now.
-
That's a problem, alright.
The early SGI boxes had big memory cards whose only job was to remember the Z depth of each drawn pixel, and ignore any new ones that were behind. That sorta worked... until the resolutions of nearly-coincident lines exceeded the z-buffer's resolution. Then... you get what you get! Things popping in front or behind as they move. Dynamic jaggies.