Home Page Forums MAME MAME How does the hardware of vector-games work?

CRTs are no longer being manufactured, so good luck with that.

I've often thought you could create a texture, or these days a shader, that would create less of a boxy solid rectangle look and more of a bright middle with a smooth alpha falloff and rounded endcaps to improve the overall look. At least that was my theory.

There is already some example in bgfx that show this kind of shaders in action and this is preview of it :

Not a big fan of faux-blooming and artificial saturation, but otherwise that looks cool.

There is some old code in the D3D renderer, which does a texture mapping on the vector-line polygons, but I don't know if it ever worked. Maybe I can get it to work.


This basically the same what can be achieved with the HLSL post processing.

Micko that look cool.

It never worked because I'm the one who hacked it up originally.

I quickly realized that a single texture wouldn't really work because it gets stretched over arbitrary lengths. But a shader could in theory do it right.

Beside that most of you didnt realize that the change has nothing to do with (faux)-bloom or any other post-fx and that it rather has to do with the drawing of the vectors itself, shown in a very exaggerate way (without post-fx) to see the change, I would say it looks way better than before.

Previously the vectors looked like single matches that build a object and with the change, it looks more like a homogeneous/seamless vector build object, which in turn looks more realistic IMHO.

Someone could say the change is so minor and you wouldnt see it in "normal" usage anyway, but this would be a wrong decision. A small "bug" with post-fx on top, will change the final picture in a noticeable way, like it did often in the past with HLSL prior v.160 of MAME.

I told you once, that a time will come, where developers cant really compare abandoned technology (like vector-monitors in this case) with their own code. So a feedback for Jezze that help him is more appreciated, like the described issues from JD/MG on Github or the described Vectrex mechanics by Edstrom. Jezze needs/wants feedback, apart from "good/bad job", rather one that says "we tried something in the past, but abondened it, because of this and that, so lets look at it again and find a solution."

You can of course, sit and wait for HDR or any other upcoming technology. There is no question that HDR will improve the appearance of vector-rendering, but how much is still a theory until its proved.

One of my first real job as a programmer was to convert HPGL vector based plotter file formats to a Sixel format that could be sent to one of the first ink jet printers. When the job was delivered one of the first feedbacks were that the width of the lines were too thin due to the high resolution of the printer. However, they couldn't accept that the price for making the line wider was higher than the $200 that I received for the total job so I never completed that task.

If I had done it it would have looked similar to Jezzes pictures and at the time I was struggling with the corners and how to make them round and avoid the overlapping areas of the lines. The dots (overlapping areas) in the corners with higher intensity is needed by the Vectrex however.

An improvement I would think about is to draw the vectors as filled trapezoids to avoid the overlapping areas and then the dots in the corners separatelly as filled circles with the correct diameter (== vector line width) and intensity that is a factor 2 of the vector intensity. I admit I have no clue what goes in the shader and what goes in the vector renderer in the MAME graphic pipeline but that is my feedback at this point.

Thanks for your feedback.

The vector renderer currently only knows about lines, that have a start and end coordinate, an intensity and a width; points are also zero-length lines. And these lines are renderer by D3D, OpenGL and GDI in quite different ways. D3D renders rectangles, OpenGL renders simple lines and GDI renders parallelograms which is quite odd. (I think BGFX handles them like D3D.)

I also think that it would be an improvement if we were able to render single points as circles and lines as rectangles with rounded ends.

The approach of Aaron Giles to implement a texture mapping could also be continue.