Hey, Ant_222, I just wanted to let you know that your patch doesn't apply any longer to the current revision of DOSBox (r4095), it might even breka the changes introduced with it (more than 256 colors in opengl output). I (hopefully) was able to fix it in ECE by manually implementing the changes in the diff and by removing two more instances of the check that get newly set at another point, effectively breaking the changes made before (see PP3.jpg).

Thanks a lot, Yesterplay80. Can you please clarify what you did. In the first image I see unpatched code. The current SVN version is to the left and your modification to the right? Is the same true of the second image?

The third image shows some changes to the patched code. What is on the left and what is on the right?

When I have time, I will examine those changes and will try to add them to the patch.

On the left, marked in red, is always your latest patch (adapted to ECE, so the line numbers might differ). The first two images on the right show, marked in green, the changes that were required to make it applicable (again, with ECE) again, the third image shows the changes I made to re-enable the support for more than 256 colors in OpenGL output, which the latest revision added.

I think your changes are correct and should not break anything. Please test, however, the attached modification. I cannot currently upload it to the title post because of a problem with this forum.

Sorry, wrong attachment. The correct one is here.

Thanks, I will try the patch with the next DOSBox revision!

To whomever it may concern: the diff between r4094 and r4095 has this change:

1--- src/gui/sdlmain.cpp	(revision 4094)
2+++ src/gui/sdlmain.cpp	(revision 4095)
3@@ -414,6 +414,8 @@
4 		goto check_gotbpp;
5 #endif
6 	case SCREEN_OVERLAY:
7+		//We only accept 32bit output from the scalers here
8+		//Can't handle true color inputs
9 		if (flags & GFX_RGBONLY || !(flags&GFX_CAN_32)) goto check_surface;
10 		flags|=GFX_SCALING;
11 		flags&=~(GFX_CAN_8|GFX_CAN_15|GFX_CAN_16);

That is, in spite of the comment, the test of was not made more rigorous.

The complete change is less rigorous (for opengl output), not overlay:
https://bazaar.launchpad.net/~i30817/dosbox/t … k/revision/3998

I don't know if Ant_222 is active here any more, however: The latest revision r4132 breaks his patch, but that's easily fixed. Et voilà!

Yesterplay80 wrote:

I don't know if Ant_222 is active here any more, however: The latest revision r4132 breaks his patch, but that's easily fixed. Et voilà!

pp15b.diff

Thanks for the notification, Yesterplay80. I am going on vacation tomorrow, but I will try to fix it upon return.

Edit: What is the easiest way to update a patch according to incompatible changes in the source? My procedure is tedious: check which places are broken, take the last successfully patched version, and manually implement in it the changes from the SVN.

Ne need to try, the diff I posted already is the fixed version. Have fun in your vacations!

Thank you kindly. I have added your patch to the title post as pixel-perfect-alpha14-4132.patch.zip .

Btw, latest daily build of ScummVM now has this 😎

I thought they had added it way before I had made my patch... Do they approximate the aspect ratio using the 5x6 method, i.e. by scaling 320x200 into 1600x1200? If so, I am very glad for them and wish that one happy day my patch or its equivalent is included into official DOSBox.

Ant_222 wrote:

I thought they had added it way before I had made my patch... Do they approximate the aspect ratio using the 5x6 method, i.e. by scaling 320x200 into 1600x1200? If so, I am very glad for them and wish that one happy day my patch or its equivalent is included into official DOSBox.

I frequently updating scummvm with daily builds, but noticed pixel perfect scaling only week or so ago. But who knows, maybe i was unobservant and miss it.

You are correct. The previous version of pixel-perfect scaling was in a separate branch.

Hello Ant_222,

nice patch I like it.

But the patch file has many unneeded stuff.
- added tailing spaces and tabs
- changed spaces to tabs and vice versa
- added or removed spaces in line
- out commented (test-)code added

That makes your patch harder to read as necessary and merging in the future maybe complicater as needed.
As attachment a cleaned file, cross diffed with your file and compiled errorless. Feel free to use it, credits not needed.

Many thanks for tidying up my mess, vogam. May I ask of you another service—to post a diff of between the source patched with my original and with your fixed patched. I will review the changes and, if all is OK, upload your fix on the title patch of the thread.

FYI: Commit r4144 once again breaks your patch, Ant_222, because of two added lines. I'll look into it later for ECE.

Yesterplay80 wrote:

FYI: Commit r4144 once again breaks your patch, Ant_222, because of two added lines. I'll look into it later for ECE.

. Begin busy on other projects now, may I ask you to test the vogam's fixed version? He said he had fixed inconsistent whitespace (space and tabs). If not, I will do it as soon as I can.