James-F wrote:

The compiler shows error in render.cpp.

That sdlmain.cpp is not patched at all. For example, the patch has:

1diff -upr /home/Ant/dosbox-code-3989/src/gui/sdlmain.cpp ./src/gui/sdlmain.cpp
2--- /home/Ant/dosbox-code-3989/src/gui/sdlmain.cpp	2016-09-06 22:15:47 +0300
3+++ ./src/gui/sdlmain.cpp	2016-09-06 22:26:53 +0300
4@@ -49,6 +49,7 @@
5 #include "cpu.h"
6 #include "cross.h"
7 #include "control.h"
8+#include "math.h"

whereas the version you uploaded has no math.h mentioned. The other two files are patched. patch must have reported some errors about sdlmain.cpp.

Phew! I have fixed it for good now.

It didn't work.
Same problem in the same place.

* Each time I completely delete the dosbox directory to start fresh, and follow the guide no more no less.

1TESTER@Desky-i7 ~
2$ cd dosbox
3
4TESTER@Desky-i7 ~/dosbox
5$ patch -p0 < pixelperfect.patch
6(Stripping trailing CRs from patch.)
7patching file ./include/video.h
8(Stripping trailing CRs from patch.)
9patching file ./src/gui/render.cpp
10(Stripping trailing CRs from patch.)
11patching file ./src/gui/sdlmain.cpp
12
13TESTER@Desky-i7 ~/dosbox
14$

1make[3]: Entering directory `/home/TESTER/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:1030:2: error: expected initializer before 'if'
6  if (SDL_LockSurface(sdl.blit.surface)) {
7  ^
8sdlmain.cpp:1034:9: error: expected constructor, destructor, or type conversion
9before '=' token
10  *pixels=(Bit8u *)sdl.blit.surface->pixels;
11         ^
12sdlmain.cpp:1035:8: error: expected constructor, destructor, or type conversion
13before '=' token
14  *pitch=sdl.blit.surface->pitch;
15        ^
16sdlmain.cpp:1036:2: error: expected unqualified-id before 'return'
17  return 1;
18  ^
19sdlmain.cpp:1037:1: error: expected declaration before '}' token
20 }
21 ^
22make[3]: *** [sdlmain.o] Error 1
23make[3]: Leaving directory `/home/TESTER/dosbox/src/gui'
24make[2]: *** [all-recursive] Error 1
25make[2]: Leaving directory `/home/TESTER/dosbox/src'
26make[1]: *** [all-recursive] Error 1
27make[1]: Leaving directory `/home/TESTER/dosbox'
28make: *** [all] Error 2
29
30TESTER@Desky-i7 ~/dosbox
31$

James-F wrote:

It didn't work.
Same problem in the same place.

A missing curly bracket. Fixed. But I really must go home and check it all without hurry. I will tell you when I have done it.

Take your time, don't do it at work. 🤣

Ant_222 wrote:

A missing curly bracket. Fixed. But I really must go home and check it all without hurry. I will tell you when I have done it.

It works for me now.

DDRAW this time.
I am compiling dosbox with EVERYTHING because different users might want them, so take this into account.

Don't forget your other patch, I am more interested in your super-scaler patch.

Making all in gui make[3]: Entering directory `/home/TESTER/dosbox/src/gui' g++ -DHAVE_CONFIG_H -I. -I../.. -I../../include -I/ […]
Show full quote

Making all in gui
make[3]: Entering directory `/home/TESTER/dosbox/src/gui'
g++ -DHAVE_CONFIG_H -I. -I../.. -I../../include -I/mingw/include/SDL -D_GNU_SOU
RCE=1 -Dmain=SDL_main -g -O2 -mno-ms-bitfields -MT sdlmain.o -MD -MP -MF .deps
/sdlmain.Tpo -c -o sdlmain.o sdlmain.cpp
sdlmain.cpp: In function 'void InitScreenTypes()':
sdlmain.cpp:1078:68: error: 'ssdStartUpate' was not declared in this scope
AddScreenType( SCREEN_SURFACE_DDRAW, &ssdBestMode, &ssdSetSize, &ssdStartUpat
e, &ssdEndUpdate,&ssdGetRgb );
^
make[3]: *** [sdlmain.o] Error 1
make[3]: Leaving directory `/home/TESTER/dosbox/src/gui'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/TESTER/dosbox/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/TESTER/dosbox'
make: *** [all] Error 2

TESTER@Desky-i7 ~/dosbox
$

James-F wrote:

DDRAW this time.

Fixed. My haste and inattention.

I am compiling dosbox with EVERYTHING because different users might want them, so take this into account.

I will test the following patches with as full a configuration as I can.

Don't forget your other patch, I am more interested in your super-scaler patch.

Of course not—Only yestereve in the bath I desinged a reasonably fast algorithm for interpolative downscaling, but I shall not have time to implemenent until either this or the next weekend.

Finally, well done!
Now you deserve a good rest. 😀

Included patches: Nuked-OPL, normal4x-5x-6x, and PixelPerfect (Alpha2).
Compiled with: Compressed CD Audio functionality, DDRAW, SDL-Network, PNG screenshots.

James-F wrote:

Finally, well done! Now you deserve a good rest. :happy:

Thank you kindly for your patience with me, who works in snatches of spare time.

Ant_222 wrote:

Then it should be corrected: […]
Show full quote

VileRancour wrote:

Ant_222 wrote:

What were the resolutions of the game and of your desktop? It is simply impossible to have pixel-perfect aspect correction if the native desktop resolution is not high enough. For example—the standard 640x400 textmode on a 1680x1050 monitor can only be upscaled by a factor of two without aspect correction.

320x200 and 1280x1024 respectively. I'm well aware that I'd need 1600x1200 for pixel-perfect scaling with aspect correction, just wanted to make sure that I'm seeing a deliberate fallback (i.e. that it wasn't just ignoring aspect= altogether, or anything like that).

Then it should be corrected:

Copy code to clipboard

1320x200 * 4x5 = 1280x1000

If it is not the case for you I have a bug.

May I ask you to post a screenshot demonstrating the problem?

James-F wrote:

Finally, well done! Now you deserve a good rest. :happy: […]
Show full quote

Finally, well done!
Now you deserve a good rest. 😀

Included patches: Nuked-OPL, normal4x-5x-6x, and PixelPerfect (Alpha2).
Compiled with: Compressed CD Audio functionality, DDRAW, SDL-Network.

Now's you time to stay awake, James-F! 😉 Your DOSBox.exe is looking for a missing libogg-0.dll here. Maybe you forgot to set "--disable-shared" when configuring the installation?

Actually I had this problem before setting the PATH environmental variable in windows as following:

1C:\MinGW\bin;C:\MinGW\MSYS\1.0\bin;C:\MinGW\MSYS\1.0\local\bin;

libogg-0.dll is in my C:\MinGW\bin; directory.

I don't think I forgot "--disable-shared" because I just copy and paste straight from the website instructions.
I'll try to recompile.

EDIT:
I think when compiling with MinGW and MSYS in windows I have to include libogg-0.dll manually in the folder.
Also searching vogons for "libogg-0.dll" tells me the same.
* Download updated.

EDIT2:
I completely removed MinGW and compiled everything again.
This time all is included without extra dlls.
* Download updated again.

Apparently MinGW and MSYS are extremely finicky about ./configuring and make installing thing the SECOND time.
It has to be right the first time or no success. 😒

I never had to copy any file manually, however it works now! 😁

Progress report: I have mostly implemented interpolative scaling, and it works, but one major optimization and a code clean-up still need be made. My patch now adds the following output types: overlaynb (nearest neighbor), overlaypp (pixel-perfect), and overlaynp (near-perfect, i.e. interpolative downscaling with a minimum of artefacts) in addition to the standard overlay.

Greetings and thank you for the wonderful new view mode! And thank you as well to James-F for compiling a dosbox version with all the patches that is usable by clueless people like me. Now if a new version of D-fend existed for this, it would be awesome, we'd have like a pseudo-update of DOSBox hehe. I myself simply tried to connect this build to D-Fend since I enjoy actually using a GUI, but I was wondering if what James-F said in the release post about this DOSBox was accurate for my case, since I prefer all programs use their install folder for saving settings and stuff, and what I did was I just copied the 4 files over into the DOSBox 0.74 folder that D-Fend Reloaded installs, and only ran DOSBox through the frontend.

I have to say it is nice to play a DOS game with more of my 1920x1080 screen and have it look nice. I realize I need to at least get a 1920x1200 screen to get maximum benefit, but it's still a great improvement now. I absolutely hate black bars of any kind, even as I now understand some games had a black area they made use of, but I was wondering if there would possibly be a way to get games to use even more of my screen while still being pixel perfect. Also, and more importantly for me, would it be possible to connect overlaypp to an image enhancement filter like xbrz or hq#x? I much prefer playing old DOS games this way. Here's hoping your work will be in the main DOSBox release soonTM.

Taiyoumaru wrote:

I absolutely hate black bars of any kind, even as I now understand some games had a black area they made use of, but I was wondering if there would possibly be a way to get games to use even more of my screen while still being pixel perfect.

Probably not, unless you get a dedicated 4/3 monitor. You have to choose between pixel-perfectness in its strict sense and the absense of a black area around the image. You can get away with either only vertical or only horizontal black bars if you use the openglnb output or my upcoming overlaynp.

with the aspect-ratio correction on. Also, and more importantly for me, would it be possible to connect overlaypp to an image enhancement filter like xbrz or hq#x? I much prefer playing old DOS games this way. Here's hoping your work will be in the main DOSBox release soonTM.

I don't know—I haven't even thought about it. My immediate task is to finish "near-perfect" interpolative upscaling (which you might enjoy). I dislike all sorts of filters and enchancers when applied to low-resolution non-photorealistic images with pixel art.

I don't know—I haven't even thought about it. My immediate task is to finish "near-perfect" interpolative upscaling (which you might enjoy). I dislike all sorts of filters and enchancers when applied to low-resolution non-photorealistic images with pixel art.

If by interpolation you are referring to horizontal semi-transparent bars on my screen that emulate the CRT monitor, then no, I would probably dislike that even more. To me the image would look discontinuous and break immersion and I'd much rather just play with no scaler in that case. I realize I'm in the minority here among many DOS purists, but most of my childhood never had the benefit of DOS gaming since by the time I could use a PC windows 95 was ubiquitous and 98 came very soon so I was unfortunately left out of DOS gaming with only faint memories of few games to guide me back in my adult life. But by then I had already been spoiled by emulators of various consoles that offered image enhancers like supereagle etc., so going back to these old games has been a mild strain on my eyes. My biggest wish is for xBRz support to be implemented in the main dosbox branch. I believe it is the only scaler worth mentioning as it makes everything look absolutely stuning to me while maintaining a lot of the painstaking detail that goes into pixel art, as can be evidenced here https://sourceforge.net/projects/xbrz/

Perhaps something for the future, one can only hope 😁

Finally as a question for future monitor buying, am I correct in assuming that overlaypp will also use the most possible screen it can on a 30inch 2560x1600 monitor as well since both 1920x1200 and 2560x1600 are 16:10?

Taiyoumaru wrote:

My biggest wish is for xBRz support to be implemented in the main dosbox branch. I believe it is the only scaler worth mentioning as it makes everything look absolutely stuning to me while maintaining a lot of the painstaking detail that goes into pixel art, as can be evidenced here https://sourceforge.net/projects/xbrz/ I realize

Thanks. Their code may help me optimise mine at least.

Finally as a question for future monitor buying, am I correct in assuming that overlaypp will also use the most possible screen it can on a 30inch 2560x1600 monitor as well since both 1920x1200 and 2560x1600 are 16:10?

Generally, no. With overlaypp the horizontal and vertical scaling factors are always integral, which means that instead of zooming by a factor of, say, 2.13 it will use 2.00 to keep the pixels perfect. Here's how a 640x480 image will be upscaled:

11920x1200: 640x480->2x2->1280x960
22560x1600: 640x480->3x3->1920x1440

Generally, no. With overlaypp the horizontal and vertical scaling factors are always integral, which means that instead of zooming by a factor of, say, 2.13 it will use 2.00 to keep the pixels perfect.

So in essence how much screen a game can take also depends on its original maximum resolution, which means games with different resolutions would occupy varying amounts of space on the screen. By that code it also looks like game would never occupy the great majority of my screen (I was hoping for something 90%+), so I guess I'll have to settle for the few artifacts with a stretched resolution using the upcoming options. Thanks for the patience with my silly questions.