Patch for pixel-perfect scaling

Here you can discuss the development of patches.

Re: Patch for pixel-perfect scaling

Postby lukeman3000 » 2017-6-17 @ 21:48

Ant; why, in general, do people prefer surfacenp over surfacepp?
lukeman3000
Member
 
Posts: 129
Joined: 2009-3-17 @ 00:59

Re: Patch for pixel-perfect scaling

Postby Serious Callers Only » 2017-6-17 @ 21:53

I'd like to built in this patch to my dosbox ppa, but the munt conflict concerns me. I keep munt mt32emu dosbox patch always to its latest version by copying the source and the patch direct from their git on the ppa recipe, and a conflict like this would prevent me doing that, with the alternative of just use your 'forked' patch instead of theirs. What i'm really asking is: can the conflict be solved in another way in your own patch or by submitting a 'fix' to theirs so that both upstream munt dosbox patch and yours can coexist?

Alternatively, if you submit this to upstream dosbox and it is accepted, this problem would disappear eventually.
Last edited by Serious Callers Only on 2017-6-18 @ 01:38, edited 1 time in total.
Serious Callers Only
Member
 
Posts: 284
Joined: 2003-4-26 @ 21:34

Re: Patch for pixel-perfect scaling

Postby KainXVIII » 2017-6-17 @ 22:22

lukeman3000 wrote:Ant; why, in general, do people prefer surfacenp over surfacepp?

No black borders (horizontal, depends on resolution of your monitor :cool: )
Last edited by KainXVIII on 2017-6-18 @ 10:01, edited 2 times in total.
User avatar
KainXVIII
Member
 
Posts: 172
Joined: 2015-5-20 @ 15:04
Location: Yaroslavl

Re: Patch for pixel-perfect scaling

Postby Serious Callers Only » 2017-6-18 @ 01:28

I don't really dislike column black borders, but i really dislike the bottom and top ones and the way some graphics modes in dosbox stretch horizontally. There's a way to avoid it* on my graphics drivers (mesa), but it often fails when the game changes resolution as happens very often in windows 95 games**. This mode sounds like it should fix this and be on upstream yesterday, especially now with huge widescreen monitors.

*
fullresolution=desktop
windowresolution=desktop
output=openglnb

** on these, i often have to change fullresolution to 'original' and eat the resolution change showing the desktop (ugly!) or the said blackboxing/widescreen distortion after the res change.
Serious Callers Only
Member
 
Posts: 284
Joined: 2003-4-26 @ 21:34

Re: Patch for pixel-perfect scaling

Postby Ant_222 » 2017-6-18 @ 22:08

krcroft wrote:I would be happy to try to help by getting profiling data for you. I'm a big fan and user of your patch on my general linux machine and would love to see this get wider adoption into retropie's dosbox distribution.
Very well, I will post the test program here as soon as time permits.
Ant_222
Member
 
Posts: 247
Joined: 2010-7-24 @ 21:29

Re: Patch for pixel-perfect scaling

Postby Ant_222 » 2017-6-18 @ 22:13

lukeman3000 wrote:Ant; why, in general, do people prefer surfacenp over surfacepp?
I have no idea. I know hard-core retrogamers on other platforms that use a technique identical to mine. In Amiga they call it the 5-by-6 method, because 6x5 is the optimal upscaling of the Amiga 320x200 mode. Whereas classic games are practically made of pixel art, I believe that sharp and regular pixels are more important that filling the whole monitor (especially now that monitors are huge) or keeping the exact aspect ratio.
Ant_222
Member
 
Posts: 247
Joined: 2010-7-24 @ 21:29

Re: Patch for pixel-perfect scaling

Postby Ant_222 » 2017-6-18 @ 22:20

Serious Callers Only wrote:I'd like to built in this patch to my dosbox ppa, but the munt conflict concerns me. I keep munt mt32emu dosbox patch always to its latest version by copying the source and the patch direct from their git on the ppa recipe, and a conflict like this would prevent me doing that, with the alternative of just use your 'forked' patch instead of theirs. What i'm really asking is: can the conflict be solved in another way in your own patch or by submitting a 'fix' to theirs so that both upstream munt dosbox patch and yours can coexist?
The last time someone told me about this conflict, it was in a single make file, and I thought I fixed it. Where is the conflict currently?
Serious Callers Only wrote:Alternatively, if you submit this to upstream dosbox and it is accepted, this problem would disappear eventually.
The authors and maintainers of DOXBox are aware of my patch. For the reasons stated above, I do wish they would include it into the mainstream SVN.
Last edited by Ant_222 on 2017-6-18 @ 22:27, edited 1 time in total.
Ant_222
Member
 
Posts: 247
Joined: 2010-7-24 @ 21:29

Re: Patch for pixel-perfect scaling

Postby Ant_222 » 2017-6-18 @ 22:26

Serious Callers Only wrote:fullresolution=desktop
windowresolution=desktop
output=openglnb
Even though that does not use my scaling algorithm, the desktop option for windowed mode is introduced in my patch (albeit clumsily :-)
Ant_222
Member
 
Posts: 247
Joined: 2010-7-24 @ 21:29

Re: Patch for pixel-perfect scaling

Postby KainXVIII » 2017-6-19 @ 08:46

Ant_222 wrote:
lukeman3000 wrote:Ant; why, in general, do people prefer surfacenp over surfacepp?
I have no idea. I know hard-core retrogamers on other platforms that use a technique identical to mine. In Amiga they call it the 5-by-6 method, because 6x5 is the optimal upscaling of the Amiga 320x200 mode. Whereas classic games are practically made of pixel art, I believe that sharp and regular pixels are more important that filling the whole monitor (especially now that monitors are huge) or keeping the exact aspect ratio.

Some games (like Ravenloft) with unusual resolutions does not scale well with surfacepp (filling very little of screen space, at least on 1080p monitor)
User avatar
KainXVIII
Member
 
Posts: 172
Joined: 2015-5-20 @ 15:04
Location: Yaroslavl

Re: Patch for pixel-perfect scaling

Postby Ant_222 » 2017-6-19 @ 09:18

KainXVIII wrote:Some games (like Ravenloft) with unusual resolutions does not scale well with surfacepp (filling very little of screen space, at least on 1080p monitor)
Ravenloft - Strahd's Possession?

Is it designed for 4:3 monitors? What does surfacepp show in the debug output?
Ant_222
Member
 
Posts: 247
Joined: 2010-7-24 @ 21:29

Re: Patch for pixel-perfect scaling

Postby KainXVIII » 2017-6-19 @ 09:46

Ant_222 wrote:
KainXVIII wrote:Some games (like Ravenloft) with unusual resolutions does not scale well with surfacepp (filling very little of screen space, at least on 1080p monitor)
Ravenloft - Strahd's Possession?

Is it designed for 4:3 monitors? What does surfacepp show in the debug output?

I thing we already discussed that game? :happy:
But here you go
Code: Select all
Available area: 1920x1080
Scaling: 320x400 (0.60) --[3.0 x 2.0]-->  960x800  (0.67)
Available area: 1904x1038
Scaling: 320x400 (0.60) --[3.0 x 2.0]-->  960x800  (0.67)
Last edited by KainXVIII on 2017-6-19 @ 10:26, edited 1 time in total.
User avatar
KainXVIII
Member
 
Posts: 172
Joined: 2015-5-20 @ 15:04
Location: Yaroslavl

Re: Patch for pixel-perfect scaling

Postby Ant_222 » 2017-6-19 @ 09:52

KainXVIII, Indeed. I plumb forgot. I feared there was a bug in the patch, but it works with this game as expected.

Edit: It seems a true 320x400 resolution rather than the usual 320x200 upscaled vertically.
Ant_222
Member
 
Posts: 247
Joined: 2010-7-24 @ 21:29

Re: Patch for pixel-perfect scaling

Postby Ant_222 » 2017-6-21 @ 19:59

I wrote to krcroft:
Ant_222 wrote:Very well, I will post the test program here as soon as time permits.
The program is attached. Let me know if you need any further assistance in compiling, running, or benchmarking.

Edit: This code is somewhat messy because of my decision to implement all the three scalers in a single generic mechanism. I should prefer to leave only the pixel-perfect scaler, but if people find the other ones—surfacenb and surfacenp—also useful, the only alternative is to extract the pixel-perfect code into a separate small routine to facilitate optimization.

The original and now-lost implementation of xBRZ for DOSBox was multi-threaded—something of which my patch might avail also!
You do not have the required permissions to view the files attached to this post.
Last edited by Ant_222 on 2017-6-21 @ 21:05, edited 4 times in total.
Ant_222
Member
 
Posts: 247
Joined: 2010-7-24 @ 21:29

Re: Patch for pixel-perfect scaling

Postby Ant_222 » 2017-6-21 @ 20:12

Ant_222 wrote:
Serious Callers Only wrote:I'd like to built in this patch to my dosbox ppa, but the munt conflict concerns me. I keep munt mt32emu dosbox patch always to its latest version by copying the source and the patch direct from their git on the ppa recipe, and a conflict like this would prevent me doing that, with the alternative of just use your 'forked' patch instead of theirs. What i'm really asking is: can the conflict be solved in another way in your own patch or by submitting a 'fix' to theirs so that both upstream munt dosbox patch and yours can coexist?
The last time someone told me about this conflict, it was in a single make file, and I thought I fixed it. Where is the conflict currently?
Both munt and my patch add new files to /src/gui and therefore modify src/gui/Makefile.am, which is merely a list of files. Whereas the patches are contextual, such changes, if made within the context range, always produce a conflict.

Do any programmers here know how this situation may be resolved within the framework of Automake?
Ant_222
Member
 
Posts: 247
Joined: 2010-7-24 @ 21:29

Previous

Return to DOSBox Patches

Who is online

Users browsing this forum: No registered users and 2 guests