So far aliases have been a Windows-only feature, so ultimately whoever starts maintaining the Windows version should keep that issue in mind.

What a shame you are not going to compile/maintain a windows verison any longer - VCS has been a key tool in its updated form for my making videos for Digital Foundry using retro PCs.

260 is OK atm - but it has had some issues detecting the input resolution at times from certain retro GPU hardware (2008 era Nvidia), though that just may be the Datapath card itself detecting those resolutions incorrectly. Usually for example taking 800x600 @ 60 hz and instead thinking it is 400x300 @♀120 hz

It's not really the nature of free open source that some specific dude works at it forever. It's a shame if nobody does, but if it's a shame for someone to stop doing it then it'll be a shorter queue of starters.

Guess the user group isn't all that large.
And being a user doesn't mean you can program. I mean I can program a bit (some basics in pythin,c++,c#) but I am not familiar at all with this. Never used github myself, would first need to learn how to actually compile the stuff already available to create that exe, and I am not even speaking about implementing new features of fixing any issues.
But if you are already saying that just compiling that is a total pain in the ass, I am not sure I could do it.

I'm not in the group of users either, so I'm not the guy to go to for this. If you want to work with it but are new to the whole thing, take baby steps - first compile it, then mess around with the code, etc. Luckily programming is now more accessible than ever, and natural-language-controlled AI is on the cusp of taking it over.

I've finally got to try and build some Windows binaries 😀

The result is a fork on GitHub that aims to maintain a working Windows/x64 build, and distribute binaries for it.

The 1st release for the fork is based on v2.6.1 and can be found here: https://github.com/arnoo-sel/vcs/releases.
It has been tested only on Windows 10, but should also work on Windows 11.

I hope this can be of some help!

Awesome, thanks! Going to test it tomorrow!

arnoo wrote on 2023-05-30, 21:59:

I've finally got to try and build some Windows binaries :) […]
Show full quote

I've finally got to try and build some Windows binaries 😀

The result is a fork on GitHub that aims to maintain a working Windows/x64 build, and distribute binaries for it.

The 1st release for the fork is based on v2.6.1 and can be found here: https://github.com/arnoo-sel/vcs/releases.
It has been tested only on Windows 10, but should also work on Windows 11.

I hope this can be of some help!

I will give it a download and try ASAP and write about my experience (Win 11)

I tested your version.
What I used before was V2.6.0

The way I record works as follows (just for you to see which things I might stumble over):

-I have presets for different resolutions
-These are then going through the filter graph, where they are denoised and then "scaled". Though I really use it to downscale and add pixels, not to upscale, but I will get to that later in the feature requests section.
-For Output I use software renderer
-To record the footage I use OBS, I use a defined space in OBS where it's scaled to 1280x1000 pixels (always stretched) using "point" which for whatever reason gives better result than "none" in OBS, achieving a Nearest Neighbour scaling.
This way I scale 320x200 (after downscaling from 720x400 in vcs) into aspect correct ratio while staying pixel perfect, and because I add the black padding to 640x480 in VCS, making it 640x480 it's basically just doubling it's size

So I tested your version. Things I noticed:
-Font is bigger, gets a bit less readable and the preset names get shortened by adding ascii characters. Purely cosmetical issue.
-I was able to correctly import my Filter Graph and preset settings
-Tested a game with 320x200 - worked as before
-Tested a game with 640x480 - worked as before (including the bug)

Feature and Bug-Fix Requests:
I got a few Bug-Fix and feature requests, which I mentioned before, but which I wanted to summarize here, also to clear things up from the previous conversation and to boil it down to essential parts to make it easier to read. The bugs existed before already, so not new to your version. I just tested and confirmed that they are still present:

Bugs:
-There is a bug with 640x480 Resolution not correctly applying presets. When you switch to that resolution, the preset does become active, but the horizontal size (which should be 800) is not applied. Its only getting applied if you add 1 in size and then remove it again. This to me would be the most important thing to fix, so that in a game which uses both resolutions (e.g. 320x200 for running around, and 640x480 for a map), you don't need to re-adjust the recording mid-recording every time (which also wouldnt be practical)
You can see a demonstration here: https://www.youtube.com/watch?v=DJ64DnnECQM

-Hotkeys for preset activation are currently broken. As there is no way for vcs to distingquish between 720x400 and 320x200, that would be super useful. So when running DOS Navigator for example I would like to switch into the "other" preset via a hotkey, but that seems to be broken.
I did set up two presets which should have activated with 720x400 on 70Hz. It will always activate the top one in the list. If I give the bottom one in the list a hotkey and press that hotkey it does nothing.

Feature Requests:
-Would be great to have an Output-Node for Output Scaler, in order to process the signal further (and to scale a second time). Most prominent usecase is 320x200 games. These are captured as 720x400, and need to be scaled down to 320x200 first, and then scaled up again in order to get pixel perfect scaling. Right now this has to be done in OBS.
-Would also be nice if as an "input gate" you could chose one of the presets instead of a resolution. That way you could also handle the different types differently (previous point)

So overall, it works the same as before, with minor cosmetical changes.
But either way it's great to have someone able to work in it again, very much appreciated 😀

If you want to switch between 720 x 40o and 640 x 400 manually, use the numpad shortcuts for input resolution. Presets should activate accordingly.

It should be possible to implement fully user-customizable UI styling by having the code load a .qss style file from disk rather than the one in the embedded resource file. QSS is pretty ugly but allows customization of most aspects of the UI.

Kordanor wrote on 2023-05-31, 23:56:

I tested your version.

Thank you for giving it a try!

I've got a lot to learn about the code base, but I do intend to start working on small bug fixes and easy features.
So thank you for the detailed bug reports!

I've create Issues on Github for your bug reports and feature requests.

Font is bigger, gets a bit less readable and the preset names get shortened by adding ascii characters. Purely cosmetical issue.

Could you send a screenshot of this, either here or on the Github issue I've created to track this? (https://github.com/arnoo-sel/vcs/issues/5)
Also, what's the scaling for the monitor this is happening on? (as set in the Windows display settings.)
High-DPI support is one thing that is handled differently by the newer version of the UI library I've been using in this release. I've tried to match the old behavior, but might have done something wrong.

As there is no way for vcs to distingquish between 720x400 and 320x200

I first started looking at VCS's code because of this exact thing, wondering if there was anything that could be done.
Although it cannot be done in a 100% accurate way that would work in all situations (that's just the nature of the analog signal), I've got some ideas for how to maybe do this in a way that's good enough for some situations.
I've got to get a lot more familiar with the code before I can even start investigating this though, so that's a long term thing 😀

vvbee wrote on 2023-06-01, 04:22:

If you want to switch between 720 x 40o and 640 x 400 manually, use the numpad shortcuts for input resolution. Presets should activate accordingly.

It should be possible to implement fully user-customizable UI styling by having the code load a .qss style file from disk rather than the one in the embedded resource file. QSS is pretty ugly but allows customization of most aspects of the UI.

I am not sure what you mean (i also want to change between two settings dealing with the same resolution (as it arrives in VCS), both being 720x400, the one "masking" 320x200, the other being "true" 720x400).
Numpad keys dont seem to do anything. CTRL+1...9 switches resolutions but I didnt follow the logic (it neither uses the order of presets nor the resolution screen)

arnoo wrote on 2023-06-01, 14:59:

Could you send a screenshot of this, either here or on the Github issue I've created to track this?

Left is the old version, right is the new version. You can see that the font is bigger, and the minimum size of the window is bigger (you cant make it smaller) this also means that when you load it the first time, it's smaller than it should be, and some of the names get "shortened". I now reproduced it by giving a new template a unreasonable long name:

You can see the Ascii symbol between "I" and "how"
AS mentioned, this is purely cosmetical.

arnoo wrote on 2023-06-01, 14:59:

I first started looking at VCS's code because of this exact thing, wondering if there was anything that could be done.
Although it cannot be done in a 100% accurate way that would work in all situations (that's just the nature of the analog signal), I've got some ideas for how to maybe do this in a way that's good enough for some situations.
I've got to get a lot more familiar with the code before I can even start investigating this though, so that's a long term thing 😀

I was also looking into other ways of handling it. Like changing dos textmode to 720x401 pixel for example, so that it can be distinguished. I mean when my PC boots its actually in 640x480, it just switches to 720x400 after that. But couldnt find any solution.

I also thought about processes how to distinguish these via script automatically. And while that's easy on paper, you also dont want that check to be done like 30 times per second. And you dont want to trigger it when it shouldn't.
Like you could just count the colors on screen (usually 720x400 programms only have very few colors). But then your 320x200 game might get a black loading screen and you'd get thrown back (wouldnt be tradic if its just black, but you get my point).
Maybe one preset element could try to see how many "different" pixels get lost when compressing it to 320x200. And if its too many stay at 720x400 and then have two output gates for each condition. But would be quite complicated to implement, and possible CPU intensive, and again, you dont want ti to switch back randomly.

Kordanor wrote on 2023-06-01, 17:56:

vvbee wrote on 2023-06-01, 04:22:

If you want to switch between 720 x 40o and 640 x 400 manually, use the numpad shortcuts for input resolution. Presets should activate accordingly.

I am not sure what you mean (i also want to change between two settings dealing with the same resolution (as it arrives in VCS), both being 720x400, the one "masking" 320x200, the other being "true" 720x400).
Numpad keys dont seem to do anything. CTRL+1...9 switches resolutions but I didnt follow the logic (it neither uses the order of presets nor the resolution screen)

The input resolution shortcuts map the numpad layout to the layout of the buttons in the input resolution dialog - 7 activates the top left button, etc. You can modify the UI buttons' resolutions with Alt + click or whatever it was.

If your source resolution changes to 640 x 400 then you manually switch the input resolution to 640 x 400 and the preset for 640 x 400 should activate if it's set to activate for that input resolution. If you want the output dimensions of it to be the same as for 720 x 400 then an output scaler should do it.

Ah, alright.
Well, the issue is different though.
While internally it's 320x200 its being "rendered" as 720x400.. If you crop it to 320x200, you will only get part of the picture. So that is not working.

So far I have seen 3 cases of "different" versions of 720x400:

1.
720x400 -> DOS and DOS Commander. This really is 720x400. Rescaling this to 720x400 will result into carbage. So the resolution needs to be kept and then upscaled if wished.

2.
720x400-> VGA Games like Duke Nukem which are actually running on 320x200. These need to be downscaled to 320x200 before they can be upscaled. Otherwise it will result in a blurry mess (not as much as garbage as the prev point).
With my current setup (without the extron) it uses the same preset as 1. and is fine. But needs to be processed differently. I am not sure if with the extron it had different results.

3.
720x400-> EGA Games like Keen 1, which are actually running on 320x200. This however is running on 71Hz (rounded). So it's possible to capture it with a different preset. And this is also needed! Using the same preset will reset in muddy pixels. So this uses a different preset than 1. but it needs to be processed like 1. (btw without extron 1 pixel on the right side is cut off, but thats likely an issue with the datapath)

To put it into a graph:

With my current setup case 1 and 2 use the same preset. I am not sure if that is always true (I think with extron I needed 2 different ones, but wouldnt swear on it)
While Case 3 can be handled with a different preset, you cannot set a different input gate for it.
Having additional options for input gates would solve this issue with case 3, but it would still make it impossible to tell between case 1 or 2. For now I only see a hotkey as "easy" solution. But that would need to be a hotkey for a preset, which ideally works windows wide (so you could also put it on a streamdeck or a function key on the keyboard)

Different presets are sometimes needed for the same-ish video mode, so there's activation by resolution and/or refresh rate and/or hotkey. Hotkeys not working is probably along the lines of me having forgotten to restore them after refactoring, but I haven't looked into it.

Blurry messes are likely a problem with the video source or analog capture settings. Try a different video card.

One possible way to automatically detect 720 vs 640 would be to write a TSR that detects video mode changes or other signs that a game was launched and flashes a signal when it happens, then have an image filter in VCS that detects the signal, discards the frame and tells VCS to do whatever.

vvbee wrote on 2023-06-04, 17:28:

Blurry messes are likely a problem with the video source or analog capture settings. Try a different video card.

The video source is nice. It's all about how it is captured. So far I didnt see anything which I couldn't process pretty much perfectly.
The only issue with capture is the visionRGB in 640x480 with cutting off the bottom 3 or so pixels (with Extron changed to just 1). This is a common issue with the capture card, as was also pointed out in the VGA thread. And I think EGA 320x200 is cutting off the last pixel on the right.

One possible way to automatically detect 720 vs 640 would be to write a TSR that detects video mode changes or other signs that a game was launched and flashes a signal when it happens, then have an image filter in VCS that detects the signal, discards the frame and tells VCS to do whatever.

For now 720 vs 640 is no issue with detecting. It's just a bug that the preset for 640x480 isn't applied correctly (it lights up but the width is not applied unless you increase, decrease size, as shown in my video)

The issue is 720x400 vs 320x200. Ofc the "flash" would be an option. But I guess it's not easy to implement - and we'd still need the other implementations to even utilize the changes. (like switching between processing types / having the filter graph being preset based)

640 x 400 I mean. I'm currently not looking into the 640 x 480 issue either since I'm doing other things but I'm sure it's fixable easily enough. It could be a driver bug too.

Writing the TSR and getting reliable results with it would be some amount of messing around, assuming it's possible. I'm not planning on doing it, but someone might.

A recent commit merges the individual GUI dialogs into a single control panel. Also improves UI functionality here and there, and removes a few things. Work in progress as always. More or less all INI file settings are reset, best to move the old INI file out of the way to have the program generate a fresh one without all the old gunk.

Should be possible to import the change into the Windows version, but a bit of work. This is where you don't want to be using a wildly different version of Qt to break extra things here and there.

That looks great!

Should be possible to import the change into the Windows version, but a bit of work. This is where you don't want to be using a wildly different version of Qt to break extra things here and there.

Of course if I wanted to make it as easy as possible, I should have kept the same version of Qt.
But on hobby projects, I need to inject a bit of fun 😀

But it wasn't too difficult of a merge in the end!