Previous Thread
Next Thread
Print Thread
Page 1 of 5 1 2 3 4 5
How does the hardware of vector-games work? #101776 09/29/15 11:39 AM
Joined: Jul 2015
Posts: 97
u-man Offline OP
Member
OP Offline
Member
Joined: Jul 2015
Posts: 97
Hello guys,

I allready asked questions about the hardware of vector games and how it works, in the shoutbox. Many things where told, many where interesting, but i still have no absolute (or proofed with a source) answer. Specifically the "overbrightness" in some games is relevant for me (i.e. bullets of Asteroids, Deathstar explosion in Star Wars etc.). Initially i asked my german arcade-zone.de friends (pro-collectors and best scene in germany), what they know about the hardware and how this "overbrightness" really works. They came up with a so called "Z-Amplitude" as a answer :



Question is, if this thing is true, is it emulated in MAME and if it is, where i would find it?

Asking the same here, came up with different answers. People explained that vectors are drawn multiple times to achieve the "overbrightness", which nobody can approve at arcade-one.de to me. So i am in the misery, for the right answer. Is there anywhere a source to read about the multiple drawing of the vectors?

I am assuming that this "overbrightness" is not emulated in MAME or at least not noticeable enough. I am asking all these questions, because Jezze maybe could change some stuff, but wants to do it properly and hopefully just with HLSL.

I came up with the idea of a clipping filter, to keep brightness of vector games within a range and spare some heap for the "overbrightness", but we need to know if it is even possble to retrieve "overbrightness" info inside of MAME. So this thread is more a preparation for upcoming work, to achieve the desired result. Any expert answers about the vector renderer in MAME are welcome here.

Jezze allready did some changes to vector games, bringing back some functions of HLSL to vector-games. You can read about it here: https://github.com/mamedev/mame/commit/062e6e0383050546656dfed7261273a2d7d142a4
I am not sure if he added HLSL shadowmask options, for colored vector games (yes, they have one), but if not, it is for sure in the "upcoming next" agenda wink .

These pictures are taken from a original Star Wars, where you clearly see the shadowmask:





I know that we cant emulate vector-games to look like the originals (with current state of MAME that treats the screen of vector games like a raster screen), but it would be nice to "simulate" it as best as possible, without altering any code that function properly and behaves like the original. So the question is, how far we can get with alternatives like shaders and so on. I am open to any nice ideas and suggestions here. Jezze cant rewrite the vector renderer, but we have hope that there is stuff, that could be useful for shaders.

I think thats enough for a initial and good starting thread.
Thanks for your time reading it wink


I live... I die... I live again.
Re: How does the hardware of vector-games work? [Re: u-man] #101777 09/29/15 12:16 PM
Joined: Mar 2001
Posts: 16,394
R
R. Belmont Online Content
Very Senior Member
Online Content
Very Senior Member
R
Joined: Mar 2001
Posts: 16,394
The "Z amplitude" is the brightness of the video signal, as we attempted to explain to you previously.

Re: How does the hardware of vector-games work? [Re: R. Belmont] #101779 09/29/15 04:14 PM
Joined: May 2009
Posts: 1,822
J
Just Desserts Offline
Very Senior Member
Offline
Very Senior Member
J
Joined: May 2009
Posts: 1,822
Correct. The "Z Amplitude" signal is just a clever way of saying the brightness of the beam. In actual fact, I think this may be a combination of four things:
- The vector system assuming everything being drawn is a line
- The vector system's internal anti-aliasing working against us
- The vector system not handling intensity in an ideal way
- The handling of vectors in d3dhlsl.c and the vector shader need to be fixed, ideally by Jezze

Here's a pastie link containing a dump of each point that's written by avgdvg.c in one frame of Asteroids, with a player's shot on-screen: http://pastie.org/10450392

The first three points are the player's shot. Note the intensity: It's roughly double the intensity of all of the other vectors! So, this raises the question, why is the shot still so dar? Well, it's a combination of things.

First of all, the vector system assumes everything being drawn is a line. Check it out for yourself at the bottom of src/emu/video/vector.c. With what's currently in the list, it will produce a line of length 0 for the player's shot.

This certainly isn't going to be fatal, but it's not ideal, and it's even less ideal when you consider the fact that vectors, by default, are anti-aliased. How is our OSD-side anti-aliasing code going to account for the fact that it's a line of zero length? I would guess that it's probably not going to behave too terribly well.

I would also suggest that the way vectors are currently handled in my HLSL code leaves something to be desired. There's a gross hack in vector.fx to try to brighten short vectors, but that's a hack and should eventually be removed.

Lastly, regarding things that could be easy to fix: The core vector system in vector.c treats the vector's intensity as an alpha value, but does not attenuate the actual color value of the vectors. I bodged a quick hack into vector.c to scale down the color value based on the intensity value, as well as use the intensity value as alpha, and this is the result on Asteroids and Star Wars. Note that you have to click on the images in order to expand them, otherwise the size reduction makes it harder to see the differences: http://imgur.com/a/spPch

It does make most of the vectors rather dark, yes, but it does dramatically increase the contrast level between the half-intensity and full-intensity vectors, and I think some post-processing on top of that would really go a long way, assuming Jezze can whip together a better vector shader than what's already there (which is admittedly awful).

As for actual accuracy goes, the current theory is that the shots are made extra-bright by holding the beam in place for the shot for an extra few fractions of a second versus how vectors are normally drawn by the Atari DVG unit. This could be fixed by having vector.c know about the current time of the start and end points of the vector, and use that to infer an additional level of brightness in addition to what's specified by the hardware (which is already emulated).

The problem is that having this functionality is meaningless unless the individual vector drivers themselves start to use it, and that's a much more daunting task, because the current emulation of the Atari DVG is pretty ancient, and doesn't really play well with MAME's current scheduler system. More specifically, the Atari DVG code is a god damn cluster fuck of epic proportions: It appears to have its own internal scheduler, so to speak, and operates using its own time slicing, then reports back to the parent driver how many cycles it ran for, or something like that. As a result, the current system time as reported by machine().scheduler().time() is in fact the same for swaths of the vectors generated, and it seems like it would take a pretty massive re-tooling of the code in order to operate correctly. Multiply this by all of the different drivers that make use of the vector system, and, to quote Dog from Lock, Stock, and Two Smoking Barrels, "It's a bit more than a bit of a problem. I'd say it's the Mount fucking Everest of problems".

Re: How does the hardware of vector-games work? [Re: u-man] #101780 09/29/15 04:55 PM
Joined: Aug 2015
Posts: 381
Edstrom Offline
Senior Member
Offline
Senior Member
Joined: Aug 2015
Posts: 381
Vectrex is one of the reasons I started to contribute to MAME/MESS, as I was hacking a way with a C++ for Vextrex tutorial and needed a nice debug environment and still aim for that using MAME/MESS. Anyway, while doing the Vectrex tutorial rewamp converting 6809 assembler to C/C++ I read a lot of documents about the internals of Vectrex and there are loads of it at the Vectrexmuseum and in other places you'll find from the link collection there.

From that I believe that a good emulation need to render time as well as the vector and that time contributes to brightness not only to the current pixel itself but surrounding pixels which are accumulating brightness as the beam passes by. Then the pixels would have it brightness fade away as the phosfor looses its charge.

The vectrex hardware is really simple, just a D/A per axis and a beam on/off controlled by standard circuits. The speed/intensity of the beam is controlled by a counter/timer. There is also an intensity pot that when turned to max makes the beam-off movement traces to be seen aswell.

On top of that the audio circuitry is really poorly designed and get a buzz noice from the vector cirtcuitry which changes frequency depending on the vectors. I have seen at least a homebrew game using the buzz noice during vertical blanking to make music but I am not sure any original titles did that.

Having said that, I am not sure how close a good enough emulation needs to go in terms of accuracy, I just want to give some input if the vector system is to be redesigned and I would be happy to sub-contribute in the area if needed.

Last edited by Edstrom; 09/29/15 05:01 PM.
Re: How does the hardware of vector-games work? [Re: u-man] #101781 09/29/15 05:21 PM
Joined: Sep 2004
Posts: 385
A
AaronGiles Offline
Senior Member
Offline
Senior Member
A
Joined: Sep 2004
Posts: 385
Yes, ideally the vector generators (and mathboxes) should be implemented as executable devices so they can be properly scheduled.

However, you can probably make the existing AVG/DVG stuff work by taking the start time and adding cycles_accumulated_so_far * clock_period to the base time and using that for timing.

Re: How does the hardware of vector-games work? [Re: u-man] #101782 09/29/15 05:35 PM
Joined: Jul 2015
Posts: 97
u-man Offline OP
Member
OP Offline
Member
Joined: Jul 2015
Posts: 97
First thanks, for all the info. So i will try to summarize this:

Z-Amplitude just handles brightness and there is no "overbrightness" factor. The overbrighntess just comes from the fact, that the beam is staying a tick longer on the same place.

Further we dont see bright bullets even if there is a nearly double intensity value for brightness, because the renderer treats points as lines and those points are also anti-aliased, which in turn makes the bullets look dark again.

Regarding the things that could be easy to fix: is your example in the current MAME version or is it something that you have done by yourself, just to show what is possible with a fix?

It would be a huge task to improve the vector-renderer, because we would also need to alter the roms to use the improvements, as every vector game treat the drawing differently or in some cases even have their own "timing/frame" system.

Is this summary roughly correct?


I live... I die... I live again.
Re: How does the hardware of vector-games work? [Re: u-man] #101783 09/29/15 05:50 PM
Joined: May 2009
Posts: 1,822
J
Just Desserts Offline
Very Senior Member
Offline
Very Senior Member
J
Joined: May 2009
Posts: 1,822
Originally Posted By u-man
Regarding the things that could be easy to fix: is your example in the current MAME version or is it something that you have done by yourself, just to show what is possible with a fix?


It's actual code that I had running, but it's a somewhat gross hack, so I'm not comfortable committing it to baseline.

Originally Posted By u-man
It would be a huge task to improve the vector-renderer, because we would also need to alter the roms to use the improvements, as every vector game treat the drawing differently or in some cases even have their own "timing/frame" system.

Is this summary roughly correct?


No, that's not correct at all. None of this requires altering the ROMs at all. It all comes down to how the Atari DVG and other games' vector generators are emulated, it has nothing to do at all with modifying the ROMs themselves. Someone proposing a solution that involved modifying the ROMs would get laughed off the mailing list.

Re: How does the hardware of vector-games work? [Re: AaronGiles] #101784 09/29/15 05:53 PM
Joined: May 2009
Posts: 1,822
J
Just Desserts Offline
Very Senior Member
Offline
Very Senior Member
J
Joined: May 2009
Posts: 1,822
Originally Posted By AaronGiles
Yes, ideally the vector generators (and mathboxes) should be implemented as executable devices so they can be properly scheduled.

However, you can probably make the existing AVG/DVG stuff work by taking the start time and adding cycles_accumulated_so_far * clock_period to the base time and using that for timing.


Looking at the code, I can't imagine it would be too terribly hard to do that in its current incarnation, it apparently is based off of vg_run_timer, which would simply go away in favor of an executable device interface which pumps run_state_machine, yeah?

Re: How does the hardware of vector-games work? [Re: Just Desserts] #101786 09/29/15 09:01 PM
Joined: Jul 2015
Posts: 97
u-man Offline OP
Member
OP Offline
Member
Joined: Jul 2015
Posts: 97
Originally Posted By Just Desserts
Originally Posted By u-man
Regarding the things that could be easy to fix: is your example in the current MAME version or is it something that you have done by yourself, just to show what is possible with a fix?


It's actual code that I had running, but it's a somewhat gross hack, so I'm not comfortable committing it to baseline.

Ok, good to know. It looks nice and the difference is clearly visible for me. Maybe Jezze can do something with this or use it for a start. I can achieve a similar look with HLSL, but it is tremendous trial to find the right settings and it is different for every game or in other words i cant use global settings that looks the same on each game.

Originally Posted By u-man
It would be a huge task to improve the vector-renderer, because we would also need to alter the roms to use the improvements, as every vector game treat the drawing differently or in some cases even have their own "timing/frame" system.

Is this summary roughly correct?


No, that's not correct at all. None of this requires altering the ROMs at all. It all comes down to how the Atari DVG and other games' vector generators are emulated, it has nothing to do at all with modifying the ROMs themselves. Someone proposing a solution that involved modifying the ROMs would get laughed off the mailing list.

Yes you are right and i didnt mean the roms, but rather the drivers... it is clearly not my day today frown , but this is another story.
All in all, you clarified a lot for me.


I live... I die... I live again.
Re: How does the hardware of vector-games work? [Re: u-man] #101790 09/29/15 10:30 PM
Joined: May 2009
Posts: 1,822
J
Just Desserts Offline
Very Senior Member
Offline
Very Senior Member
J
Joined: May 2009
Posts: 1,822
Originally Posted By u-man

Yes you are right and i didnt mean the roms, but rather the drivers... it is clearly not my day today frown , but this is another story.
All in all, you clarified a lot for me.


That's correct in that case. Yeah, the drivers would all need to be updated to make use of the time-based functionality. It would, however, be possible to have an intermediate solution where there's a function that allows you to queue a time-stamped vector, and a function that preserves the old behavior so that drivers can be gradually updated to support the new functionality.

Still, it would be kind of nightmarish to rework all of the vector drivers to support it. It's something that we should really do at some point, I'm just saying that it won't be a particularly easy fix.

Page 1 of 5 1 2 3 4 5

Who's Online Now
3 registered members (R. Belmont, RColtrane, 1 invisible), 172 guests, and 2 spiders.
Key: Admin, Global Mod, Mod
ShoutChat Box
Comment Guidelines: Do post respectful and insightful comments. Don't flame, hate, spam.
Forum Statistics
Forums9
Topics8,722
Posts114,643
Members4,873
Most Online510
Aug 26th, 2019
Powered by UBB.threads™ PHP Forum Software 7.7.3