VOGONS

Common searches


Reply 341 of 733, by Serious Callers Only

User metadata
Rank Member
Rank
Member

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-06-18, 01:38. Edited 1 time in total.

Reply 342 of 733, by KainXVIII

User metadata
Rank Member
Rank
Member
lukeman3000 wrote:

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

No black borders (horizontal, depends on resolution of your monitor 😎 )

Last edited by KainXVIII on 2017-06-18, 10:01. Edited 2 times in total.

Reply 343 of 733, by Serious Callers Only

User metadata
Rank Member
Rank
Member

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.

Reply 344 of 733, by Ant_222

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

Reply 345 of 733, by Ant_222

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

Reply 346 of 733, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
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-06-18, 22:27. Edited 1 time in total.

Reply 347 of 733, by Ant_222

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

Reply 348 of 733, by KainXVIII

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

Reply 349 of 733, by Ant_222

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

Reply 350 of 733, by KainXVIII

User metadata
Rank Member
Rank
Member
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? 😀
But here you go

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-06-19, 10:26. Edited 1 time in total.

Reply 351 of 733, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 352 of 733, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie

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!

Attachments

  • Filename
    dosbox-pixelscale.zip
    File size
    147.76 KiB
    Downloads
    56 downloads
    File license
    Fair use/fair dealing exception
Last edited by Ant_222 on 2017-06-21, 21:05. Edited 4 times in total.

Reply 353 of 733, by Ant_222

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

Reply 354 of 733, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 355 of 733, by Ant_222

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

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.

Reply 356 of 733, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie

Ant,

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

https://zerobin.net/?10fcc30a9c241373#cnsGNVd … celcXaEGN9UKe8=

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.

Reply 357 of 733, by Solanacean

User metadata
Rank Newbie
Rank
Newbie

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?

Attachments

Reply 358 of 733, by Ant_222

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