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.

[u-man74]

I have two ideas for the vector renderer, that may be interesting for this project:

• a shake/jiggle filter that operate on vertices level, to simulate the "stable" screen of vector games, especially true for the Vectrex system and the cheap hardware used (comparing to arcade vector games).
• due to the nature of the vector renderer, assuming that everything being drawn is a line, a filter would be needed, that treats "true" points (i.e. Stars, Bullets etc) like a special case. So that a point case could be passed to exclusive point fx, like bloom/glow, shading etc.

IMHO these two things alone, would vastly improve the vector renderer and the appearance of vector-games, without being maybe to complex to realize... sadly, i have no skills for that :( .

PS: excellent issue description.

[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 https://github.com/mamedev/mame/issues/389 would work also for vector machines so you can have driver specific shaders instead of driver specific cover-up code in the core.

[u-man74]

No doubt, that this proposal from MooglyGuy here, is about to improve the actual emulation. I just thought that my two arguments posted before, still belong to the vector renderer, than anywhere else (HLSL/GLSL/BGFX shaders) ,are also improving the actual emulation and would be also available for all drivers simultaneosly. The two arguments can only be solved (in a good way) through the vector renderer itself. They dont belong to any shader section, thats why i believe that no BGFX/HLSL/GLSL is of any help here.

In the case of vector games and for "true" emulation, we will not only be confronted, by the software itself, but rather with the hardware that created the fascination that everyone shares with vector games. I think we can agree that vector games are a special case in the world of emulation. Maybe i am completely wrong (and if so, i apologize), but i think that even the most accurate software emulation will reach a limit and i count my two arguments into it. Or in other words, i dont think you can reach better results, regarding "shakiness" and "point shading" through more accurate emulation. Again, i apologize, if i am wrong.

I see "shakiness" and "point shading" a lot more defining vector-games, then the 50/60 Hz humming or contamination of audio cirtcuitry, which is more a obscure thing and only happening under some circumstances.

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

[u-man74]

"...Not sure how much of that is bad caps versus the original low-cost design." :D ... i would say, blame the low-cost design.... still nice, to see star wars on a vectrex ;) .

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