Previous Thread
Next Thread
Print Thread
Page 4 of 5 1 2 3 4 5
Joined: May 2009
Posts: 2,053
Likes: 85
J
Very Senior Member
Offline
Very Senior Member
J
Joined: May 2009
Posts: 2,053
Likes: 85
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.

Joined: Aug 2015
Posts: 405
Senior Member
Offline
Senior Member
Joined: Aug 2015
Posts: 405
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 smile


Because I can
Joined: Jul 2015
Posts: 104
u-man Offline OP
Senior Member
OP Offline
Senior Member
Joined: Jul 2015
Posts: 104
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 frown .

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:
Click to reveal...



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.
Click to reveal...



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.

Click to reveal...



3. Some "wobble/shake" filter to mimic the "stable" smile 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 laugh ? 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:
Click to reveal...



StarWars Logo, with motion:
Click to reveal...



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 wink .


I live... I die... I live again.
Joined: Mar 2001
Posts: 16,928
Likes: 62
R
Very Senior Member
Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 16,928
Likes: 62
The Death Star explosion *is* visibly hexagonal on hardware, which makes perfect sense given how vector games work smile

Joined: Oct 2015
Posts: 26
J
Member
Offline
Member
J
Joined: Oct 2015
Posts: 26
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.

Originally Posted By Just Desserts
The handling of vectors in d3dhlsl.c and the vector shader need to be fixed

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].

Originally Posted By Just Desserts
The vector system assuming everything being drawn is a line

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.

Originally Posted By Just Desserts
The vector system not handling intensity in an ideal way

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)

Joined: Oct 2015
Posts: 26
J
Member
Offline
Member
J
Joined: Oct 2015
Posts: 26
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.


Joined: Feb 2004
Posts: 2,397
Likes: 113
Very Senior Member
Online Content
Very Senior Member
Joined: Feb 2004
Posts: 2,397
Likes: 113
The beam shouldn't be so sharp and square - it doesn't look realistic at all either way.

Joined: Oct 2015
Posts: 26
J
Member
Offline
Member
J
Joined: Oct 2015
Posts: 26
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?

Joined: Mar 2001
Posts: 16,928
Likes: 62
R
Very Senior Member
Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 16,928
Likes: 62
Realistic vector rendering will need everyone to have HDR monitors, so it's a ways off yet.

Joined: Aug 2015
Posts: 405
Senior Member
Offline
Senior Member
Joined: Aug 2015
Posts: 405
Or real vector monitors.... :-)


Because I can
Page 4 of 5 1 2 3 4 5

Link Copied to Clipboard
Who's Online Now
1 members (robcfg), 20 guests, and 3 robots.
Key: Admin, Global Mod, Mod
ShoutChat
Comment Guidelines: Do post respectful and insightful comments. Don't flame, hate, spam.
Forum Statistics
Forums9
Topics9,112
Posts119,407
Members5,024
Most Online890
Jan 17th, 2020
Our Sponsor
These forums are sponsored by Superior Solitaire, an ad-free card game collection for macOS and iOS. Download it today!

Superior Solitaire
Forum hosted by www.retrogamesformac.com