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: 9575
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: 4058
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: 109
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: 109
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: 109
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: 470
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: 109
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: 470
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
Member
 
Posts: 470
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: 6
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
Member
 
Posts: 470
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: 109
Joined: 2017-3-09 @ 01:34

Previous

Return to DOSBox Patches

Who is online

Users browsing this forum: No registered users and 1 guest