DOSBox-X branch

Here you can discuss the development of patches.

Re: DOSBox-X branch

Postby Darkstar » 2018-2-12 @ 20:13

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..
User avatar
Darkstar
Newbie
 
Posts: 25
Joined: 2003-10-21 @ 18:13

Re: DOSBox-X branch

Postby DosFreak » 2018-2-12 @ 20:33

lol no.

Agree to disagree.

Please post your delusions in a new thread so they can be shot down piece by piece.
User avatar
DosFreak
l33t++
 
Posts: 9648
Joined: 2002-6-30 @ 16:35
Location: Your Head

Re: DOSBox-X branch

Postby collector » 2018-2-13 @ 01:32

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.
User avatar
collector
l33t
 
Posts: 4121
Joined: 2003-1-15 @ 10:39

Re: DOSBox-X branch

Postby hail-to-the-ryzen » 2018-2-13 @ 02:01

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:
Code: Select all
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:
Code: Select all
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);
 }
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:
Code: Select all
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.
hail-to-the-ryzen
Member
 
Posts: 185
Joined: 2017-3-09 @ 01:34

Re: DOSBox-X branch

Postby hail-to-the-ryzen » 2018-2-19 @ 10:16

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.
hail-to-the-ryzen
Member
 
Posts: 185
Joined: 2017-3-09 @ 01:34

Re: DOSBox-X branch

Postby hail-to-the-ryzen » 2018-2-20 @ 05:37

Dynamic core has the same above issue as the normal core where emptying these functions that are used in the 3dfx/gl code:
Code: Select all
void CPU_Core_Dyn_X86_SaveDHFPUState(void) {
}

void CPU_Core_Dyn_X86_RestoreDHFPUState(void) {
}
hail-to-the-ryzen
Member
 
Posts: 185
Joined: 2017-3-09 @ 01:34

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2018-2-20 @ 06:04

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.
User avatar
TheGreatCodeholio
Oldbie
 
Posts: 504
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby hail-to-the-ryzen » 2018-2-20 @ 06:18

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?
hail-to-the-ryzen
Member
 
Posts: 185
Joined: 2017-3-09 @ 01:34

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2018-2-20 @ 06:21

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.
User avatar
TheGreatCodeholio
Oldbie
 
Posts: 504
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2018-2-20 @ 18:24

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.
User avatar
TheGreatCodeholio
Oldbie
 
Posts: 504
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby Shane32 » 2018-2-21 @ 00:17

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):
Code: Select all
[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.
User avatar
Shane32
Newbie
 
Posts: 12
Joined: 2018-1-01 @ 15:28

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2018-2-21 @ 00:20

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.
User avatar
TheGreatCodeholio
Oldbie
 
Posts: 504
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby hail-to-the-ryzen » 2018-2-21 @ 02:41

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.
Code: Select all
    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) {
hail-to-the-ryzen
Member
 
Posts: 185
Joined: 2017-3-09 @ 01:34

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2018-2-21 @ 08:36

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.
User avatar
TheGreatCodeholio
Oldbie
 
Posts: 504
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby hail-to-the-ryzen » 2018-2-21 @ 10:12

Please try this instead:
Code: Select all
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);
 
hail-to-the-ryzen
Member
 
Posts: 185
Joined: 2017-3-09 @ 01:34

Re: DOSBox-X branch

Postby Shane32 » 2018-2-21 @ 17:54

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.
User avatar
Shane32
Newbie
 
Posts: 12
Joined: 2018-1-01 @ 15:28

Re: DOSBox-X branch

Postby Shane32 » 2018-2-21 @ 18:13

Here's the updated code (direct3d.cpp, starting with line 1279):
Code: Select all
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;

    }

#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)
Code: Select all
          // Don't do aspect ratio correction when fullfixed=false + aspect=false
         d3d->aspect=0;
User avatar
Shane32
Newbie
 
Posts: 12
Joined: 2018-1-01 @ 15:28

Re: DOSBox-X branch

Postby Shane32 » 2018-2-21 @ 18:25

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
User avatar
Shane32
Newbie
 
Posts: 12
Joined: 2018-1-01 @ 15:28

Re: DOSBox-X branch

Postby hail-to-the-ryzen » 2018-2-23 @ 03:35

With a first attempt at adding the relevant normal optimizations, it showed a >5% decrease in performance. :) Used the Quake timedemo for practical results.
hail-to-the-ryzen
Member
 
Posts: 185
Joined: 2017-3-09 @ 01:34

Re: DOSBox-X branch

Postby hail-to-the-ryzen » 2018-2-25 @ 06:46

DOSBox-X should remove the non-functional directx driver selection from menu Video->Driver and also OpenGL-HQ from Video->Output.
hail-to-the-ryzen
Member
 
Posts: 185
Joined: 2017-3-09 @ 01:34

PreviousNext

Return to DOSBox Patches

Who is online

Users browsing this forum: No registered users and 3 guests