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.
Game Acronym List
DosBox CVS Builds
DosBox Feature Request Thread
DosBox FAQ
PC Game Compatibility List
"Who's got time to read all the way down to the bottom of an email?"
User avatar
DosFreak
l33t++
 
Posts: 9573
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: 4057
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: 108
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: 108
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: 108
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
Member
 
Posts: 468
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: 108
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
Member
 
Posts: 468
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Previous

Return to DOSBox Patches

Who is online

Users browsing this forum: No registered users and 2 guests