Codeholio did a lot of work to improve the video emulation. I tried yesterday to understand the emulation of panning for 16-bit VGA, but I think I'd need logging so I can keep track of memory and variables. 😀 It prevented me from thinking of a workaround, so I suggested removing the above commit.

Attached a patch (**) to allow MinGW32 to build the recent dosbox-x (12/29/14).

Instructions (requires MinGW32/gcc and SDL library; same as for for vanilla dosbox)
1. patch -p1 < dosbox-x-MinGW32.diff
2. ./autogen.sh
3. LDFLAGS="-static-libgcc -static-libstdc++" ./configure --enable-core-inline
4. make

** Removed fluidsynth & d3d output mode from configure script only, code for 3rd party network file patch, and a few minor changes.

truth5678 wrote:

Attached a patch (**) to allow MinGW32 to build the recent dosbox-x (12/29/14). […]
Show full quote

Attached a patch (**) to allow MinGW32 to build the recent dosbox-x (12/29/14).

Instructions (requires MinGW32/gcc and SDL library; same as for for vanilla dosbox)
1. patch -p1 < dosbox-x-MinGW32.diff
2. ./autogen.sh
3. LDFLAGS="-static-libgcc -static-libstdc++" ./configure --enable-core-inline
4. make

** Removed fluidsynth & d3d output mode from configure script only, code for 3rd party network file patch, and a few minor changes.

Why no D3D? 🙁

It's removed from configure script only as a single section of contiguous lines. The patch contains this removed section, so it is simple to add those lines back and then build. However, there are additional requirements to build with the d3d patch, and it is not required to run dosbox-x.

truth5678 wrote:

It's removed from configure script only as a single section of contiguous lines. The patch contains this removed section, so it is simple to add those lines back and then build. However, there are additional requirements to build with the d3d patch, and it is not required to run dosbox-x.

Gotcha. The D3D patch is a must if your host Operating System is Windows and you want to run a Win95/98 guest inside DOSBox-X. The OpenGL scaling just isn't up to snuff in those later graphics modes.

The opengl issue is because some code was removed from dosbox-x. In response to your issue, here are instructions to apply the opengl scaling code to dosbox-x: DOSBox-X branch.

truth5678 wrote:

The opengl issue is because some code was removed from dosbox-x. In response to your issue, here are instructions to apply the opengl scaling code to dosbox-x: DOSBox-X branch.

Oh, so the OpenGL scaling in DOSBox-X was an improvement over the vanilla DOSBox OpenGL scaling? Interesting.

I am currently working on additional patches to dosbox-x in response to your requests.

To start, here is the opengl scaling patch with notes:
"Patch is attached to reactivate opengl mode along with window and full screen scaling. Requires testing in other systems since I only tested it in a build by mingw/gcc.

The patch may contain parts which do not apply cleanly to the latest dosbox-x, so these parts would be applied manually."

I'll update this patch on request, but I'm currently working on another separate patch. I have additional patches which extend this opengl scaling patch, too. Thank you for the request, I'll continue to work on this.

Attached is an in-progress patch to update the mt32 emulation in dosbox-x to the newest 1.50 version. There is an issue where the midi music does not always start, similar to that seen in the latest Ykhwong build of dosbox.

Edit: I believe I ruled out compiler issues. I tried different settings in the configuration file, although not all of them. Perhaps the issue is related to initialization of the device in emulation? The long way to solving this problem is building an older version and then working forward in commits. 😀

truth5678 wrote:

I am currently working on additional patches to dosbox-x in response to your requests. […]
Show full quote

I am currently working on additional patches to dosbox-x in response to your requests.

To start, here is the opengl scaling patch with notes:
"Patch is attached to reactivate opengl mode along with window and full screen scaling. Requires testing in other systems since I only tested it in a build by mingw/gcc.

The patch may contain parts which do not apply cleanly to the latest dosbox-x, so these parts would be applied manually."

I'll update this patch on request, but I'm currently working on another separate patch. I have additional patches which extend this opengl scaling patch, too. Thank you for the request, I'll continue to work on this.

Thank you, sir! I think a lot of people would benefit from better OpenGL scaling when using a Win9x guest OS within DOSBox-X. Heck, the only reason I used the Direct3D scaling in ykhwong's build in certain games was because the OpenGL scaling in vanilla DOSBox doesn't properly scale some video to fullscreen in those later graphics modes; I've never been entirely clear on where the exact barrier was, but I know that with vanilla DOSBox the video clips from later DOS games would always play in the small box in the center of the screen but the Direct3D patch in ykhwong's build allowed them to properly scale.

EDIT: I was reading earlier in this thread from August when I mentioned this and leileilol comment on how vanilla DOSBox uses a special scaler for tweaked Mode X resolutions. I guess that's why those graphics modes doesn't scale the same way even when your output is set to opengl/openglnb.

Could you test the functionality of Mode X scaling in the major builds? I tested ddraw modes but less of Mode X. It may be interesting to know which games access those modes and how well they work. In Quake 2, at least the version I tested, it seemed that Mode X was a fallback if a particular ddraw mode was not available, but this is from my recollection. 😀

truth5678 wrote:

Could you test the functionality of Mode X scaling in the major builds? I tested ddraw modes but less of Mode X. It may be interesting to know which games access those modes and how well they work. In Quake 2, at least the version I tested, it seemed that Mode X was a fallback if a particular ddraw mode was not available, but this is from my recollection. 😀

Sure thing; I think I should have time this weekend.

For me, where opengl scaling doesn't work has been with "Star Trek: A Final Unity", "Zork Nemesis" and a Windows 95 guest OS.

Try applying this patch after applying scaling_gl.diff: VIDEO - OpenGL Fullscreen/Desktop Fix (SDL1).

truth5678 wrote:

Try applying this patch after applying scaling_gl.diff: VIDEO - OpenGL Fullscreen/Desktop Fix (SDL1).

Egads, I forgot about that patch you created!! It was back before I taught myself the basics of how to compile code; I'm still very much a novice in that regard but I'll give these patches a shot! Thanks, truth5678!

😀 There are a few other patches, too. I'll provide instructions to add back d3d at a later time, I was merely posting for development, not really typical use of the program; especially given that Ykhwong has a build posted. The mingw instructions may help someone test the floppy emulation, especially if they prefer the mingw environment to VS2008. It may also help identify VS2008 specific errors, as we have done previously in this thread.

truth5678 wrote:

I don't think it's complete. I did confirm this by testing, too. In fact, ykhwong's newest build has additional floppy emulation code which is not in the latest release version of dosbox-x. The additions are documented at the dosbox-x github.

Are you sure ykhwong's newest build doesn't have the latest commit of DOSBox-X? Because the changes in ykhwong's recent build state it has the latest Dec. 29, 2014 commit from github (it's commit '9e21731799a8bb59da924e7b01eccb994acf75ca').

Yes, you are correct, it does have the most recent commits. I may have confused his build with the latest dosbox-x from 12/24/14.

In addition, I ran the FDC test and it is not complete according to the test (dosbox-x). I meant to also write that you can confirm whether the FDC test passes on PCem and compare the result to that obtained from dosbox-x. Furthermore, I looked at the code and notes about the FDC emulation for verification. I did these tests from DOS, so it would not require the additional 95 emulation to work.

Codeholio also documented the parts of FDC emulation and they are in an earlier post here, including motor timings. You may follow each element of the emulation discussed there and associate it with a section of FDC code (or just from the description in the commits).

Thank you, truth5678, for confirming! I guess that the new "enable int13fakeiov86" option for the FDC's in dosbox.conf must just be a placeholder then. 😉

Codeholio did post that commit here: https://github.com/joncampbell123/dosbox-x/co … d62613e96fc62c2. It does also describe that he tested that option and that it is necessary for 95 operation. However, by running DOS FDC tests, we remove the necessity of whether that option is working or not. 😀

In Ykhwong's recent build, there is an issue where MIDI music does not start in some games.

Reproduced above issue in dosbox-x builds as far back as 1/22/14, before Ykhwong's properly working build from 1/27/14. I conclude that this is a linker issue (combined with early source code changes) which is causing the unreliable starting of midi music in some games. I can't confirm this yet, but it provides a guide so others save troubleshooting steps.