Open MooglyGuy opened 8 years ago
I have two ideas for the vector renderer, that may be interesting for this project:
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.
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.
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.
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.
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.
"...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 ;) .
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.
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).
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.
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 ofdevice_t
, meaning that it should already be possible for said device to log the time at which a vector point is queued viamachine().time()
. This function returns anattotime
, which should be stored directly in thepoint
structure defined insrc/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 startattotime
s of the twopoint
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 adouble
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 insrc/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 therender_container
class. Additionally, this new container item will need to be added to the enum found insrc/emu/render.c
which defines variousCONTAINER_ITEM
types, with a proposed name ofCONTAINER_ITEM_VECTOR
. Handling will need to be added for this type inrender_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
andPRIMFLAG_TYPE_QUAD
insrc/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.