{"action":"created","issue":{"url":"https://api.github.com/repos/mamedev/mame/issues/399","repository_url":"https://api.github.com/repos/mamedev/mame","labels_url":"https://api.github.com/repos/mamedev/mame/issues/399/labels{/name}","comments_url":"https://api.github.com/repos/mamedev/mame/issues/399/comments","events_url":"https://api.github.com/repos/mamedev/mame/issues/399/events","html_url":"https://github.com/mamedev/mame/issues/399","id":111929401,"number":399,"title":"Improve backend (core) vector support to supply potentially useful frontend data","user":{"login":"MooglyGuy","id":1891617,"avatar_url":"https://avatars.githubusercontent.com/u/1891617?v=3","gravatar_id":"","url":"https://api.github.com/users/MooglyGuy","html_url":"https://github.com/MooglyGuy","followers_url":"https://api.github.com/users/MooglyGuy/followers","following_url":"https://api.github.com/users/MooglyGuy/following{/other_user}","gists_url":"https://api.github.com/users/MooglyGuy/gists{/gist_id}","starred_url":"https://api.github.com/users/MooglyGuy/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/MooglyGuy/subscriptions","organizations_url":"https://api.github.com/users/MooglyGuy/orgs","repos_url":"https://api.github.com/users/MooglyGuy/repos","events_url":"https://api.github.com/users/MooglyGuy/events{/privacy}","received_events_url":"https://api.github.com/users/MooglyGuy/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/mamedev/mame/labels/enhancement","name":"enhancement","color":"c2e0c6"}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":8,"created_at":"2015-10-16T23:30:19Z","updated_at":"2016-09-09T21:09:53Z","closed_at":null,"body":"**Boilerplate Introduction**\r\nAt 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.\r\n\r\n**Issue Introduction**\r\nThis 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.\r\n\r\n**Background**\r\nIt 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.\r\n\r\n**Solutions**\r\nThe `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.\r\n\r\nDuring `vector_device::screen_update`, the end and start `attotime`s 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.\r\n\r\nThis, 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.\r\n\r\nAdditionally, 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.\r\n\r\n**Afterword**\r\nThe 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."},"comment":{"url":"https://api.github.com/repos/mamedev/mame/issues/comments/246040717","html_url":"https://github.com/mamedev/mame/issues/399#issuecomment-246040717","issue_url":"https://api.github.com/repos/mamedev/mame/issues/399","id":246040717,"user":{"login":"rb6502","id":9260603,"avatar_url":"https://avatars.githubusercontent.com/u/9260603?v=3","gravatar_id":"","url":"https://api.github.com/users/rb6502","html_url":"https://github.com/rb6502","followers_url":"https://api.github.com/users/rb6502/followers","following_url":"https://api.github.com/users/rb6502/following{/other_user}","gists_url":"https://api.github.com/users/rb6502/gists{/gist_id}","starred_url":"https://api.github.com/users/rb6502/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/rb6502/subscriptions","organizations_url":"https://api.github.com/users/rb6502/orgs","repos_url":"https://api.github.com/users/rb6502/repos","events_url":"https://api.github.com/users/rb6502/events{/privacy}","received_events_url":"https://api.github.com/users/rb6502/received_events","type":"User","site_admin":false},"created_at":"2016-09-09T21:09:53Z","updated_at":"2016-09-09T21:09:53Z","body":"Glad to hear that, @Luke-Nukem !\r\n\r\nFor reference, the Vectrex buzz was due to a manufacturing error; when it's built to the schematics it has no buzz (I believe this was true of Japanese models).  This was covered in interviews with the designers in the \"Vectrex Radio\" podcast."}}
{"actor":{"display_login":"rb6502"}}