DosFreak wrote:

Best not to comment if you don't have any idea of what you're talking about. Most of those features aren't needed by games or don't work across multiple operating systems or are only needed by a few games and the patch is hacky but because one or two games need it people bitch. If you have a patch for DOSBox that is for gaming then upchannel it to the devs. If it's a fix for compatibility and it doesn't break anything then you'll see it in SVN.

I already guessed my comment would upset the DosBox fanboys 😀

Apparently you are new to (DosBox) development, because what you describe (and what works in most other open source projects) just doesn't work in DosBox. They won't accept bug fixes, as long as these bug fixes can potentially be used to do more than just play games with DosBox. A lot of VGA, EGA and/or CGA related fixes were rejected in the past because "no (known) game uses these features". Which might be true, or it might not be (who can claim to know every game out there that exists?). The fact that they oppose anything that doesn't fit their vision for gaming under the weak excuse of not wanting to be held liable for someone using non-gaming programs in DosBox is the reason development is stalled, but it is also what creates a fertile soil for forks like DosBox-X, which is eventually a good thing.

DosFreak wrote:

If it's a new feature and it's for gaming purposes then you'll eventually see it in a new ver.

Well, the last "new ver." we got from DosBox was v0.74 which was released 7 years ago. 7 years without a release spells pretty much "dead" to me. And if you look at the commits you will see that 90% of them are compile fixes, cleanups, etc. which are mostly one-liners. The last non-trivial commit was in mid January, and the last "feature commit" was so far back that I couldn't even find it within reasonable time.

And again, this is nothing bad, people move on to other projects, develop different interests, etc. so it's a common thing in open source projects. And most of the time, there are other people who continue the development in their own fork. This is how open source works. I would love to see a flurry of new activity in DosBox SVN, but I understand that with their current focus on DOS gaming only, there just isn't much that can be added anymore. DosBox needs new developers with a new focus and a vision that goes beyond DOS gaming, and these developers will continue innovating with new features. I, for one, am really looking forward to this development..

🤣 no.

Agree to disagree.

Please post your delusions in a new thread so they can be shot down piece by piece.

Darkstar wrote:

Apparently you are new to (DosBox) development

Best to not come into a community you know nothing about and talk down to people without knowing who they are.

It's now possible to compile SDL v12 for Windows without the dx5 object files; one way is to remove them from the Makefile: ./src/audio/windx5/*.c.
And this change:

1diff -rupN SDL-1.2-Orig//src/video/SDL_video.c SDL-1.2//src/video/SDL_video.c
2--- SDL-1.2-Orig//src/video/SDL_video.c
3+++ SDL-1.2//src/video/SDL_video.c
4@@ -78,9 +78,9 @@ static VideoBootStrap *bootstrap[] = {
5 #if SDL_VIDEO_DRIVER_GAPI
6 	&GAPI_bootstrap,
7 #endif
8-#if SDL_VIDEO_DRIVER_DDRAW
9+/* #if SDL_VIDEO_DRIVER_DDRAW
10 	&DIRECTX_bootstrap,
11-#endif
12+#endif */
13 #if SDL_VIDEO_DRIVER_WINDIB
14 	&WINDIB_bootstrap,
15 #endif

Also, 3dfx/gl games run better under high CPU load (win32) with this change from the direct3d patch:

1diff -rupN SDL-1.2-Orig//src/thread/win32/SDL_sysmutex.c SDL-1.2/src/thread/win32/SDL_sysmutex.c
2--- SDL-1.2-Orig//src/thread/win32/SDL_sysmutex.c
3+++ SDL-1.2/src/thread/win32/SDL_sysmutex.c
4@@ -30,7 +30,7 @@
5 
6 
7 struct SDL_mutex {
8-	HANDLE id;
9+	CRITICAL_SECTION cs;
10 };
11 
12 /* Create a mutex */
13@@ -42,12 +42,7 @@ SDL_mutex *SDL_CreateMutex(void)
14 	mutex = (SDL_mutex *)SDL_malloc(sizeof(*mutex));
15 	if ( mutex ) {
16 		/* Create the mutex, with initial value signaled */
17-		mutex->id = CreateMutex(NULL, FALSE, NULL);
18-		if ( ! mutex->id ) {
19-			SDL_SetError("Couldn't create mutex");
20-			SDL_free(mutex);
21-			mutex = NULL;
22-		}
23+		InitializeCriticalSection(&mutex->cs);
24 	} else {
25 		SDL_OutOfMemory();
26 	}
27@@ -58,10 +53,7 @@ SDL_mutex *SDL_CreateMutex(void)
28 void SDL_DestroyMutex(SDL_mutex *mutex)
29 {
30 	if ( mutex ) {
31-		if ( mutex->id ) {
32-			CloseHandle(mutex->id);
33-			mutex->id = 0;
34-		}
35+		DeleteCriticalSection(&mutex->cs);
36 		SDL_free(mutex);
37 	}
38 }
39@@ -73,10 +65,7 @@ int SDL_mutexP(SDL_mutex *mutex)
40 		SDL_SetError("Passed a NULL mutex");
41 		return -1;
42 	}
43-	if ( WaitForSingleObject(mutex->id, INFINITE) == WAIT_FAILED ) {
44-		SDL_SetError("Couldn't wait on mutex");
45-		return -1;
46-	}
47+	EnterCriticalSection(&mutex->cs);
48 	return(0);
49 }
50 
51@@ -87,9 +76,6 @@ int SDL_mutexV(SDL_mutex *mutex)
52 		SDL_SetError("Passed a NULL mutex");
53 		return -1;
54 	}
55-	if ( ReleaseMutex(mutex->id) == FALSE ) {
56-		SDL_SetError("Couldn't release mutex");
57-		return -1;
58-	}
59+	LeaveCriticalSection(&mutex->cs);
60 	return(0);

61 }

This Windows specific API is tailored for use within a single process while they suggest the above original way where communicating between processes.

I don't know whether this Windows patch was already added:

1diff -rupN SDL-1.2-ORIG//src/video/windib/SDL_dibvideo.c SDL-1.2//src/video/windib/SDL_dibvideo.c
2--- SDL-1.2-ORIG//src/video/windib/SDL_dibvideo.c
3+++ SDL-1.2//src/video/windib/SDL_dibvideo.c
4@@ -821,7 +821,7 @@ SDL_Surface *DIB_SetVideoMode(_THIS, SDL
5 	} else {
6 #ifndef NO_CHANGEDISPLAYSETTINGS
7 		if ( (prev_flags & SDL_FULLSCREEN) == SDL_FULLSCREEN ) {
8-			ChangeDisplaySettings(NULL, 0);
9+			ChangeDisplaySettings(NULL, CDS_FULLSCREEN);
10 		}
11 #endif
12 		if ( flags & SDL_NOFRAME ) {
13@@ -1215,7 +1215,7 @@ void DIB_VideoQuit(_THIS)
14 			}
15 #ifndef NO_CHANGEDISPLAYSETTINGS
16 			if ( this->screen->flags & SDL_FULLSCREEN ) {
17-				ChangeDisplaySettings(NULL, 0);
18+				ChangeDisplaySettings(NULL, CDS_FULLSCREEN);
19 				ShowWindow(SDL_Window, SW_HIDE);
20 			}
21 #endif

It supposedly is a fix for other window positions/sizes when exiting fullscreen. I haven't observed an effect yet, however.

Verified that a custom build shows the timer and logo of the Nature95 demo in 3dfx/gl mode (sound off). Also, confirmed that this is an issue in latest dosbox-x. I think this is related to the cpu emulation since it occurs with core=normal, but not with core=dynamic.

Dynamic core has the same above issue as the normal core where emptying these functions that are used in the 3dfx/gl code:

1void CPU_Core_Dyn_X86_SaveDHFPUState(void) {
2}
3
4void CPU_Core_Dyn_X86_RestoreDHFPUState(void) {
5}

I just restored dynamic core in the master branch. Same issue?

The restored dynamic core doesn't show the 3dfx/gl issue. Could you disable that video mode where core=normal and use the 3dfx software rasterizer instead?

Noted: https://github.com/joncampbell123/dosbox-x/issues/516

I will be merging the Windows async SDL code into develop and then master on March 1st, unless any other major issues come up.

https://github.com/joncampbell123/dosbox-x/issues/472

I'm using aspect=true and noticed that when emulating DOS on a 1280x1024 monitor (5:4 aspect), the picture is stretched slightly off the edge of the screen. I suggest that when aspect=true, the logic anticipate both the width and height of the screen when sizing the picture, and shrink vertically when necessary. I can supply some logic, if you like, although it would be C# and I'm not sure if it would help.

I'm using these parameters in the conf file (all my DOS games and apps plus Windows 3.1 are loaded in a single emulation):

1[sdl]
2output=direct3d
3fullscreen=true
4[dosbox]
5a20=mask
6[render]
7aspect=true
8scaler=normal3x
9[vsync]
10# vsyncmode=host
11[cpu]
12fpu=false
13cycles=25000
14[midi]
15mpu401=uart

I could set aspect=false, of course, but my dosbox-x is shared in OneDrive, which I use on both 16:9 screens on one pc and 5:4 on another.

As an additional enhancement, the code could anticipate if the ratio was "close" (e.g. between 5:4 and 4:3), and if so, stretch to fit the screen rather than mantain the correct aspect. Perhaps when setting aspect=auto or something.

Another additional enhancement would be to change the background color past the edge of the virtualized screen, for instance to grey. This is useful when playing games like Paratroopers that have a black background, where it is helpful to be able to see the edge of the monitor.

I know that output=direct3d has issues when the 4:3 aspect ratio it comes up with is wider than the window, where it will cut off the edges instead of size down like it's supposed to.

Could you test dosbox-x with the change below to voodoo_opengl.cpp and where core=normal and 3dfx/gl mode is active. Testing with Nature95 demo with sound off and verifying whether the introduction sequence is shown.

1 	Uint32 sdl_flags = SDL_OPENGL;
2 
3-    	ogl_surface = SDL_SetVideoMode(v->fbi.width, v->fbi.height, 32, sdl_flags);
4+	ogl_surface = SDL_SetVideoMode(v->fbi.width, v->fbi.height, 16, sdl_flags);
5+	ogl_surface = NULL;
6+	ogl_surface = SDL_SetVideoMode(v->fbi.width, v->fbi.height, 32, sdl_flags);	
7 
8 	if (ogl_surface == NULL) {
9 		if (full_sdl_restart) {

No change, either core=normal or core=dynamic. Nature still shows a blank screen until it starts animating.

Please try this instead:

1diff -rupN dosbox-x-Orig/src/hardware/voodoo_opengl.cpp dosbox-x//src/hardware/voodoo_opengl.cpp
2--- dosbox-x-Orig/src/hardware/voodoo_opengl.cpp
3+++ dosbox-x//src/hardware/voodoo_opengl.cpp
4@@ -1609,12 +1609,6 @@ void voodoo_ogl_set_window(voodoo_state
5 }
6 
7 void voodoo_ogl_reset_videomode(void) {
8-#if defined(WIN32) && !defined(C_SDL2)
9-    /* always show the menu */
10-    void DOSBox_SetMenu(void);
11-    DOSBox_SetMenu();
12-#endif
13-
14     GFX_PreventFullscreen(true);
15 
16 	last_clear_color=0;
17@@ -1669,7 +1663,10 @@ void voodoo_ogl_reset_videomode(void) {
18 
19 	Uint32 sdl_flags = SDL_OPENGL;
20 
21-    ogl_surface = SDL_SetVideoMode(v->fbi.width, v->fbi.height, 32, sdl_flags);
22+		ogl_surface = SDL_SetVideoMode(v->fbi.width, v->fbi.height, 16, sdl_flags);
23+		ogl_surface = NULL;
24+	
25+		ogl_surface = SDL_SetVideoMode(v->fbi.width, v->fbi.height, 32, sdl_flags);	
26 
27 	if (ogl_surface == NULL) {
28 		if (full_sdl_restart) {
29@@ -1750,13 +1747,6 @@ void voodoo_ogl_reset_videomode(void) {
30 		LOG_MSG("VOODOO: OpenGL: invalid depth size %d",depth_csize);
31 	}
32 
33-#if defined(WIN32) && !defined(C_SDL2)
34-	// Windows SDL 1.x builds may destroy and re-create the window, and lose our menu bar.
35-	// make sure to put it back.
36-	void DOSBox_SetMenu(void);
37-	DOSBox_SetMenu();
38-#endif
39-
40 	/* Something in Windows keeps changing the shade model on us from the last glShadeModel() call. Change it back. */
41 	glShadeModel(GL_SMOOTH);
42 

Setting autofit=false fixes the aspect ratio issue with direct3d. The relevant code in direct3d.cpp (the SetupSceneScaled function) is totally nonsensical; about 1/2 the code is never used, and the code for autofit makes no sense either. Autofit doesn't seem to be used by any of the other video outputs, either. I'll write a replacement function and post it when I'm done.

Here's the updated code (direct3d.cpp, starting with line 1279):

1void CDirect3D::SetupSceneScaled(void)
2{
3    double sizex,sizey,ratio;
4
5	// TODO: It would probably be nicer to offer an option here whether the user wants
6	//		 point sampling (D3DTEXF_POINT) or linear interpolation (D3DTEXF_LINEAR) when scaling up/down.
7    pD3DDevice9->SetTextureStageState(0, D3DTSS_COLOROP,   D3DTOP_MODULATE);
8    pD3DDevice9->SetTextureStageState(0, D3DTSS_COLORARG1, D3DTA_TEXTURE);
9    pD3DDevice9->SetTextureStageState(0, D3DTSS_COLORARG2, D3DTA_DIFFUSE);
10    pD3DDevice9->SetTextureStageState(0, D3DTSS_ALPHAOP,   D3DTOP_MODULATE);
11    pD3DDevice9->SetTextureStageState(0, D3DTSS_ALPHAARG1, D3DTA_TEXTURE);
12    pD3DDevice9->SetTextureStageState(0, D3DTSS_ALPHAARG2, D3DTA_DIFFUSE);
13    pD3DDevice9->SetSamplerState(0, D3DSAMP_MINFILTER, D3DTEXF_LINEAR);
14    pD3DDevice9->SetSamplerState(0, D3DSAMP_MAGFILTER, D3DTEXF_LINEAR);
15    pD3DDevice9->SetSamplerState(0, D3DSAMP_MIPFILTER, D3DTEXF_NONE);
16
17    D3DVIEWPORT9 Viewport;
18    pD3DDevice9->GetViewport(&Viewport);
19
20    // Projection is screenspace coords
21    D3DXMatrixOrthoOffCenterLH(&m_matProj, 0.0f, (float)Viewport.Width, 0.0f, (float)Viewport.Height, 0.0f, 1.0f);
22
23    // View matrix does offset
24    // A -0.5f modifier is applied to vertex coordinates to match texture
25    // and screen coords. Some drivers may compensate for this
26    // automatically, but on others texture alignment errors are introduced
27    // More information on this can be found in the Direct3D 9 documentation
28    D3DXMatrixTranslation(&m_matView, (float)Viewport.Width/2-0.5f, (float)Viewport.Height/2+0.5f, 0.0f);
29
30    // World View does scaling
31    sizex = dwScaledWidth;
32    sizey = dwScaledHeight;
33
34    // aspect = 2 in certain conditions to disable aspect code, but typically aspect = render.aspect
35    if((aspect == 1) && (dwWidth > 0) && (dwHeight > 0)) {
36		// render.aspect IMPLEMENTED
37
38		// We'll try to make the image as close as possible to 4:3
39		// (square pixels assumed (as in lcd not crt))
40
41		//when autofit=true, scale instead to 5:4 if the monitor is a 5:4 monitor (1280x1024)
42		if (autofit && ((sizex / sizey) == (5.0 / 4.0))) {
43			ratio = 5.0 / 4.0;
44#if LOG_D3D
45			LOG_MSG("D3D:Scaling image to 5:4");
46#endif
47		}
48		else
49		{
50			ratio = 4.0 / 3.0;
51#if LOG_D3D
52			LOG_MSG("D3D:Scaling image to 4:3");
53#endif
54		}
55
56		if (sizex > sizey * ratio)
57			sizex = sizey * ratio;
58		else if (sizex < sizey * ratio)
59			sizey = sizex / ratio;
60

61    }
62
63#if LOG_D3D
64    LOG_MSG("D3D:Scaled resolution: %.1fx%.1f, factor: %dx%d", sizex, sizey, x, y);
65#endif
66
67    D3DXMatrixScaling(&m_matWorld, sizex, sizey, 1.0f);
68}

With the updated code, this code could also be changed to be cleaner: (sdlmain.cpp, lines 1502-1504)

1		    // Don't do aspect ratio correction when fullfixed=false + aspect=false
2			d3d->aspect=0;

Here's a couple quick notes on the old code:

• There is no code that ever sets aspect=0, so the if(aspect==0) block is unused. note that there is a condition which sets aspect=2, to disable the aspect code even if render.aspect=true.
• When aspect=1 and autofit=1, the code that takes the backbuffer size and divides it by sizex (or sizey) doesn't make sense, since the backbuffer is always equal to sizex or sizey. So then ratio_x and ratio_y always equal 1. So, if(ratio_x<ratio_y) always returns false, which is why it would not scale smaller vertically. (It must have been intended to do something else originally.)
• Autofit is not used anywhere other than in the direct3d code. This is already noted in the default conf file.

And on the new code:

• Autofit now is only used to detect 5:4 monitors and stretch to fill them; otherwise it defaults to a 4:3 aspect
• If in the future the windowed mode allows resizing, then autofit might not work as intended, as it should not detect 5:4 monitors when in windowed mode. This could be fixed by adding a condition in sdlmain.cpp around line 1500 that executes d3d->autofit=0 when in windowed mode

With a first attempt at adding the relevant normal optimizations, it showed a >5% decrease in performance. 😀 Used the Quake timedemo for practical results.

DOSBox-X should remove the non-functional directx driver selection from menu Video->Driver and also OpenGL-HQ from Video->Output.