lightmaster wrote:

Daum is bugged.
He put *near* perfect, you know?

No, I know nothing about it. Do you mean ykhwong has some other patch in his build that implements scaler-independent oversampling and downscaling with interpolation?

Ant_222 wrote:

lightmaster wrote:

Daum is bugged.
He put *near* perfect, you know?

No, I know nothing about it. Do you mean ykhwong has some other patch in his build that implements scaler-independent oversampling and downscaling with interpolation?

I wrote "something like", i don't think he make patch for this.
Here is config for it (i already post it sometime ago)
output=direct3d
pixelshader=bilinear.fx
aspect=true
scaler=normal5x

KainXVIII wrote:

I wrote "something like", i don't think he make patch for this. Here is config for it (i already post it sometime ago) output=di […]
Show full quote

I wrote "something like", i don't think he make patch for this.
Here is config for it (i already post it sometime ago)
output=direct3d
pixelshader=bilinear.fx
aspect=true
scaler=normal5x

This has two drawbacks: a) reliance on a third-party Windows-only technology and b) reliance on hard-coded normal<n>x scalers.

Ant_222 wrote:

KainXVIII wrote:

I wrote "something like", i don't think he make patch for this. Here is config for it (i already post it sometime ago) output=di […]
Show full quote

I wrote "something like", i don't think he make patch for this.
Here is config for it (i already post it sometime ago)
output=direct3d
pixelshader=bilinear.fx
aspect=true
scaler=normal5x

This has two drawbacks: a) reliance on a third-party Windows-only technology and b) reliance on hard-coded normal<n>x scalers.

Yeah, but its only way to post "near" perfect screenshots on Steam (that i found). For everyday gaming i use your build 😀

Fain to hear that, KainXVIII.

I have just uploaded the source of alpha 4. It requires optimization—and I know how to profile it with gprof,—and minor refactoring. In the next release I am going to add support for non-standard color formats, such as that which the S3 machine uses. May I do it via on-the-fly conversion, or shall I adapt the algorithm to the surface output so as to avoid color conversion during scaling?

Hey Ant_222, I just tried to compile your Alpha 4 patch with a fresh check out of the current DOSBox SVN, but if fails with the following errors:

1make[3]: Entering directory `/home/<USERDIR>/dosbox/src/gui'
2g++ -DHAVE_CONFIG_H -I. -I../..  -I../../include -I/mingw/include/SDL -D_GNU_SOU
3RCE=1 -Dmain=SDL_main  -g -O2 -mno-ms-bitfields  -MT sdlmain.o -MD -MP -MF .deps
4/sdlmain.Tpo -c -o sdlmain.o sdlmain.cpp
5sdlmain.cpp:1214:2: error: expected initializer before 'if'
6  if (SDL_LockSurface(sdl.blit.surface)) {
7  ^
8sdlmain.cpp:1218:9: error: expected constructor, destructor, or type conversion
9before '=' token
10  *pixels=(Bit8u *)sdl.blit.surface->pixels;
11         ^
12sdlmain.cpp:1219:8: error: expected constructor, destructor, or type conversion
13before '=' token
14  *pitch=sdl.blit.surface->pitch;
15        ^
16sdlmain.cpp:1220:2: error: expected unqualified-id before 'return'
17  return 1;
18  ^
19sdlmain.cpp:1221:1: error: expected declaration before '}' token
20 }
21 ^
22make[3]: *** [sdlmain.o] Error 1
23make[3]: Leaving directory `/home/<USERDIR>/dosbox/src/gui'
24make[2]: *** [all-recursive] Error 1
25make[2]: Leaving directory `/home/<USERDIR>/dosbox/src'
26make[1]: *** [all-recursive] Error 1
27make[1]: Leaving directory `/home/<USERDIR>/dosbox'
28make: *** [all] Error 2

Yesterplay80 wrote:

Hey Ant_222, I just tried to compile your Alpha 4 patch with a fresh check out of the current DOSBox SVN, but if fails with the following errors:[...]

I beg your pardon. Fixed.

Ant_222 wrote:

I beg your pardon. Fixed.

No problem. Your fixed patch already found a home in my updated enhanced build.

@Ant_222
When overlaynp-sharpness=0, the interpolation algorithm is extremely slow with fade-ins and fade-outs.
This is noticeable in music stutters when there is a fade to black effect in games.
It happens only in fullscreen when the algorithm actually works, not in windowed mode.

In Warcraft 2 right before the main menu, and when you click Exit Program.

James-F wrote:

When overlaynp-sharpness=0, the interpolation algorithm is extremely slow with fade-ins and fade-outs.
This is noticeable in music stutters when there is a fade to black effect in games.

Right, which is why I said it needs further optimization. Zero sharpness means a maximum of interpolation, fade-ins and fade-outs require redrawing of the full frame, whence the CPU load.

It happens only in fullscreen when the algorithm actually works, not in windowed mode.

overlaynp should work, and does for me, in windowed mode as well. If you make the window the size of the desktop it should be slow too. Edit: See, for example, the attached screenshot from Battle Snake in a 1500x1000 window. It is near-perfectly interpolated.

FYI: I just tried to compile r4000 with your patch, but the file sdlmain.cpp underwent several changes in r3999 and hunks #12 and #13 of your patch won't apply any more.

Yesterplay80 wrote:

FYI: I just tried to compile r4000 with your patch, but the file sdlmain.cpp underwent several changes in r3999 and hunks #12 and #13 of your patch won't apply any more.

Thanks for letting me know, but that is ill tidings indeed. Just yesterday I completed alpha 5, where a bug is fixed and the algorithm is migrated to the surface device and is made compatible with all machine types, and windowed mode is supported for pixel-perfect scaling.

My changes to sdlmain.cpp include serious refactoring that breaks up several huge functions into smaller and more manageable ones and gets rid of several switch statements over the same enumerator. Furthermore, I now have an idea how to make my scalers fully orthogonal to the output device and how to arrange the output devices in sdlmain.cpp into an extensible modular structure to which new scalers, such xBRz, may easily be added.

May I coordinate my efforts with other developers? How can I contact them to discuss my changes?

Ant_222 wrote:

May I coordinate my efforts with other developers? How can I contact them to discuss my changes?

I'd suggest sending them a PM here or by contacting them over SourceForge (account is needed, though):

https://sourceforge.net/u/qbix79/profile/
https://sourceforge.net/u/harekiet/profile/
https://sourceforge.net/u/ripsaw8080/profile/

So I'll just wait with the next enhanced build until your patch works again. There's always r3998 in the meantime. 😀

Thank you, Yesterplay80. I will find the author of the change and contant him. I will post the alpha 5 anyway so as to have the latest version here for everybody's reference. I shall be grateful if you produce a build from it based on an ealier SVN revision, because I don't know how much time or work it will take me to get the patch working again, and alpha 5 has important fixes.

Qbix79 modified the sdlmain.cpp in r3999: https://sourceforge.net/p/dosbox/code-0/3999/#diff-3

But it looks like he only added and removed some spaces or line breaks where (un)necessary, so you should be able to get your patch working in a matter of minutes mirroring those few changes.

Thanks, I shall re-apply those changes manually.

Ant_222 wrote:

Thanks, I shall re-apply those changes manually.

OK, I'll wait for your update and then I'll try to merge your patch with the others again to make a new build. In the meantime I compiled r4000 with Alpha 4 of your patch, I added the few blanks that were missing manually, too.

Thank you Ant_222 and Yesterplay80!
I freaking love the DOSBox Enhanced build.

Although I don't quite understand why the holdup for implementing some basic (but essential) patches that many people use for many years now to the official SVN... 😕

James-F wrote:

Thank you Ant_222 and Yesterplay80! I freaking love the DOSBox Enhanced build.

I am right glad to know that my work is appreciated.

Although I don't quite understand why the holdup for implementing some basic (but essential) patches that many people use for many years now to the official SVN... :confused:

True, but I must improve the quality and reliability of my code. Of couse, it would have been much easier via small incremental steps in SVN. I hope the developers will allow me to do that some day... Even doing the diffs is much easier when all the files are in SVN.

Ant_222 wrote:

Even doing the diffs is much easier when all the files are in SVN.

I don't konw how exactly it works, but SVN offers the option to make your own fork of a project. Would that help you?