The Direct3D option? What's wrong with it? That's what I always use.

And disable the menu item (core =) Dynamic where paging is enabled. Also, the user should receive a warning message if pressing the keys to switch to the dynamic core while paging is enabled.

The Alpha Centauri demo with sound on results in a page fault in Windows 95. This occurs in other versions and is also independent of the dosbox-x settings. If its sound routines are not sensitive to cpu cycles, then it may be related to the dosbox-x page fault handling system.

The above issue has infrequently occurred in real hardware, but early versions of PCem do not have the issue.

The workaround is to disable audio by renaming sound.dll in the game directory.

Did the COMMDLG.DLL debug log to screen occur in both W31 enhanced and standard mode? Also, while booting a W31 image or from a local directory?

Apparently it happens in both 286 standard and 386 enhanced modes. This is running Windows 3.1 from a local directory, under the DOSBox-X DOS kernel.

I haven't yet been able to reproduce the issue in the latest win32 dosbox-x. Using xms=ems=umb=true and sb2 sound.

COMMDLG.DLL is 89248 bytes and last modified on 3/10/92.

It only seems to happen with that specific version of Windows 3.1. Windows 3.0 and Windows 3.11 don't display the message. I'll finish up the changes from Windows and then boot back into Linux to check the COMMDLG.DLL version on my end.

COMMDLG.DLL in my Windows 3.1 setup is also 89248 bytes. I don't have the last modified date on my system.

Hi TheGreatCodeholio and thank you for your efforts on d-x.
Have a small q: why do you have to disable fullscreen (or any scaling at all?) with OGL Voodoo emulation?

The OGL voodoo emulation is very delicate from it's design. It seems to take the OpenGL context DOSBox-X would normally use itself and set it up to become the state the DOS game uses through the hardware, including video resolution.

The problem is that any change of window size or any resize event destroys this delicate setup and messes up the graphics.

The proper fix for the issue would be two major changes.

One, the OGL voodoo emulation needs to allocate it's own OpenGL context and leave DOSBox-X's GFX context alone. Then they won't conflict and a lot of the delicate balancing act could be eliminated in sdlmain.cpp.

Two, resizing of the window could be re-enabled if the 3Dfx OGL code rendered to a texture instead (if the client area of the window did not match the resolution), and the GFX code then drew the texture to the window. You could then resize the window as you see fit while the DOS game within continued to see the 640x480 or whatever video framebuffer it expects to draw to.

Thanks.
Also there's the issue of corruption/flickering of static elements (like hud/cockpit) I see in both Archimedean Dynasty and Carma... Actually for me Carma won't render any menus at all (have to push enter blindly), and in AD the screen with the mission briefing is likewise totally black. Could be related to (1) tho?
Anyway, still hoping to play AD w/glide one day on Linux... The reason I became interested in this Voodoo on Dosbox stuff in the first place)) Seems that it's possible with nGlide on windowz...

This project really regained new life recently and I really appreciate the fact beta version binary builds are easy to find now (Did I say emucr?)

However I see some weird bugs with opengl output rendering (the standard one, not opengl voodoo) still here (you can see stills of old screens when changing graphic mode or when the whole screen image changes). I know it's hard to understand from my words what the bug is about, I'll try to document the thing with some video captures.

For the memory-backed disk image code, it may be worthwhile to bypass the capability to produce DOS 1.X floppy images (fatDrive::fatDriveInit in drive_fat.cpp):

1+	if ((bootbuffer.mediadescriptor & 0xf0) != 0xf0 && filesize <= 360) {
2+		LOG_MSG("DOS 1.x format floppy not supported in this code path for memory-based disk images");
3+		created_successfully = false;
4+	       	return;
5+	}

If this is considered, then the above also requires an additional condition on whether the image is memory-based or not, so that non-memory-based images can create that kind of floppy.

Thanks for the suggestion, that would be Shane32's work: https://github.com/joncampbell123/dosbox-x/pull/565

As it is now, the memory-backed disk code simply emulates a hard drive attached to the emulator, regardless of the type of formatting it has - just the same as mounting a vhd file would. It is automatically formatted so it is immediately available for use by the system. I'm not sure I understand what benefit it would have to place additional limitations on memory-backed disks, assuming the file structure was supported by the rest of DosBox. Am I missing something?

That's fine.

The MS-DOS 6.22 Supplemental package (SUP622.EXE) has Accessibility programs. However, FAKEMOUS doesn't detect the PS/2 port even though it is active in DOSBox-X, and the ADOS.COM menu item "mousekeys" is not available. This is a function where the mouse motion and buttons are controlled from the keyboard number pad.

However, the Windows 3.1 Accessibility Pack (ACCP.EXE) for 16-bit and its mousekeys function do work in DOSBox-X: http://www.mdgx.com/w31toy.htm.

With latest DOSBox-X, Alpha Centauri with sound exits with an error type 13 in cpu.cpp:
E_Exit("CALL:Descriptor type %x unsupported",(int)call.Type())

Cpu.h shows the definitions of these (descriptor) types, for example:
#define DESC_386_CALL_GATE 0x0c
#define DESC_386_INT_GATE 0x0e
#define DESC_386_TRAP_GATE 0x0f

Noted that the code comments about "this code isn't very easy to make interruptible".

I think PCem has similar code in loadcscall(), and it is appears interruptible. The alternative is that the above error is an after effect of the true issue.

I found a Windows version of Alpha Centauri (a demo).

Seems to be working fine so far.

Are you using dynamic core?