Yesterplay80 wrote:

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?

It would help with the diffs, but whereas forks tend to diverge, I still shall have a hard time maintaining a compilable patch. Thanks.

Alpha 5 uploaded. The patch has been rewritten for the surface output type, supports windowed mode and different machine types.

While implementing support for all machine types I was disappointed to find out that some them, such as vgaonly, seem to apply internal pre-scaling that prevents my patch to approximate aspect ratio effectively, e.g. vgaonly interprets a 320x200 game as a 640x400 one, depriving my algorithm of the necessary elbowroom for pixel-perfect manipulations. I consider this a flaw and think that the emulation of the video subsystem should be rewritten in such a way as to provide a point where the original raw image data is available. The patch takes it from RENDER_Reset(), where the pixel array is already modified.

I had DOSBox crash once during testing but couldn't repeat it. If the patched version should crash for you, please let me know in what circumstances it happened.

It might be just my PC, but DOSBox crashes every time when using "surfacepp", "surfacenp" or "surfacenb" as output. At first I thought it could have to do with your patch intervening with one of the others I add to my build, though it compiled without errors. But then I tried the exe you provided and the same thing happened. I tried several games, crashed every time. Could someone else please try out the newest build (s. page 1 of this thread for download)?

Btw., your MSYS installation seems to be a little outdated:

I had that same glitch as well: DOSBox SVN Builds 😀 It was fixed by updating MinGW.

Yesterplay80 wrote:

It might be just my PC, but DOSBox crashes every time when using "surfacepp", "surfacenp" or "surfacenb" as output.

Very strange, because it works here. Attached is a self-contained test sample. What happens if you unpack it into an empty directory and run test.bat?

Btw., your MSYS installation seems to be a little outdated:
[...]
I had that same glitch as well: DOSBox SVN Builds :) It was fixed by updating MinGW. But please make sure to not update mingw32-gcc to a version higher than 4.9, because everything starting with 5 seems to not compile DOSBox any more!

I thought it was typo in the source code. Well, upgrading MSYS is low priority for me as long as I can make working patches.

Ant_222 wrote:

Yesterplay80 wrote:

It might be just my PC, but DOSBox crashes every time when using "surfacepp", "surfacenp" or "surfacenb" as output.

Very strange, because it works here. Attached is a self-contained test sample. What happens if you unpack it into an empty directory and run test.bat?

That works. As long as I run the exe without actually running a game, it works. If I try to start a game with the same exe, it crashes. That happened with both alpha 5 and alpha 6 now.

UPDATE: I found the culprit! I have set "fulldouble=true" under [sdl] in all my games. If I turn that off, it works, even with my enhanced build. If I leave it on, DOSBox crashes. Is that intended behaviour or should double buffering work with pixel perfect scaling as well? It worked with alpha 4.

Yesterplay80 wrote:

I found the culprit! I have set "fulldouble=false" under [sdl] in all my games. If I turn that off, it works, even with my enhanced build. If I leave it on, DOSBox crashes. Is that intended behaviour or should double buffering work with pixel perfect scaling as well?

No, that is a bug, and I will fix it. Thanks for the testing! Edit: I have found the nest of this bug and shall squish it this evening.

Yesterplay80, see if the error persists in the alpha 7.

Ant_222 wrote:

Yesterplay80, see if the error persists in the alpha 7.

You seem to have hit the bug very, very hard, as everything seems to work now! Great job! 😁

I also uploaded a new version of my build including your alpha 7 patch.

Yesterplay80 wrote:

Ant_222 wrote:

Yesterplay80, see if the error persists in the alpha 7.

You seem to have hit the bug very, very hard, as everything seems to work now! Great job! :-D

Thank you very much.

I also uploaded a new version of my build including your alpha 7 patch.

May I ask you once again to update your build with the alpha 8 which is the same as alpha 7 in all wise save that it works some 30-40% faster in non-interpolative modes?

Done! The enhanced build now includes your alpha 8 patch!

Downloaded, thank you both!!

lightmaster wrote:

Downloaded, thank you both!!

It is great to know one's work is appreciated, but I should very much like to know which mode you are using—pixel-perfect, the lack whereof made me write patch and which I consider the one true mode for DOSBox, or nearest-neighbor or near-perfect?

Surfacenb, so nearest neighbor right?
Thanks again.

lightmaster wrote:

Surfacenb, so nearest neighbor right?

Right, does not openglnb work better for you?

Yes, does work better.

I've been looking at the patch, but I don't think it can be applied to SDL2 (eg Re: An adaptation to SDL 2.0 (Alpha-level Android build attached) )

Mainly, SDL2 would rather you deal with SDL_Texture instead of SDL_Surface. It will try to use SDL_PIXELFORMAT_ARGB8888, and SDL will pick D3D or OpenGL itself.

Kisai wrote:

I've been looking at the patch, but I don't think it can be applied to SDL2 (eg Re: An adaptation to SDL 2.0 (Alpha-level Android build attached) )

Mainly, SDL2 would rather you deal with SDL_Texture instead of SDL_Surface. It will try to use SDL_PIXELFORMAT_ARGB8888, and SDL will pick D3D or OpenGL itself.

My patch is not for SDL but for DOSBox, which currently uses SDL 1.2 for graphical output. When (or if) DOSBox switches to SDL 2.0, I shall be glad to modify my patch accordingly, although I hope that by then it will have been accepted into the official source. Edit: my scaler will work with any pixel format.

Kisai wrote:

I've been looking at the patch, but I don't think it can be applied to SDL2 (eg Re: An adaptation to SDL 2.0 (Alpha-level Android build attached) )
Mainly, SDL2 would rather you deal with SDL_Texture instead of SDL_Surface. It will try to use SDL_PIXELFORMAT_ARGB8888, and SDL will pick D3D or OpenGL itself.

I have taken a look at SDL_Texture—and yes, my patch shall work with it, e.g.:

1/* for each update rectangle: */
2SDL_LockTexture( texture, rect, &outp.pixels, &outp.pitch );
3ps_scale( scale_info, ... outp, ... ); // my routine
4SDL_UnlockTexture( texture );

Edit: if the dimenstions of the texture in fullscreen match the native resolution of the display.

I think that the patch will make new and better defaults possible for DOSBox. I propose to:

• change the default fullscreen resolution from original to desktop so that DOSBox shall work correctly with LCD monitors, which are useful only at their native resolution and which are what the majority of the audience have.
• change the default output type from surface to surfacepp so that DOSBox shall display games with minimal distortion and at a reasonable scale indifferently to the dimensions and resolution of the physical monitor.
• turn on aspect-ratio correction by default, because I see no objections to it save running the minority of games designed primarily for non-MS-DOS platforms using display dimensions other than 4/3.
• turn on fullscreen by default because it provides distraction-free and the most faithful reproduction of games.

What think you?

I think it's an interesting proposal, hope it works for steam and gog releases to capture screenshots too.