Yeah, pixel perfect will however not be aspect correct. As 320:200 is a 16:10 resolution in terms of pixels, but should be displayed in 4:3 means the pixels are stretched. And the only way to do that pixel perfect is by using very specific resolutions.
Like 1600x1200 (which is 4/3 but with 320 multiplied by 5 and 200 multiplied by 6).

However, with 320x200 it seems like even non-pixel perfect looks fine.
1280x1000 is pixel perfect and "almost" keeps the 4/3 perspective
But I also tried 1440x1080 which looks fine (nearest neighbour)

That is not true for 640x480.
That looks great in 1280x960 but horrible in 1440x1080.

Nesrest neighbour downscaling to 320x200 and then upscaling to 1600x1200 solves the aspect ratio isdue while maintining "pixel" perfection.

analog signals don't have "pixels" per se, 320x200 is output line-doubled in VGA cards hence why it gets recognized as 720x400 usually because it has 400 active lines, now the horizontal resolution is just a matter of sampling hence why you have to sometimes fiddle with the settings to get a pixel-perfect capture.

VCS sometimes gets this wrong, and you have to switch resolutions back and forth to make it work again, make yourself a preset for that resolution that you can force via key-combo to fix it again.
and yeah you can go slightly off ratio, but I do that after capturing, I first downscale it to it's original resolution i.e. 320x200 and then rescale it to whatever to output is, i.e. do 1280x1000 for 1080p if you wanna keep it pixel perfect.

personally I have a 1440p monitor, so for playing I just do 1600x1200 (though I do that regardless of resolution, so also for SVGA etc. the downscaling trick mitigates any filtering for recording anyways), the VisionRGB in combination with VCS is perfectly capable to play games through, lag isn't really noticable to me, for recording I just use filtering anyways.

Yeah, my intention is mostly Youtube. So a good picture on 1080p is pretty much a must.
Surprisingly 320x200 looks decent on 1080p even if its not pixel perfect. I will probably still go for 1280x1000.
800x600 upscaled further looks like total garbage. So here for now I think the area upscaler is the best solution.

From my current testing:
320x200->1280x1000 (but even 1440x1080 looks ok) nearest Neighbour
640x480->1280x960 nearest neighbour
800x600->1440x1080 area upscaler

I also need to figure out a good way to switch in between them though if there is a game which takes a different resolution when on world map or something. As from how I see it, there is no way to have "dynamic" profiles either in OBS if I wanted to upscale there, or in VCS.

Does someone know a reliable way to reproduce the 320 x 200 as 640 x 480 issue in VCS? I don't remember seeing the problem on Linux now, but 640 x 480 is the program's default startup resolution for input and output, so maybe something isn't getting correctly hooked up to the capture API on initialization.

Even so, I'd imagine using the input resolution dialog (or Ctrl+4) to force 640 x 400 should fix it?

vvbee wrote on 2022-11-19, 08:52:

Does someone know a reliable way to reproduce the 320 x 200 as 640 x 480 issue in VCS? I don't remember seeing the problem on Linux now, but 640 x 480 is the program's default startup resolution for input and output, so maybe something isn't getting correctly hooked up to the capture API on initialization.

Even so, I'd imagine using the input resolution dialog (or Ctrl+4) to force 640 x 400 should fix it?

Yes, its actually easy to reproduce. Start VCS->You got the issue. ^^
No matter what resolution is running, for VCS the resolution on startup is always 640x480 unfortunately.

Examples:
1. Start Duke Nukem 3D in 320x200. Then start VCS. Detects 640x480
2. Start Windows in 800x600. Then start VCS. Detects 640x480

Forcing the input resolution (e.g. to 320x200 or 800x600) fixes it.
It is also fixes as soon as there is any resolution change.

Example:
-Start Duke Nukem 3D in 320x200. Then start VCS. Detects 640x480
-Close Duke Nukem 3D. In this case I am now in Windows 800x600, which is correctly detected.
-Starte Duke Nukem 3D, the program "correctly" detects 720x400

Thanks. I remember fixing a bug like that years ago, so I'm guessing it's a regression of a similar thing, i.e. it doesn't hook up to the active video mode on startup. My guess is if you start VCS without there being an input signal to the capture card, then boot up whatever you're capturing, VCS will pick up the right mode then as well.

It doesn't seem to be an issue in the Linux version, and it's been a year or more since I did capture in Windows, so maybe that's around when the bug came in. If so, VCS 2.4.0 should work properly.

I don't have the hardware setup to capture in Windows right now, but I'll see about it at some point.

Turned off the PC, started the program, it will then go to
640x480 @0.000 Hz.
started the PC and it then automatically switched to
640x480 @59.940 Hz.
and a second later to
720x600 @75000 Hz.
So that indeed works.

I also tested version 240 now, but it got the same issue on startup.

Btw: Also posted some other feedback over at your specific thread at
Re: VCS - A capture utility for certain Datapath capture cards

So what is the best cheapo aliexpress available 70hz compatible device these days for people who are not chasing perfection?

Would be a crazy or feasible (or both, maybe) idea to try to bit-bang digital data coming out of a VGA chip and meant for a RAMDAC into something like the GPIO pins of a Raspberry Pi ?

darry wrote on 2022-11-20, 16:58:

Would be a crazy or feasible (or both, maybe) idea to try to bit-bang digital data coming out of a VGA chip and meant for a RAMDAC into something like the GPIO pins of a Raspberry Pi ?

I'm guessing you don't even need to hijack the data in any way if the card actually has a VESA feature connector, actually..

Been reading up on this topic a bit as it looks like I'll need to change my setup a bit in the near future: I now have a separate work room and retro 'mancave', but my sons are getting bigger, have had enough of sharing a room and will probably have to give up one of my rooms for one of them. For work I need a big 3x 24" TFT setup (currently 1x 1900x1200, 2x 2560x1440), which means there's no room in front of me for my CRT. I can move it to the side, which is fine for showing off, but not for longer periods of actual use.

So what I'm considering is using a capture card to feed the output of my VGA KVM (hooked up to all my old boxes) to a capture card so I can get the feed in a window on my Windows 11 desktop. I particularly want that, as I find 320x240 VGA looks awful at full screen on TFT screens this size, and I want to be able to move it round/behind other windows I'm working on rather than dedicate a whole screen. Being able to also easily take screenshots is a nice-to-have bonus 😉

Given what I've read on the past few pages, the DataPath VisionRGB-E1S sounds like a good choice for capture. How's the latency for actual real-time use? I'm not a huge FPS gamer (most of my retro time is spent in 4x games like Colonization or Master of Magic) but I get very irritated by visible input lag. If there are better options, I'm open to them.

The latency is very low. I just recorded a clip with 120 fps.
Right side is the original machine. Using VGA on a Fujitsu Siemens Scenicview P20-2 which has a delay of 16 ms (depending on how its measured, according to datasheets)
Left Side is a PC, with the Datapath connection, showing it in a window on a IIYAMA ProLite B2280WSD which supposedly has 5 ms delay.
So let's say that the left monitor has a delay advantage of 11ms

And when I am shooting with a gun in Duke Nukem 3D you can see that it looks pretty much the same. If you go into it frame by frame, you can see that the ammo goes down just a tiny bit differently. Not even every frame. Considering one frame on 120 fps is 8ms, it's less than that. Let's assume its 6ms

Maning the right screen (original hardware) takes 16ms to display it.
The left screen takes maybe 16+7ms = 23s to display it. Subtracting the delay of the monitor itself, you have 23s-6ms=17ms of additional delay by the datapath if my math is right. ^^

I think for the vast majority of games, this is very likely completely irrelevant. Maybe if you play shmups or other stuff with extreme reaction times, then maybe it makes a slight difference.

I think youtube only offers up to 60 fps, you can go foward/backward a frame pressing komma , and dot .
https://www.youtube.com/watch?v=QTTQrw3Bhso

Edit: Used the VCS software. Ofc it might be possible that the original software would have even less delay. Didn't test that.

Kordanor wrote on 2022-11-24, 16:15:

Edit: Used the VCS software. Ofc it might be possible that the original software would have even less delay. Didn't test that.

When I benchmarked it four years ago, VCS was faster than Datapath's app. That was in a virtual machine using the VisionRGB-PRO and its version of the Datapath software. For HD capture with a slow CPU, Datapath's could be faster in any case.

I can confirm the Datapath VisionRGB E1-S, E2-S and VisionAV with VCS application works perfectly and with latency low enough to be perfectly usable as a screen for gaming PC.

The is only one slight concern - the VCS loads one core of your CPU to 100% load when running. So for example on my Ryzen 9 5900X that means the CPU consumes about 70W when running VCS. with the original Datapath SW, the CPU remains idle which means about 40W less in my case.

havli wrote on 2022-11-26, 21:54:

The is only one slight concern - the VCS loads one core of your CPU to 100% load when running. So for example on my Ryzen 9 5900X that means the CPU consumes about 70W when running VCS. with the original Datapath SW, the CPU remains idle which means about 40W less in my case.

VCS disables DMA and does everything by the CPU. It's by design, and I don't currently see it changing fundamentally at least. You can disable CPU boost, use Eco mode, or whatever, and get saved watts that way.

I think the Datapath app defaults to DMA and scales on the capture card, so the power gets used elsewhere. Probably still more efficient though.

Yes, I figured this is intended behavior. Right now I spend most of the time using the capture card as a monitor for my CPU testing platform. So very simple task - just show 1920x1080 resolution in a window. For this purpose I am using the Datapath app. And for other purposes VCS, when I need some of the extra features.

Probably a reasonable split. I'll look into using a callback system though, where the capture thread could spin the main thread on capture events and otherwise the main thread sleeps, rather than the main thread continuously polling flags set by the capture thread. Not sure if it's possible without introducing at least slightly more latency.

Had a look at it - seems doing a callback system would require either a single thread that does everything (not ideal), or some amount of extra latency in cross-thread communication (not the best thing either).

What I ended up doing for now is I'll put an eco mode into VCS that you can toggle on the fly via the GUI. When disabled, VCS works as it does now, and when enabled, it forces the main thread to sleep between capture events (new frames, new video modes, whatever) for a duration determined by how much idle time there's been lately between capture events. On Linux at least, it looks to work reasonably especially if your system load is fairly static. And if you do want to run in eco mode then you probably don't care about an occasional extra frame drop or however the additional latency ends up coming out.

This is great news, thank you. I am really looking forward to try this new version. 😀
Missing frame from time to time or slightly higher latency is definitely no problem for me.