VOGONS

Common searches


Reply 660 of 733, by Yesterplay80

User metadata
Rank Oldbie
Rank
Oldbie

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?

My full-featured DOSBox SVN builds for Windows & Linux: Vanilla DOSBox and DOSBox ECE (Google Drive Mirror)

Reply 661 of 733, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
Yesterplay80 wrote:

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.

Reply 662 of 733, by MT_

User metadata
Rank Newbie
Rank
Newbie
Yesterplay80 wrote:

.

Fwiw, looks like the English version of the DOSBox ECE page is not available anymore:

404: Seite nicht gefunden
Unter dieser Adresse wurde nichts gefunden. Möglicherweise hilft eine Suche oder einer der Links unterhalb?

Is that intentional? Thanks.

Reply 663 of 733, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
MT_ wrote:

Fwiw, looks like the English version of the DOSBox ECE page is not available anymore [...] Is that intentional?

I don't know. Ask its author, Yesterplay80 in the thread about DOSBox ECE.

Reply 665 of 733, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
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:

  1. A pixel shader for pixel-perfect scaling,
  2. BladeSk's patch, and
  3. My patch.

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.

Reply 666 of 733, by lukeman3000

User metadata
Rank Member
Rank
Member
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:

  1. A pixel shader for pixel-perfect scaling,
  2. BladeSk's patch, and
  3. My patch.

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.

Reply 667 of 733, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
lukeman3000 wrote:

Please don't stop.

I will try...

lukeman3000 wrote:

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.

Reply 668 of 733, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie
Ant_222 wrote:
lukeman3000 wrote:

Please don't stop.

I will try...

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).

Reply 669 of 733, by KainXVIII

User metadata
Rank Member
Rank
Member
lukeman3000 wrote:

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.

scu.jpg
Filename
scu.jpg
File size
42.62 KiB
Views
1740 views
File license
Fair use/fair dealing exception

Reply 670 of 733, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie
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?

That's what openglnb output does.

Reply 671 of 733, by KainXVIII

User metadata
Rank Member
Rank
Member
jmarsh wrote:
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?

That's what openglnb output does.

Not surfacenp? Unfortunately it will be performance hog in current implementation.

Reply 672 of 733, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie
jmarsh wrote:

That's what openglnb output does.

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.

Reply 673 of 733, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie

openglnb is exactly the same as opengl but with nearest neighbour (i.e. integer scaling) instead of bilinear filtering.

Not sure what your definition of "integer scaling" is, but duplicating rows/columns is what it does when enlarging images.

Last edited by jmarsh on 2019-09-04, 11:19. Edited 1 time in total.

Reply 674 of 733, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
KainXVIII wrote:

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.

Reply 675 of 733, by KainXVIII

User metadata
Rank Member
Rank
Member
Ant_222 wrote:
KainXVIII wrote:

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.

I think its just integer scaler with added black borders (if needed)

Reply 676 of 733, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie
Ant_222 wrote:
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.

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.

Reply 677 of 733, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
krcroft wrote:
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?

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.

Reply 678 of 733, by KainXVIII

User metadata
Rank Member
Rank
Member

@ant_222, here you go, btw, screenshots from latest ScummVM build (aspect correction on, 1080p)

The Legend of Kyrandia (Extracted_DOS_Russian) 05.09.2019 10_34_43.png
Filename
The Legend of Kyrandia (Extracted_DOS_Russian) 05.09.2019 10_34_43.png
File size
229.67 KiB
Views
1707 views
File license
Fair use/fair dealing exception
The Legend of Kyrandia (Extracted_DOS_Russian) 05.09.2019 10_36_09.png
Filename
The Legend of Kyrandia (Extracted_DOS_Russian) 05.09.2019 10_36_09.png
File size
271.52 KiB
Views
1707 views
File license
Fair use/fair dealing exception

Reply 679 of 733, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
KainXVIII wrote:

@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":

320x200 --[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.