VOGONS

Common searches


DOSBox-X branch

Topic actions

Reply 1360 of 2410, by Darkstar

User metadata
Rank Newbie
Rank
Newbie
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..

Reply 1361 of 2410, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

🤣 no.

Agree to disagree.

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

How To Ask Questions The Smart Way
Make your games work offline

Reply 1362 of 2410, by collector

User metadata
Rank l33t
Rank
l33t
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.

The Sierra Help Pages -- New Sierra Game Installers -- Sierra Game Patches -- New Non-Sierra Game Installers

Reply 1363 of 2410, by hail-to-the-ryzen

User metadata
Rank Member
Rank
Member

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:

diff -rupN SDL-1.2-Orig//src/video/SDL_video.c SDL-1.2//src/video/SDL_video.c
--- SDL-1.2-Orig//src/video/SDL_video.c
+++ SDL-1.2//src/video/SDL_video.c
@@ -78,9 +78,9 @@ static VideoBootStrap *bootstrap[] = {
#if SDL_VIDEO_DRIVER_GAPI
&GAPI_bootstrap,
#endif
-#if SDL_VIDEO_DRIVER_DDRAW
+/* #if SDL_VIDEO_DRIVER_DDRAW
&DIRECTX_bootstrap,
-#endif
+#endif */
#if SDL_VIDEO_DRIVER_WINDIB
&WINDIB_bootstrap,
#endif

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

diff -rupN SDL-1.2-Orig//src/thread/win32/SDL_sysmutex.c SDL-1.2/src/thread/win32/SDL_sysmutex.c
--- SDL-1.2-Orig//src/thread/win32/SDL_sysmutex.c
+++ SDL-1.2/src/thread/win32/SDL_sysmutex.c
@@ -30,7 +30,7 @@


struct SDL_mutex {
- HANDLE id;
+ CRITICAL_SECTION cs;
};

/* Create a mutex */
@@ -42,12 +42,7 @@ SDL_mutex *SDL_CreateMutex(void)
mutex = (SDL_mutex *)SDL_malloc(sizeof(*mutex));
if ( mutex ) {
/* Create the mutex, with initial value signaled */
- mutex->id = CreateMutex(NULL, FALSE, NULL);
- if ( ! mutex->id ) {
- SDL_SetError("Couldn't create mutex");
- SDL_free(mutex);
- mutex = NULL;
- }
+ InitializeCriticalSection(&mutex->cs);
} else {
SDL_OutOfMemory();
}
@@ -58,10 +53,7 @@ SDL_mutex *SDL_CreateMutex(void)
void SDL_DestroyMutex(SDL_mutex *mutex)
{
if ( mutex ) {
- if ( mutex->id ) {
- CloseHandle(mutex->id);
- mutex->id = 0;
- }
+ DeleteCriticalSection(&mutex->cs);
SDL_free(mutex);
}
}
@@ -73,10 +65,7 @@ int SDL_mutexP(SDL_mutex *mutex)
SDL_SetError("Passed a NULL mutex");
return -1;
}
- if ( WaitForSingleObject(mutex->id, INFINITE) == WAIT_FAILED ) {
- SDL_SetError("Couldn't wait on mutex");
- return -1;
- }
+ EnterCriticalSection(&mutex->cs);
return(0);
}

@@ -87,9 +76,6 @@ int SDL_mutexV(SDL_mutex *mutex)
SDL_SetError("Passed a NULL mutex");
return -1;
}
- if ( ReleaseMutex(mutex->id) == FALSE ) {
- SDL_SetError("Couldn't release mutex");
- return -1;
- }
+ LeaveCriticalSection(&mutex->cs);
return(0);
Show last 1 line
 }

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:

diff -rupN SDL-1.2-ORIG//src/video/windib/SDL_dibvideo.c SDL-1.2//src/video/windib/SDL_dibvideo.c
--- SDL-1.2-ORIG//src/video/windib/SDL_dibvideo.c
+++ SDL-1.2//src/video/windib/SDL_dibvideo.c
@@ -821,7 +821,7 @@ SDL_Surface *DIB_SetVideoMode(_THIS, SDL
} else {
#ifndef NO_CHANGEDISPLAYSETTINGS
if ( (prev_flags & SDL_FULLSCREEN) == SDL_FULLSCREEN ) {
- ChangeDisplaySettings(NULL, 0);
+ ChangeDisplaySettings(NULL, CDS_FULLSCREEN);
}
#endif
if ( flags & SDL_NOFRAME ) {
@@ -1215,7 +1215,7 @@ void DIB_VideoQuit(_THIS)
}
#ifndef NO_CHANGEDISPLAYSETTINGS
if ( this->screen->flags & SDL_FULLSCREEN ) {
- ChangeDisplaySettings(NULL, 0);
+ ChangeDisplaySettings(NULL, CDS_FULLSCREEN);
ShowWindow(SDL_Window, SW_HIDE);
}
#endif

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

Reply 1364 of 2410, by hail-to-the-ryzen

User metadata
Rank Member
Rank
Member

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.

Reply 1365 of 2410, by hail-to-the-ryzen

User metadata
Rank Member
Rank
Member

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

void CPU_Core_Dyn_X86_SaveDHFPUState(void) {
}

void CPU_Core_Dyn_X86_RestoreDHFPUState(void) {
}

Reply 1366 of 2410, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

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

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 1368 of 2410, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

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

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 1369 of 2410, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

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

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 1370 of 2410, by Shane32

User metadata
Rank Newbie
Rank
Newbie

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):

[sdl]
output=direct3d
fullscreen=true
[dosbox]
a20=mask
[render]
aspect=true
scaler=normal3x
[vsync]
# vsyncmode=host
[cpu]
fpu=false
cycles=25000
[midi]
mpu401=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.

Reply 1371 of 2410, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

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.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 1372 of 2410, by hail-to-the-ryzen

User metadata
Rank Member
Rank
Member

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.

 	Uint32 sdl_flags = SDL_OPENGL;

- ogl_surface = SDL_SetVideoMode(v->fbi.width, v->fbi.height, 32, sdl_flags);
+ ogl_surface = SDL_SetVideoMode(v->fbi.width, v->fbi.height, 16, sdl_flags);
+ ogl_surface = NULL;
+ ogl_surface = SDL_SetVideoMode(v->fbi.width, v->fbi.height, 32, sdl_flags);

if (ogl_surface == NULL) {
if (full_sdl_restart) {

Reply 1373 of 2410, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

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

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 1374 of 2410, by hail-to-the-ryzen

User metadata
Rank Member
Rank
Member

Please try this instead:

diff -rupN dosbox-x-Orig/src/hardware/voodoo_opengl.cpp dosbox-x//src/hardware/voodoo_opengl.cpp
--- dosbox-x-Orig/src/hardware/voodoo_opengl.cpp
+++ dosbox-x//src/hardware/voodoo_opengl.cpp
@@ -1609,12 +1609,6 @@ void voodoo_ogl_set_window(voodoo_state
}

void voodoo_ogl_reset_videomode(void) {
-#if defined(WIN32) && !defined(C_SDL2)
- /* always show the menu */
- void DOSBox_SetMenu(void);
- DOSBox_SetMenu();
-#endif
-
GFX_PreventFullscreen(true);

last_clear_color=0;
@@ -1669,7 +1663,10 @@ void voodoo_ogl_reset_videomode(void) {

Uint32 sdl_flags = SDL_OPENGL;

- ogl_surface = SDL_SetVideoMode(v->fbi.width, v->fbi.height, 32, sdl_flags);
+ ogl_surface = SDL_SetVideoMode(v->fbi.width, v->fbi.height, 16, sdl_flags);
+ ogl_surface = NULL;
+
+ ogl_surface = SDL_SetVideoMode(v->fbi.width, v->fbi.height, 32, sdl_flags);

if (ogl_surface == NULL) {
if (full_sdl_restart) {
@@ -1750,13 +1747,6 @@ void voodoo_ogl_reset_videomode(void) {
LOG_MSG("VOODOO: OpenGL: invalid depth size %d",depth_csize);
}

-#if defined(WIN32) && !defined(C_SDL2)
- // Windows SDL 1.x builds may destroy and re-create the window, and lose our menu bar.
- // make sure to put it back.
- void DOSBox_SetMenu(void);
- DOSBox_SetMenu();
-#endif
-
/* Something in Windows keeps changing the shade model on us from the last glShadeModel() call. Change it back. */
glShadeModel(GL_SMOOTH);

Reply 1375 of 2410, by Shane32

User metadata
Rank Newbie
Rank
Newbie

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.

Reply 1376 of 2410, by Shane32

User metadata
Rank Newbie
Rank
Newbie

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

void CDirect3D::SetupSceneScaled(void)
{
double sizex,sizey,ratio;

// TODO: It would probably be nicer to offer an option here whether the user wants
// point sampling (D3DTEXF_POINT) or linear interpolation (D3DTEXF_LINEAR) when scaling up/down.
pD3DDevice9->SetTextureStageState(0, D3DTSS_COLOROP, D3DTOP_MODULATE);
pD3DDevice9->SetTextureStageState(0, D3DTSS_COLORARG1, D3DTA_TEXTURE);
pD3DDevice9->SetTextureStageState(0, D3DTSS_COLORARG2, D3DTA_DIFFUSE);
pD3DDevice9->SetTextureStageState(0, D3DTSS_ALPHAOP, D3DTOP_MODULATE);
pD3DDevice9->SetTextureStageState(0, D3DTSS_ALPHAARG1, D3DTA_TEXTURE);
pD3DDevice9->SetTextureStageState(0, D3DTSS_ALPHAARG2, D3DTA_DIFFUSE);
pD3DDevice9->SetSamplerState(0, D3DSAMP_MINFILTER, D3DTEXF_LINEAR);
pD3DDevice9->SetSamplerState(0, D3DSAMP_MAGFILTER, D3DTEXF_LINEAR);
pD3DDevice9->SetSamplerState(0, D3DSAMP_MIPFILTER, D3DTEXF_NONE);

D3DVIEWPORT9 Viewport;
pD3DDevice9->GetViewport(&Viewport);

// Projection is screenspace coords
D3DXMatrixOrthoOffCenterLH(&m_matProj, 0.0f, (float)Viewport.Width, 0.0f, (float)Viewport.Height, 0.0f, 1.0f);

// View matrix does offset
// A -0.5f modifier is applied to vertex coordinates to match texture
// and screen coords. Some drivers may compensate for this
// automatically, but on others texture alignment errors are introduced
// More information on this can be found in the Direct3D 9 documentation
D3DXMatrixTranslation(&m_matView, (float)Viewport.Width/2-0.5f, (float)Viewport.Height/2+0.5f, 0.0f);

// World View does scaling
sizex = dwScaledWidth;
sizey = dwScaledHeight;

// aspect = 2 in certain conditions to disable aspect code, but typically aspect = render.aspect
if((aspect == 1) && (dwWidth > 0) && (dwHeight > 0)) {
// render.aspect IMPLEMENTED

// We'll try to make the image as close as possible to 4:3
// (square pixels assumed (as in lcd not crt))

//when autofit=true, scale instead to 5:4 if the monitor is a 5:4 monitor (1280x1024)
if (autofit && ((sizex / sizey) == (5.0 / 4.0))) {
ratio = 5.0 / 4.0;
#if LOG_D3D
LOG_MSG("D3D:Scaling image to 5:4");
#endif
}
else
{
ratio = 4.0 / 3.0;
#if LOG_D3D
LOG_MSG("D3D:Scaling image to 4:3");
#endif
}

if (sizex > sizey * ratio)
sizex = sizey * ratio;
else if (sizex < sizey * ratio)
sizey = sizex / ratio;

Show last 8 lines
    }

#if LOG_D3D
LOG_MSG("D3D:Scaled resolution: %.1fx%.1f, factor: %dx%d", sizex, sizey, x, y);
#endif

D3DXMatrixScaling(&m_matWorld, sizex, sizey, 1.0f);
}

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

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

Reply 1377 of 2410, by Shane32

User metadata
Rank Newbie
Rank
Newbie

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