Home Page Forums MAME MAME How does the hardware of vector-games work?

I'm not so sure about having a device specifically for "analog" vector monitors, as to do so would effectively be making some broad assumptions about the behavior of such monitors. Specifically, it would seem to imply that all vector monitors driven by some sort of analog timing circuit behave the same, and I doubt that that is in fact the case.

The circuitry for handling the deflection is something that I feel would be better off being handled on a per-driver basis, because such circuitry would likely be unique to a given machine and not easily made generic.

In the case of the Vectrex, for example, I feel that in an ideal case, the driver would use the netlist system to emulate the analog components attached to its DACs, and then from the output of the netlist circuitry, pass along the appropriately time-stamped vectors to the core vector rendering system.

Also, for the record, my proposal in that issue will not get us "proper" vectors, it is just one step of several in that direction. I will be writing up separate issues for all of the individual steps necessary to get proper vector rendering.

Makes sense. The beam, deflection principles and different types of phosphor however are entities in all CRT devices but the circuitry interfacing to the surrounding world can differ a lot.

A VGA monitor would have a sweep generator and expects sync pulses and such but also the ID0 to ID3 and later DDC lines for monitor detection.

A TV would have an RF input and many consoles and home computers had an RF modulator either build in or as an accessory.

Going further into the TV world there are numbers of special schemes involving serial protocols in the SCART connector and later in the HDMI connector, not to mention the VBI lines with Closed Caption and Teletext information as well as copyright, macrovison and WSS signalling. All these features requires intelligence in the display device for OSD etc. and they eventually included an MCU to deal with all this long before SmartTV become a thing.

I think we could view the display device as something that may be emulated more exactly at some point and there are certainly ROM:s to be dumped and PCB:s to be described in these as well. They should be a slot device as much as anything else in MAME imvho.

Vectrex happens to be one of the oddballs here, and possibly many of the arcade games too, where the machine and the display is tightly integrated.

But I like to keep it simple too

First, this new answers are all very interesting and may are the most accurate way i can think of, to reach proper simulation of vector monitors. Sadly this is beyond of any possibilty to help you or others from my side .

Long before i did start this thread, i had a nice discussion on a arcade-convention with guys that owned the originals at their homes and man-caves. We discussed what MAME could do, to improve the appearance of vector-games. Obviously the first thing, was the mimic of the beam and the phosphors, but it also was the first thing what we know, it would be very difficult to do, till the point "maybe impossible with satisfying results". So we focused on other things, that maybe could be done, with less effort.

These things came out:

1. seeing the points from drawn lines. (you could do this even with old HLSL, but the picture would be very dark, with unnatural thin lines) it would look like this:


With the latest changes from Jezze, it is possible to show the points more clearly and with enough brightness. I now have more the problem, to show them colored for colored games (i.e. a bright red point for a red line). Everything is fine with b/w games.


2. A glow that doesnt look to "artificial". You can see a good example of what i mean, if you look at the deathstar explosion of Starwars. The glow should have a circle/donut form, but looks more hexagonal instead.



3. Some "wobble/shake" filter to mimic the "stable" screen of vector games. This gets really extreme on the cheap hardware of a Vectrex. Just watch this video at 15min. : https://www.youtube.com/watch?v=12juB-ySTWo
See how the whole screen/playfield is shaking ? It gets even worse with Clean Sweep. Same stuff happens with the arcade stuff, but way less and not to that degree.

I am not sure, but such a filter could maybe also help the phosphor filter. It seems that the phosphor filter applies only to objects in motion (ok, obvious), but it has downsides for some cases. If you look at the scrolling text in StarWars and use some higher phosphor settings (0.60-0.80), you will see that the phosphor effect turns off, at the moment where the text comes to halt. This looks very strange and i guess it wouldnt look so strange, if we would have a wobble/shake filter, as the text would be still in "little" motion and the phosphor filter wouldnt stop working abruptly.

StarWars Logo with no motion:


StarWars Logo, with motion:


All the images here, are already scaled down and not full quality (i.e. you barely see the shadowmask etc.), but i hope they are good enough, to explain the examples properly .

The Death Star explosion *is* visibly hexagonal on hardware, which makes perfect sense given how vector games work

I actually have no well-founded knowledge about vector monitors, but I had a look into the vector renderer and made some visual improvements (#432) that you might enjoy.


I removed a multiplication of the alpha by 2.0 in the vector shader, which made the lines above an intensity of 127 (alpha of 0.5) completely in-transparent and therefore full white/r/g/b. I don't know about the initial intention of this multiplication, but unless a non-normalized floating point texture is used the sampling will always return ARGB values in a range of [0.0; 1.0].


This is still the case. However, I've changed a point to be no longer a zero-length line but a line with the length of the half beam width, which makes the line look like a square instead of a flat rectangle. This admittedly is some kind of hack-ish workaround until a more suitable solution would be implemented.


I came to the idea that the intensity of a beam should not only affect its brightens but also its width. So I defined the beam width by a linear slope between a configurable minimum and maximum and the actual beam intensity. An optional exponential factor weights greater intensities more than lesser intensities. I'm not sure if this is the right approach, but the results of the post processing speak for themselves.


Here is a comparison of the changes.




Here another example of Star Wars. (starwars.ini)


(click to enlarge)

I made a very small change to vector renderer and would like to know what you think about.

This is how vectors look currently. (oversized beam width to better show the difference)



And this is how vectors look after my small change; especially the junctions of the vectors.

The beam shouldn't be so sharp and square - it doesn't look realistic at all either way.

You're right and I absolutely understand, that the vector renderer does not produces a realistic rendering with or without these changes.

Furthermore I think that a realistic rendering can not be achieved with simple polygons to draw lines, but this is how it currently works. And I try to improve what currently works.

So for now it is out of question if it looks realistic. The question is does it appear more correct than before?

Realistic vector rendering will need everyone to have HDR monitors, so it's a ways off yet.

Or real vector monitors.... :-)