Unfortunately, the Vsync option wasn't the culprit, the problem persist with the attached build. I'll try to record the problem and ask in the OBS forums, though I doubt they'll have a solution without OBS showing an errr. But who knows?
Unfortunately, the Vsync option wasn't the culprit, the problem persist with the attached build. I'll try to record the problem and ask in the OBS forums, though I doubt they'll have a solution without OBS showing an errr. But who knows?
Thank you. OBS is open-source. If they are very kind to us, they can debug it and see what happens inside.
I suggest that you contact the maintainer of an OS X build with a proposal to implement one of the listed solutions. I can help with the generic algorithm of aspect-ratio approximation because some people don't make it right the fist time.
I should very much like to see the patch included into the official DOSBox, where I should be able to maintain and improve it without a constant fear that another commit breaks the patch compatibility. If I stop maintaining it, the patch will probably die because it won't work with new versions of DOSBox. Ideally, this should not happen before DOSBox adds support of pixel shaders or incorporates my patch or its analog.
Ant_222 wrote:I am very glad you like it, but don't know of any OS X build with my patch. Currently I see three ways to pixel-perfect display […] Show full quote
citrixscu wrote:
Are there any builds for OSX that has this patch included? It’s awesome on Windows.
I am very glad you like it, but don't know of any OS X build with my patch. Currently I see three ways to pixel-perfect display in DOSBox:
I suggest that you contact the maintainer of an OS X build with a proposal to implement one of the listed solutions. I can help with the generic algorithm of aspect-ratio approximation because some people don't make it right the fist time.
I should very much like to see the patch included into the official DOSBox, where I should be able to maintain and improve it without a constant fear that another commit breaks the patch compatibility. If I stop maintaining it, the patch will probably die because it won't work with new versions of DOSBox. Ideally, this should not happen before DOSBox adds support of pixel shaders or incorporates my patch or its analog.
Please don't stop. Your patch is one of the main reasons I continue to use DOSBox over ScummVM (btw, does ScummVM have anything similar to the pixel perfect patch at this point, or is the PAR still messed up when playing games with ScummVM?)
This is such a great patch. Does the most recent version of ECE feature the most updated version of the patch?
Also; was this or anything like it ever implemented?
If pixel-perfect correction is unsatisfactory, either because of a large aspect-ratio error or because of insufficient magnification, fall-back to a simpler scaling mode, such as nearest-neighbor. The secondary scaling mode and the exact criterium for the fallback may be specified in the config file.
Your patch is one of the main reasons I continue to use DOSBox over ScummVM (btw, does ScummVM have anything similar to the pixel perfect patch at this point, or is the PAR still messed up when playing games with ScummVM?)
I think not, and it is very strange that the developers of retro-gaming emulators have failed to implement this simplest and most obvious scaling method and continue to use blurry interpolation available by default in their videocards and GFX APIs. I for one am forced to use DOS-versions of ZX Spectrum and SNES emulators inside a patched DOSBox in order to have normal pixel-perfect output!
This is such a great patch. Does the most recent version of ECE feature the most updated version of the patch?
I think it does because YP80 has confirmed the correction of a bug in the latest version.
Also; was this or anything like it ever implemented?
If pixel-perfect correction is unsatisfactory, either because of a large aspect-ratio error or because of insufficient magnification, fall-back to a simpler scaling mode, such as nearest-neighbor. The secondary scaling mode and the exact criterium for the fallback may be specified in the config file.
No. Do you feel the need of it often? I don't.
The most urgent problem with the patch is that it seems to break compatibility with some video streaming software, e.g. OBS, and I am not able to reproduce the problem in order to tell about it at the OBS forum or mailing list. I should be grateful if you, or anybody else, could help with that.
Given whole-integer scaling is straight forward, more accurate on modern high-DPI displays (versus the existing double-every Nth line method), can be implemented along side the current scaling methods without influence on their performance or function, and doesn't require exotic underlying interfaces (driver or vendor-specific calls, latest-gen GL API, or Vulcan),
is there any logical argument why this wouldn't be a candidate for inclusion in the baseline version of DOSBox?
(Not saying this patch specifically.. just the concept itself. Crisp integer scaling itself has become a hot topic amung video card vendors and their drivers).
Please don't stop. Your patch is one of the main reasons I continue to use DOSBox over ScummVM (btw, does ScummVM have anything similar to the pixel perfect patch at this point, or is the PAR still messed up when playing games with ScummVM?)
ScummVM has added pixel-perfect mode (in daily builds) a year ago, i guess. Works as intended.
Given whole-integer scaling is straight forward, more accurate on modern high-DPI displays (versus the existing double-every Nth line method), can be implemented along side the current scaling methods without influence on their performance or function, and doesn't require exotic underlying interfaces (driver or vendor-specific calls, latest-gen GL API, or Vulcan),
is there any logical argument why this wouldn't be a candidate for inclusion in the baseline version of DOSBox?
Given whole-integer scaling is straight forward, more accurate on modern high-DPI displays (versus the existing double-every Nth line method), can be implemented along side the current scaling methods without influence on their performance or function, and doesn't require exotic underlying interfaces (driver or vendor-specific calls, latest-gen GL API, or Vulcan),
is there any logical argument why this wouldn't be a candidate for inclusion in the baseline version of DOSBox?
That's what openglnb output does.
Not surfacenp? Unfortunately it will be performance hog in current implementation.
My understanding from Ant's explanation is that openglnb applies the same 'duplicate every Nth line' distortion across both axis to maintain correct aspect ratio.
From Ant:
Setting aspect to true causes DOSBox to compensate for a non-square original aspect ratio by applying a variable integer magnification to different rows of pixels of the input image. For example, in case of an original aspect ratio of 1.2 and no scaling, DOSBox will double every fifth row, as can be seen in this screenshot of the DOSBox welcome screen.
The other output types stretch the source image proportionally to the dimensions of the output area producing a distorted result. The output types overlay, ddraw, and opengl employ interpolation, which results in a blurry picture, whereas openglnb employs a technique similar to that used for aspect correction but applies it to both rows and columns.
ScummVM has added pixel-perfect mode (in daily builds) a year ago, i guess. Works as intended
Please, post several ScummVM screenshots of different sizes taken in pixel-perfect mode. I will tell you the algorithm.
krcroft wrote:
My understanding from Ant's explanation is that openglnb applies the same 'duplicate every Nth line' distortion across both axis to maintain correct aspect ratio.
nb stands for nearest-neighbor. In the general case, it is not the duplication of every nth row or column. For example, in order to upscale by a factor of 2.5, the nearest-neighbor interpolation will duplicate and triplicate pixels alternatively: 2, 3, 2, 3, &c—yielding an average magnification of 2.5.
krcroft wrote:
Given whole-integer scaling is straight forward, more accurate on modern high-DPI displays (versus the existing double-every Nth line method), can be implemented along side the current scaling methods without influence on their performance or function, and doesn't require exotic underlying interfaces (driver or vendor-specific calls, latest-gen GL API, or Vulcan), is there any logical argument why this wouldn't be a candidate for inclusion in the baseline version of DOSBox?
(Not saying this patch specifically.. just the concept itself.
I do not see such an argument. An efficient implementation is actually possible even with the obsolete SDL 1.2 that the official DOSBox uses, if one takes advantage of the built-in nearest-neighbor scaling in OpenGL mode and confines the output area to one whose size is a multiple of the original resolution. This method is implemented in my patch (openglpp) and bladesk's.
My understanding from Ant's explanation is that openglnb applies the same 'duplicate every Nth line' distortion across both axis to maintain correct aspect ratio.
nb stands for nearest-neighbor. In the general case, it is not the duplication of every nth row or column. For example, in order to upscale by a factor of 2.5, the nearest-neighbor interpolation will duplicate and triplicate pixels alternatively: 2, 3, 2, 3, &c—yielding an average magnification of 2.5.
Thanks for the clarifying how openglnb distorts the scaling at fractional ratios; and for confirming that openglnb is not a replacement or equivalent for your patch.
Ant_222 wrote:
I do not see such an argument. An efficient implementation is actually possible even with the obsolete SDL 1.2 that the official DOSBox uses, if one takes advantage of the built-in nearest-neighbor scaling in OpenGL mode and confines the output area to one whose size is a multiple of the original resolution. This method is implemented in my patch (openglpp) and bladesk's.
Excellent! Sounds like that would cover almost all the use cases, given OpenGL is ubiquitous. Do you know if QBix is aware of this specific subset of pixel-perfect scaling, and what his thoughts are in terms of adding it?
On my Pi3, I currently run DOSBox's surface renderer backed by the hardware's dispmanx driver. I'm waiting to pick up a Pi4, but suspect it will have enough compute-power to run your PP surface scalar for most games that need no more than a 486/33. The Pi does support OpenGL ES (GLES) in hardware, but SDL1.2 can't take advantage of it (have to wait for SDL2 for that). Moving to SDL2 will let users offload openglpp in hardware free up those compute cycles for more DOSBox performance.
I do not see such an argument. An efficient implementation is actually possible even with the obsolete SDL 1.2 that the official DOSBox uses, if one takes advantage of the built-in nearest-neighbor scaling in OpenGL mode and confines the output area to one whose size is a multiple of the original resolution. This method is implemented in my patch (openglpp) and bladesk's.
Excellent! Sounds like that would cover almost all the use cases, given OpenGL is ubiquitous. Do you know if QBix is aware of this specific subset of pixel-perfect scaling, and what his thoughts are in terms of adding it?
He knows about my patch and dislikes the amount of changes I have introduced, for I could have done it with less. I am not sure, however, that he is aware of the idea to emulate pixel-perfect scaling via OpenGL. I am on vacation now and do not have the time for a serious discussion with the developers. I don't know their position with regard to this feature and whether a petition or a poll could change their opinion about the necessity of pixel-perfect scaling in DOSBox.
@ant_222, here you go, btw, screenshots from latest ScummVM build (aspect correction on, 1080p)
Bad news: both the screenshots use nearest-neighbor interpolation and have irregular pixel magnification, which means that the ScummVM developers not only have failed to implement pixel-perfect scaling, but also are deceiving their users by calling nearest-neighbor interpolation to the correct aspect ratio "pixel-perfect":
1320x200 --[4.0x4.8]--> 1280x960
—only the horizontal scale is integral, whereas the vertical one is a fractional. It makes no sense.
Edit: To clarify—the rows in the "pixel-perfect" screenshot are magnified with alternating scales of 4 and 5 in a ratio of 1 to 4: 4, 5, 5, 5, 5, 4, 5, 5, 5, 5, ... yielding an average vertical scale of 24/5, or 4.8.