Improve backend (core) vector support to supply potentially useful frontend data

[MooglyGuy]

Boilerplate Introduction
At present, the code for handling vector (e.g. Asteroids, Tempest, Star Wars) games is lacking in a number of areas, both in terms of accuracy and in terms of tracking data that would be useful for reproducing the visual peculiarities of a vector display.

Issue Introduction
This particular issue proposes a solution for amending the lack of temporal data pertaining to vectors drawn with the src/emu/video/vector.* subsystem. Without this information about the times across which vector points are issued, certain data is lost that could be used to contribute to the accurate perceptual reproduction of vector monitor displays.

Background
It is well known that in an authentic vector monitor, vectors are drawn by sweeping the electron guns between two X,Y points on the screen. What is not as well-known is that vector monitors did not have a refresh rate, per se, and simply drew vectors in the order in which they were submitted by the underlying arcade hardware. Equally obscure is the fact that depending on the signals sent to the monitor, the electron guns' beams could be allowed to linger on a given point, increasing the intensity of the point by exciting the phosphors on the front of the CRT. It is also relevant to mention that the length of the vector drawn can have an effect on the perceived brightness of said vector, as a beam between two diagonally opposite points on the CRT will naturally be swept much faster, and thus have less time to energize the front phosphors, than a short vector, e.g. the ship in Asteroids, or an enemy shot in Star Wars. The fact that this data is not available in any way to the platform-agnostic (core) vector system in MAME means that there is no way to store this data per-vector, and by induction, that there is no way for a platform-specific front-end, perhaps with shader-based post-processing, to act on said data to enhance the perceived brightness of these vectors.

Solutions
The vector_device class is already an instance of device_t, meaning that it should already be possible for said device to log the time at which a vector point is queued via machine().time(). This function returns an attotime, which should be stored directly in the point structure defined in src/emu/video/vector.h. The simplicity of this is confounded by the fact that some vector devices in MAME are not currently time-sliced by the primary scheduler, but a solution for this issue will be proposed in a separate issue ID.

During vector_device::screen_update, the end and start attotimes of the two point instances that make up a specific vector should be subtracted from each other to calculate the overall time given to drawing said vector. This resulting value should be converted to a double containing milliseconds in the integer portion, and fractions of milliseconds in the fractional portion, should such data be relevant.

This, in turn, reveals a deficiency in the render_container class found in src/emu/render.*. A vector should certainly not be considered a simple line primitive, as it requires pertinent information - the time delta between the start and end points - that is not relevant to a simple line primitive. It is proposed that a related member function, add_vector, be added to the render_container class. Additionally, this new container item will need to be added to the enum found in src/emu/render.c which defines various CONTAINER_ITEM types, with a proposed name of CONTAINER_ITEM_VECTOR. Handling will need to be added for this type in render_target::add_container_primitives in the same source file.

Additionally, a new primitive flag type will need to be defined. We currently find PRIMFLAG_TYPE_LINE and PRIMFLAG_TYPE_QUAD in src/emu/render.h. As it is already assumed that two bits are used for the primitive type, a third type, PRIMFLAG_TYPE_VECTOR should be added. An initial implementation of this primitive type will require a minimal amount of changes to the OS-Dependent ("OSD") layer of code, as until the back-end code which enqueues the vectors is updated to operate synchronously with MAME's scheduler, said primitive type can be naïvely treated as a simple line due to the supplied time deltas not being meaningful until then.

Afterword
The implementation time of this particular task should be relatively low for anyone familiar with the architecture of MAME's code. For anyone not familiar with the architecture of MAME's code, this task should provide a way of gaining initial familiarity both the OSD side of the code and the core side of the code. In either case, once the fundamentals are understood, implementing this should be trivial.

[JoakimLarsson]

u-man, I think you are talking about "fixing", or hiding, the lack of proper emulation with graphic post processing, eg shaders/filters, and that is fine. I believe that this proposal is about to improve the actual emulation, not hide the short commings of the current. For instance the vobblyness of vectrex is due to the game code is not zeroing the deflectors often enough and is very game specific. Also there are other shortcomings of the Vectrex you simply can't fix in postprocessing, like the contamination of audio cirtcuitry by leaking frequencies from the deflector DACs as demonstrated in the Bad Apple demo for instance, and the 50/60 Hz humming etc.

Now imho, this will take longer time than adding a couple of filter/shaders/wav files but will be available for all drivers simultaneosly in a cleaner generic way. In the meantime I believe that what RB proposed in #389 would work also for vector machines so you can have driver specific shaders instead of driver specific cover-up code in the core.

[JoakimLarsson]

No need to apologize, it's merrily my opinion, MAMEdevs might decide that the right thing to do is to draw a line in the sand and say that this is the best we do right now awaiting Moore's law to allow for improved accuracy. Your proposals regards filters/shaders which in my mind belongs to the frontend while this is a core issue and the Vector renderer is in between I believe. Ideally the post processing is done on top of the vector renderer so it can be clean from filter/shader code so you can add your driver specifics separately.

The buzzing (30Hz as base actually) is available on all first generation Vectrex as soon as you turn them on, it is a PCB design flaw that is well known: https://en.wikipedia.org/wiki/Vectrex#Sound. All I am saying is that it is not something you add statically since the buzzing frequency follows the graphics rendering.

[osresearch]

I've just submitted pull request #483 to output the game display to actual vector hardware and can confirm that the Vectrex sitting next to me demonstrates quite a bit of buzz based on what is on screen, as well as lots of wobble and shimmy. Not sure how much of that is bad caps versus the original low-cost design.

[flukejones]

Hi all. I'm going to have a go at this as a way to learn more C/C++ and exercise what I'm learning at university. I'll be using the advice given above, and the work @osresearch has done, as a starting point and also working from a very old version of MAME (v0144) to which I had ported a very old vector patch.
MAME Vector mod - software rendering only, I'd forgotten I did this.

Between all this, hopefully I should get somewhere.

[flukejones]

Just an update. I've been going through the code and taking copious notes; getting things started.

Edit: I've basically done just as was suggested by @MooglyGuy and have it compiling. I'll start extending things soon.

I haven't got too much to show yet as I'm doing this between study (Comp Sci).

[rb6502]

Glad to hear that, @Luke-Nukem !

For reference, the Vectrex buzz was due to a manufacturing error; when it's built to the schematics it has no buzz. Some models (I think all of the Bandai-branded Japanese market ones) were built properly; people sometimes mod those to have the buzz again for "authenticity". This was covered in interviews with the designers in the "Vectrex Radio" podcast.

[pmarks-net]

To illustrate this problem, here is a screenshot of Asteroids rev 2 from AAE, an emulator that was abandoned in 2008. Notice the glowing effect on the bullets. It's not entirely realistic but it's a good attempt:

For comparison, here is the same game on MAME 0.271. Notice that the bullets are just dots without any glow:

This YouTube video shows the bullets on a real CRT: https://www.youtube.com/watch?v=EI3o3hCpGzA&t=8s

[MooglyGuy]

By all means, go track down the source code for AAE and provide a link here, so I have a reference point for the implementation.

I'm not against improving the vector rendering behavior in MAME, but what I am very much against is implementing situation-specific hacks that I suspect forks like AAE resorted to.

As I have said before, I strongly believe that the overall luminance of these tiny vector dots is achieved by letting the beam linger, actively, on a particular spot before drawing the next bit of geometry. So far, nobody has opted to either prove or disprove my assertion. Given the fact that I am now professionally a UI/UX programmer, and only delve into renderer coding for fun, I don't feel any particular inclination to waste my valuable spare time looking too far into it.

If someone can provide concrete proof of how these games actually managed to have these small dots end up with an outsized brightness, I'll be perfectly happy to spend the time on my end working out a reasonable one-size-fits-all solution. Because at the end of the day, that is what MAME is about. No per-game hacks, none of this nonsense that has to be obfuscated through a fork due to what is probably some shoddy code. Give me good data, I'll write good code. Until then, I will continue to focus on emulating other things like Namco's System 23 and associated boards.

[MooglyGuy]

Realistically speaking, just in case there is someone with more time to burn than sense: In theory, getting this dialed in should be a simple matter of the vector screen device taking note of the elapsed machine time when a given point is plotted, and attenuating (or amplifying) the resulting luminance accordingly.

Problem is, that would require not just a timing-accurate 6502 core (which we do have) on 6502-based games like Asteroids - it'd also require accurate timing for everything else in the system. The Atari mathbox would need to operate with realistic timing. Things like bus accesses, too. Everything else. Every single thing that could potentially bleed cycles would need to be accounted for, in order to advance the current timestamp an accurate amount forward to know how long a given vector should linger.

Otherwise, there's the very real possibility that the point-to-point timing between individual AVG X/Y move commands would either linger too long, or not long enough. Sorry, but them's the breaks. If you want forward progress, start tracking down data. I have a long enough to-do list, which includes systems that have schematics or are otherwise straightforward enough to write test code to probe, that I'm not super enthusiastic about acquiring hardware and thrashing around in nitty-gritty low-level things.

Help me out, take an active role in fleshing out the cycle-accuracy of the Asteroids driver, and things are very likely to improve. But I can't go it alone, so I won't.

[pmarks-net]

I tweaked avgdvg.cpp to color code the different intensity values:

diff --git a/src/devices/video/avgdvg.cpp b/src/devices/video/avgdvg.cpp
index 7290ccb996b..d8a0f543f22 100644
--- a/src/devices/video/avgdvg.cpp
+++ b/src/devices/video/avgdvg.cpp
@@ -123,7 +123,27 @@ void avgdvg_device_base::vg_flush()
                        }

                        m_vector->add_point(x0, y0, m_vectbuf[i].color, 0);
-                       m_vector->add_point(x1, y1, m_vectbuf[i].color, m_vectbuf[i].intensity);
+                       rgb_t color = m_vectbuf[i].color;
+                       int intensity = m_vectbuf[i].intensity;
+                       // These cases cover the intensity values observed in Asteroids rev 4.
+                       if (intensity == 240) {
+                               // bullets (green)
+                               color = rgb_t(0, 255, 0);
+                       } else if (176 <= intensity && intensity <= 208) {
+                               // player/enemy ships, thrust (yellow)
+                               color = rgb_t(255, 255, 0);
+                       } else if (intensity == 128) {
+                               // some asteroid parts (bright cyan)
+                               color = rgb_t(0, 255, 255);
+                       } else if (intensity == 112) {
+                               // UI, most asteroid parts, debris (blue)
+                               color = rgb_t(0, 0, 255);
+                       } else if (intensity == 96) {
+                               // some asteroids parts (dark cyan)
+                               color = rgb_t(0, 128, 128);
+                       }
+                       if (intensity > 0) intensity = 255;
+                       m_vector->add_point(x1, y1, color, intensity);
                }

                if (m_vectbuf[i].status == VGCLIP)

This is the result. I notice that the bullets have a greater intensity (240 -> green) than anything else in the game, so making them glow should not require situation-specific hacks:

However, I also notice that the asteroids and debris points have the same intensity (112 -> blue) despite the debris appearing brighter in my previous YouTube link. On the high score screen, single points have a lower intensity (64) than the rest of the UI (112), so I think we can infer that points naturally appear brighter than lines on the vector display.

I wonder if the solution could be something simple, like scaling the intensity as a function of line length?

[pmarks-net]

I'm seeing interesting results with this patch that doubles the intensity of single points:

--- a/src/devices/video/vector.cpp
+++ b/src/devices/video/vector.cpp
@@ -181,21 +181,26 @@ uint32_t vector_device::screen_update(screen_device &screen, bitmap_rgb32 &bitma
                // normalize width
                beam_width *= 1.0f / (float)VECTOR_WIDTH_DENOM;

+               int display_intensity = curpoint->intensity;
+
                // apply point scale for points
                if (lastx == curpoint->x && lasty == curpoint->y)
+               {
                        beam_width *= vector_options::s_beam_dot_size;
+                       display_intensity = std::min(display_intensity * 2, 255);
+               }

                coords.x0 = ((float)lastx - xoffs) * xscale;
                coords.y0 = ((float)lasty - yoffs) * yscale;
                coords.x1 = ((float)curpoint->x - xoffs) * xscale;
                coords.y1 = ((float)curpoint->y - yoffs) * yscale;

-               if (curpoint->intensity != 0)
+               if (display_intensity != 0)
                {
                        screen.container().add_line(
                                coords.x0, coords.y0, coords.x1, coords.y1,
                                beam_width,
-                               (curpoint->intensity << 24) | (curpoint->col & 0xffffff),
+                               (display_intensity << 24) | (curpoint->col & 0xffffff),
                                flags);
                }

Here's a screenshot of mame -video opengl -beam_dot_size 2.5 -beam_width_max 2.5 -brightness 0.85 -contrast 1.20 -beam_intensity_weight 0.75 asteroid

Note that the intensity maxxes out at 255, so it would be possible to get more contrast by adding an else branch that decreases the intensity of non-points, but at least for Asteroids I'm able to get good enough contrast by adjusting the sliders, so that else branch doesn't seem necessary.

It appears that sometime between versions 0.257 and 0.271, -video opengl was fixed to render the dots as circles. I haven't found any other mode that looks reasonable (e.g. bgfx draws diamonds instead of circles), and I've failed to get any CRT shaders working, so the above screenshot is my current best result.