Has anyone tried outputting the Doom automap to the oscilloscope?

[printz]

Has anyone thought of outputting the Doom automap to the oscilloscope (preferably CRT) on XY mode?

For this to happen I'll probably need to find the commands in the API used by Doom to send data to the COM port...

[Maes]

You'd need to rig the automap code to output X-Y offset voltages, probably through a modified fline_t drawing method in am_draw.c, and also an oscilloscope supporting a "beam off" or intensity input in X-Y mode (not all do).

This would take care of vector stuff with reasonable effort, but you'd need quite a few hacks to also draw the various raster stuff (level names, numerical markers, the status bar itself, messagees etc.) unless you'd be content with "just" a vector display.

[printz]

Just vector is fine, though monochrome pixels sounds interesting, if the bandwidth doesn't grow too high... Only w/ vector gfx would be interesting, if it results in the image quality being dependent on map's complexity.

But there'll have to be a single, continuous line... no pauses allowed, unless it's that "beam off" feature you were talking about...

[Maes]

Yup. Vectrex displays actually had the ability to switch or at least diminish the beam intensity while "jumping" through a void area to draw unconnected shapes. The X-Y mode on normal oscilloscopes normally isn't so flexible.

There was an older thread about some demoscene guys that rigged an oscilloscope to display apparently arbitrary images through its X-Y inputs...nm, here it is:

As you can see, at times they can't conceal the transition beams, however if you scan fast enough in the "voids" and pass the actual stuff you want to draw over multiple times, you can sort of simulate different intensities/hide the transition beams. It helps if you sort of optimize the drawing path so that you minimize "void crossings".

[printz]

Holy cow. And according to the video description, it's without a brightness input.

[Maes]

printz said:

Holy cow. And according to the video description, it's without a brightness input.

Yup. If you force rapid enough voltage changes, you can cause the dot to "skip" without leaving much of a visible trace, but how rapidly you will be able to do it, depends on your signal-generating equipment. The dudes on the vid used two 96 KHz audio signals to drive the display, so the shortest "reaction time" for the dot is about 10.4 us. This also puts a limit on how much detail you can cram in a second (let alone a frame) of driving signal, unless of course you use better hardware and higher bandwidth.

In layman terms, this means that since you can't actually change the beam's power, the more stuff you try to draw and the more you spread over the screen area, the less bright stuff will appear (something that's obvious in the video). Also, redrawing stuff to simulate intensity control will of course cost more time, and you should always calculate the cost of drawing other stuff. TBQH, I don't think the guys in the video worried about intensity at all: they just took it "as is".

E.g. to draw a single line the very least you'll need 10.4 us if using a 96 Khz...now consider how many lines you have to draw in a single frame (let's say 100 for typical maps), and multiply that by 35. It works out to about 36.4 ms @ 96 KHz, which also means that this process should better be totally asynchronous and non-blocking (just like audio output). The maximum possible is about 2700 lines per frame (or 96000 lines per second). It seems like a lot, until you try drawing something like nuts.wad with iddt on....

Also, to keep beam intensity as even as possible, you should draw longer lines with a slower pace, otherwise you'd use the same beam energy for both a very short line and for a very long one, so you should calculate voltage ramps accordingly.

The big obstacle here is not so much the oscilloscope itself, as is the output hardware that you will use (a soundcard is effectively a quite low-bandwidth signal generator, by video standards), and the real-time requirements of the software that will do the driving, unless of course you can throw some vector-drawing hardware in the mix....