Nope MAME can't. Stars still be fully white and everything else won't look like that too. DEV can't pull that off. Pretty hard to do. Beside there no scanlines support for the vector games anyway.
On Asteroids, the shots from the UFO and your ship glow brighter than everything else. This was done by re-drawing the shots on top of themselves. Then it just sort of happens, because vector monitors. Star Wars used the same trick for explosions. I think they called it 'overdrive', which just makes it cooler.
I'm guessing it would be difficult if not impossible to do in an emulator without hooking directly into the game code itself...otherwise how would you know what should glow more and what shouldn't.
Or you could imagine a vector monitor as an emulated device. Like expansion cards for computers in MESS (uh, MAME). I think someone would have to be certifiably insane to take on a task like that and make it work cross-platform.
> On Asteroids, the shots from the UFO and your ship glow brighter than everything > else. This was done by re-drawing the shots on top of themselves. Then it just sort > of happens, because vector monitors. Star Wars used the same trick for explosions. I > think they called it 'overdrive', which just makes it cooler.
Nah it's not a vector monitor thing, just a CRT thing. If you drive a point too hard, electrons will excite the surrounding phosphor in addition to the point you're targeting. Overdrive is the correct terminology, you drive the monitor harder than the maximum that would deliver a sharp image.
> I'm guessing it would be difficult if not impossible to do in an emulator without > hooking directly into the game code itself...otherwise how would you know what should > glow more and what shouldn't.
It's doable, but you'd need a fancy (and probably slow to run) monitor simulation engine.
> > On Asteroids, the shots from the UFO and your ship glow brighter than everything > > else. This was done by re-drawing the shots on top of themselves. Then it just sort > > of happens, because vector monitors. Star Wars used the same trick for explosions. > I > > think they called it 'overdrive', which just makes it cooler. > > Nah it's not a vector monitor thing, just a CRT thing. If you drive a point too hard, > electrons will excite the surrounding phosphor in addition to the point you're > targeting. Overdrive is the correct terminology, you drive the monitor harder than > the maximum that would deliver a sharp image.
I meant compared to a conventional raster display. In my admittedly very limited understanding, a vector monitor draws only dots and the game, or vector generator or whatever, has direct control of the beam or the guns at all times.
I remember reading about a "spotkiller" circuit which does something to the beam so that it doesn't burn a hole in the phosphor? I used to own an Asteroids upright and you could see it in action as you turned the game off and the beam would sort of zinnggg onto the center of the screen, concentrated and bright like the shots and then disappear. I always imagined that that was the "spotkiller".
> I meant compared to a conventional raster display. In my admittedly very limited > understanding, a vector monitor draws only dots and the game, or vector generator or > whatever, has direct control of the beam or the guns at all times.
It's still purely a CRT characteristic. The difference between a vector monitor and a raster monitor is all in the way the beam deflection is controlled. In a raster display you have ramp generators causing it to scan in a fixed pattern. You can still get that glow effect by turning up the drive really high, but you generally wouldn't as it messes up your picture when bright stuff bleeds (or "glows") into the surrounding areas.
> I remember reading about a "spotkiller" circuit which does something to the beam so > that it doesn't burn a hole in the phosphor? I used to own an Asteroids upright and > you could see it in action as you turned the game off and the beam would sort of > zinnggg onto the center of the screen, concentrated and bright like the shots and > then disappear. I always imagined that that was the "spotkiller".
Yes, keeping the beam at a single point for too long will damage the phosphor. You can do this on a raster monitor by disconnecting the horizontal or vertical drive (causing the beam to scan along a single vertical or horizontal line) or both (causing the beam to stay on a single spot in the middle of the monitor). Or the drive circuitry could fail and this could happen without you disconnecting anything.
In a vector monitor, you don't have ramp generators continuously producing a scanning pattern, as you want to trace out arbitrary patterns. In case of a software failure, it could keep the beam switched on and held at a single point or tracing a small area repeatedly. Note that with a vector display this would only require a software failure, not a hardware failure or disconnecting drive electronics.
The spotkiller is supposed to detect cases when the beam is being held in a pattern likely to cause phosphor damage and switch it off in such cases, to help protect your investment.
But at the end of the day, CRTs are pretty much the same whether they're being used for vector or raster display. The ones that are actually different are the radar and oscilloscope displays that use electrostatic rather than electromagnetic beam deflection, and the storage CRTs in some vector terminals with a grid that allows them to "hold on" previously drawn vectors without needing to refresh them.
As far as i know, a Z-amplitude managed the brightness on vector-games like asteroids, starwars etc. (maybe on all of them, i dont know it exactly). My question would be, if MAME emulates this Z-Amplitude too ? If MAME has it, where I could find it, in the code? Would it be in the vector-renderer?
Because I have a idea for making a overdrive-effect, but it needs to be aware of the Z-amplitude. If the whole game, would be filtered through a kind of a broadcast-filter, then we would have some room left for the overdrive. A broadcast-filter converts RGB which has 0-255 steps for brightness, into something that has only 15-230 steps (no pure black and no pure white). So the remaining 15 steps for pure white could be used for the overdrive. If we combine this, with a nice glow, we could achieve some similar effect i guess. But the effect, needs to know when a overdrive happens and i dont know, where to look for it in MAME.
Nearly all the vector stuff that is left un-emulated, like proper (or more visible) point-shading or the overdrive etc. would need effects, that are co-working with the vector-renderer, as they are nearly impossible to do with a post-processing step (at least i cant imagine, how this would be done). I first assumed that points are drawn on each end of a vectorline, but i found out that this was a wrong guess. Only the start of a drawn vectorline has a point and now tell me, how a postprocessing filter would know this, if he processes the final image, where the whole line is allready drawn?
Check out the overlay lines. Close to the real thing. If you mess with the the settings then you will start losing that effect. I guest Battlezone have 3 overlays effect or so.
> As far as i know, a Z-amplitude managed the brightness on vector-games like > asteroids, starwars etc. (maybe on all of them, i dont know it exactly).
I don't know what the hell Z-amplitude is, but the brightness on vector games is simply a factor of how long the beam remained on a given spot, or how often a vector was redrawn compared to other vectors in the same scene. The shots in Asteroids, for example, are exceptionally bright because they're physically drawn more often than the rest of the vectors in the scene.
There was no frame rate per se in vector games, and the way MAME currently emulates vector games lacks the appropriate information for being able to do actual overdriven vectors in a shader. The proper way to handle it would be for the OSD to be made aware of the actual duration of the draw per-vector, and for the vector's brightness to be adjusted in the shader based on that factor. Ideally, this information could be written into a render target as well, so that the bloom shader would be aware of it in order to add extra bloom to vectors that were drawn either slower or more often in a given frame.
I don't know where you're getting the whole broadcast brightness thing from, but it has nothing to do with how vector monitors worked.
> I don't know what the hell Z-amplitude is, but the brightness on vector games is > simply a factor of how long the beam remained on a given spot, or how often a vector > was redrawn compared to other vectors in the same scene. The shots in Asteroids, for > example, are exceptionally bright because they're physically drawn more often than > the rest of the vectors in the scene. > > There was no frame rate per se in vector games, and the way MAME currently emulates > vector games lacks the appropriate information for being able to do actual overdriven > vectors in a shader. The proper way to handle it would be for the OSD to be made > aware of the actual duration of the draw per-vector, and for the vector's brightness > to be adjusted in the shader based on that factor. Ideally, this information could be > written into a render target as well, so that the bloom shader would be aware of it > in order to add extra bloom to vectors that were drawn either slower or more often in > a given frame. > > I don't know where you're getting the whole broadcast brightness thing from, but it > has nothing to do with how vector monitors worked.
All this vector double-drawing may be true and this could be the same as the Z-Amplitude, i am talking about. Believe me, i did extensive research on vector-games the last 2-3 months and talked with arcade-pros that owns the originals. The guys are not only fanboys and they know their business well. This was how they explained the stuff for me and i believe them. Good source: http://www.jmargolin.com/vgens/vgens.htm I also attached a picture of the Z-amplitude.
Off course has the broadcast-filter nothing to do with how the real stuff works, it is a effect, like HLSL is, to achieve some things, that we cant otherwise. I am aware of the MAME standards, so i think effects are somehow legal to use . The idea of a broadcast-filter sounds easier for me, than to do the stuff with OSD etc. And even if we could make that OSD thing happen, ask yourself what would the result be. Would this make the shots brighter? No, because white is white, it cant go brighter . The broadcastfilter would take care of that. Think of it like a compressor with a gate treshold, that opens only for the brighter vectors .
In my eyes there cant be a "proper" way, as long as you use a LCD or a "normal" CRT (CRT is better, but still raster ). Simulation is the way to go. Currently i would say, the best setup for colored vector games, is a PC-CRT with a high resolution (or a vector monitor :P ). It has a shadowmask and true phosphors/life. For B/W vector-games, would be a real B/W CRT be nice.
There is more problematic stuff with HLSL and vector-games, especially the handling of the resolution and effect-calculations, because unlike rastergames, we have no prescale factors on vector-games, which can be bad for the effects that are used, especially the glow. All effects are rendered on the current used screen resolution. We will try to change that and to have the prescale factor also back on vector games. Jezze did a lot for vector-games, but sadly something messed up with cocktail presentation mode and so the changes didnt went into 0164, maybe next version .
> I don't know what the hell Z-amplitude is, but the brightness on vector games is > simply a factor of how long the beam remained on a given spot
Vector games actually could modulate the CRT's cathode or screen grid like regular video and get different brightnesses of vectors (for Atari color vector games, this is how they selected the colors). The overdrive stuff like the shot in Asteroids was done by drawing it multiple times at max amplitude.
I think the problem with vector games in MAME is, that it uses RGB with 0-255 levels. In broadcast terms this would be called "illegal" colors, because a TV can only handle 15-235 levels of brightness properly for a good final picture. Good explanation: https://documentation.apple.com/en/final...=4%26tasks=true
Vector games used this as a benefit and with the overdrive effect they went with "brighter than bright". A good example is the explosion of the Death Star. On the original game, you wouldnt see those rings like in MAME. The colors would bleed so much into each other, that you actually dont see any rings. Thats why i think that such a filter would look good on vector games, to achieve the same effect.
> I think the problem with vector games in MAME is, that it uses RGB with 0-255 levels. > In broadcast terms this would be called "illegal" colors, because a TV can only > handle 15-235 levels of brightness properly for a good final picture. > Good explanation: > https://documentation.apple.com/en/final...=4%26tasks=true > > Vector games used this as a benefit and with the overdrive effect they went with > "brighter than bright". A good example is the explosion of the Death Star. On the > original game, you wouldnt see those rings like in MAME. The colors would bleed so > much into each other, that you actually dont see any rings. Thats why i think that > such a filter would look good on vector games, to achieve the same effect.
Having played one recently I can say that you definitely do see the rings, they don't bleed THAT much.
However it is still a really intense moment, the hardware is being pushed so hard the display becomes actually quite unstable and you can hear the hardware making noises as it struggles to cope with the demand being placed on it to the point where you're actually wondering if it really is going to blow up in your face.
> Having played one recently I can say that you definitely do see the rings, they don't > bleed THAT much. > > However it is still a really intense moment, the hardware is being pushed so hard the > display becomes actually quite unstable and you can hear the hardware making noises > as it struggles to cope with the demand being placed on it to the point where you're > actually wondering if it really is going to blow up in your face.
Thats what i mean . Back in my days as a graphics artist doing weather-forecast pictures at a tv-station, my instructor showed me a old tv with illegal colors on screen. This thing was so noisey, i first thought it will implode the next moment . But actually you only harm your ears and/or eyes, the TV is still fine .
> I think the problem with vector games in MAME is, that it uses RGB with 0-255 levels. > In broadcast terms this would be called "illegal" colors, because a TV can only > handle 15-235 levels of brightness properly for a good final picture. > Good explanation: > https://documentation.apple.com/en/final...=4%26tasks=true
I'm well aware of the color space limitations of broadcast TV, but I have to ask, are you aware that there's a difference between a bare CRT taking in RGB, and a television set displaying a broadcast NTSC signal?
> I'm well aware of the color space limitations of broadcast TV, but I have to ask, are > you aware that there's a difference between a bare CRT taking in RGB, and a > television set displaying a broadcast NTSC signal?
Yup - arcade monitors are for all intents and purposes the same as the 15 kHz analog RGB monitors used on the Amiga/ST/IIgs. (I've used a 1084S and a IIgs monitor to show the picture from JAMMA boards successfully). In particular, they don't need broadcast-safe colors, you can crank the R/G/B to both ends and there's no problems.
Where broadcast-safe comes in is NTSC. Extremely bright red on NTSC causes very unattractive artifacting, for instance. But no vector games ran NTSC to the monitor, it would be nonsense.
This is all true and you all, are right with the explanation. I made the mistake, that i didnt explained it further. Off course there is nothing wrong with RGB and the 0-255 levels, but i still think, that a broadcast-filter kind of shader, would make sense, just to have that little space for overdrive effects. If you use the brightness, contrast, gamma settings to achieve some overdrive, you will see that there is not much scope you can play with, because you will brightness the whole game-screen, which is mostly wrong for certain vector-games.
I would still like to see a kind of proof or documantation on your state, that the vectors are drawn twice (or more) to achieve that brightness (Asteroids shots etc.), cause i think you are wrong with this assumption. This is important (at least for me) to clarify, if we want a better simulation on this. I dont write this, to sound dogmatic here. I really want to cooperate with you all and to find a good and optimum way to have better results and i am interested in every single opinion of you.
Index 
Threaded 
Star Trek arcade by Sega (Video)
Reply
[Re: 
. The idea of a broadcast-filter sounds easier for me, than to do the stuff with OSD etc. 
. Back in my days as a graphics artist doing weather-forecast pictures at a tv-station, my instructor showed me a old tv with illegal colors on screen. This thing was so noisey, i first thought it will implode the next moment 