VIDEO Patch for pixel-perfect scaling (SDL1)

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: 188
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: 331
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: 216
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: 331
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: 330
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: 330
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: 330
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: 330
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: 216
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: 330
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: 216
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: 330
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: 330
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: 330
Joined: 2010-7-24 @ 21:29

Re: Patch for pixel-perfect scaling

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

Re: conflict with munt, I have asked about it in the Automake mailing list and one reader said that:
  • Such conflicts at the level of .am files are usual and trivial to resolve manually.
  • They can be reduced by rearranging file lists with one file per line and sorting them alphabetically, so as to decrease the probability that changes occur near one another.
I will request the latter modification in the Development section. Edit: Done.
Ant_222
Member
 
Posts: 330
Joined: 2010-7-24 @ 21:29

Re: Patch for pixel-perfect scaling

Postby Ant_222 » 2017-6-23 @ 20:49

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?
No that we know there is little hope for a solution in the official DOSBox, I can tell you that yes, the conflict can be resolved by using a version of
Code: Select all
src/gui/Makefile.am
customized especially for the two patches. One need only add there the new files introduced both in my patch and in munt. At the level of actual source code (*.cpp and *.h) the patches do not seem to conflict. Will you consider writing such a consolidated Makefile.am or will you let me do it?

krcroft, any good news about profiling?

Edit: The Ehanced Community Edition of DOSBox by Yesterplay80 contains both the Pixel-Perfect and munt patches, so you might take the problematic .am file thence.
Ant_222
Member
 
Posts: 330
Joined: 2010-7-24 @ 21:29

Re: Patch for pixel-perfect scaling

Postby krcroft » 2017-6-25 @ 03:41

Ant,

Profile data is below, and the full output describing kernel, gcc version, and make log is pasted here:

https://zerobin.net/?10fcc30a9c241373#c ... aEGN9UKe8=

When building with 'production' optimizations (such as Ofast or O3) ps_scale dominates to 100% and no other function shows in the list.
Unfortunately not too helpful given ps_scale is the primary work-horse function, but at least you know the time is going purely into its own lines as opposed to being eaten by the functions that it calls.

Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds seconds calls ms/call ms/call name
99.91 7.05 7.05 512 13.78 13.78 ps_scale(ps_info_internal*, ps_pixels, ps_pixels, ps_rect*)
0.14 7.06 0.01 1 10.01 10.01 new_info(ps_format_in, ps_size, ps_format_out, ps_size, unsigned char, double, char, char)
0.00 7.06 0.00 10 0.00 0.00 free_if_not_null(void*)
0.00 7.06 0.00 2 0.00 0.00 FreeRaw(char const*)
0.00 7.06 0.00 2 0.00 0.00 li_get(unsigned int, double, double)
0.00 7.06 0.00 1 0.00 10.01 ps_new_perfect(ps_format_in, ps_size, ps_format_out, ps_size, char, char, unsigned char, double, ps_size*)
0.00 7.06 0.00 1 0.00 0.00 ReadRaw(char const*, int, int, char**)
0.00 7.06 0.00 1 0.00 0.00 ps_free(ps_info_internal*)
0.00 7.06 0.00 1 0.00 0.00 WriteRaw(char*, int, int, char const*)
0.00 7.06 0.00 1 0.00 0.00 handle_dwh_new(char, char, ps_format_in*, ps_size*, double*)


On the rpi, SDL interfaces with a hardware scaler called dispmanx that will scale the source (ie: 320x200, dosbox output=surface, scale=none) up to the native display size provided the source resolution is at least 2x smaller than the physical display resolution. If the incoming resolution is a ratio less than 2x then the frame is passed through (which happens if dosbox perform the scaling as in scale=normalNx, or output=surfacepp). dispmanx is a very fast hardware scaler; it's this second scenario when dosbox does the scaling in software that is much slower (although normal2x is generally OK)

One possibility might be generating the smallest output surface that maps into an "integer-clean" ratio to the physical display resolution, to avoid performing the scaling in software and yet also ensure the hardware/TV scaler doesn't interpolate pixels. For example, normally a 200 pixel-tall source would be hardware-stretched to 3.6x to fit a 1280x720 display, but if we pre-padded our 200 pixels with 20 black lines on the top and bottom (producing a 240 pixel source), then the hardware scaler would be a pixel-exact 720/240 = 3.0. This doesn't solve the 4:3 aspect ratio problem, but it does let us get pixel-exact output with dumb/interpolating hardware scalers.
krcroft
Newbie
 
Posts: 16
Joined: 2017-4-29 @ 15:07

Re: Patch for pixel-perfect scaling

Postby Solanacean » 2017-7-12 @ 19:52

I'm having a weird problem with my OS X build when using any of the pixel-perfect modes, see the attached screenshots. Any ideas what could cause this and how to fix it?
You do not have the required permissions to view the files attached to this post.
Solanacean
Newbie
 
Posts: 21
Joined: 2017-4-03 @ 00:00
Location: Russia

Re: Patch for pixel-perfect scaling

Postby Ant_222 » 2017-7-12 @ 20:01

Solanacean wrote:I'm having a weird problem with my OS X build when using any of the pixel-perfect modes, see the attached screenshots. Any ideas what could cause this and how to fix it?
Not yet, but it looks like a bug in my patch. Does it happen in fullscreen too?
Ant_222
Member
 
Posts: 330
Joined: 2010-7-24 @ 21:29

Re: Patch for pixel-perfect scaling

Postby Ant_222 » 2017-7-12 @ 20:07

Solanacean, please post a screenshot of the DOSBox debugging console and the settings you used with surfacepp.
Ant_222
Member
 
Posts: 330
Joined: 2010-7-24 @ 21:29

PreviousNext

Return to DOSBox Patches

Who is online

Users browsing this forum: cheshirenoir and 1 guest