DOSBox-X branch

Here you can discuss the development of patches.

Re: DOSBox-X branch

Postby emendelson » 2017-4-25 @ 15:23

Dominus wrote:You just need to stop using those project files but use mingw(64?) for this ;)


Now why didn't I think of that? ;)

I can build DOSBox SVN in mingw (32-bit Windows 7), so I tried this, but I came up against the lack of the endian.h file that The Great Codeholio mentioned. Here's the error:

make[4]: Entering directory `/home/Edward/dosbox-x-master/src/cpu'
g++ -DHAVE_CONFIG_H -I. -I../.. -I../../include -I/usr/local/include/SDL -D_GNU
_SOURCE=1 -Dmain=SDL_main -g -O2 -Wall -mmmx -msse -msse2 -D_FILE_OFFSET_BITS=6
4 -Wno-strict-aliasing -std=gnu++0x -MT callback.o -MD -MP -MF .deps/callback.T
po -c -o callback.o callback.cpp
In file included from ../../include/callback.h:24:0,
from callback.cpp:24:
../../include/mem.h:34:21: fatal error: endian.h: No such file or directory
compilation terminated.


So I'm still at a loss here, unfortunately.
emendelson
Oldbie
 
Posts: 640
Joined: 2010-2-14 @ 02:00

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2017-4-25 @ 15:30

emendelson wrote:But I wasn't being sarcastic! I really don't know how to do this, and I wasn't asking you to do it! (It's always annoying when someone asks someone else to write something...) There are a lot of Win32 types around here who could write that file in three minutes if they wanted to build for Windows, as surely someone else will want to do. There was absolutely zero sarcasm - I'm too grateful for this project to be sarcastic about it!


Sorry about that, then. It's hard to determine tone from pure text.
DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.
TheGreatCodeholio
Member
 
Posts: 369
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby emendelson » 2017-4-25 @ 15:31

Wait, I found this, renamed it endian.h, and put it in include, and got past that error:

https://gist.github.com/panzi/6856583#f ... e_endian-h

But then I got this error much later:

mv -f .deps/core_prefetch.Tpo .deps/core_prefetch.Po
g++ -DHAVE_CONFIG_H -I. -I../.. -I../../include -I/usr/local/include/SDL -D_GNU
_SOURCE=1 -Dmain=SDL_main -g -O2 -Wall -mmmx -msse -msse2 -D_FILE_OFFSET_BITS=6
4 -Wno-strict-aliasing -std=gnu++0x -MT core_dyn_x86.o -MD -MP -MF .deps/core_d
yn_x86.Tpo -c -o core_dyn_x86.o core_dyn_x86.cpp
In file included from core_dyn_x86/dyn_fpu.h:51:0,
from core_dyn_x86/decoder.h:1963,
from core_dyn_x86.cpp:234:
core_dyn_x86/../../fpu/fpu_instructions.h: In function 'void FPU_FCOM(Bitu, Bitu
)':
core_dyn_x86/../../fpu/fpu_instructions.h:457:27: error: 'isinf' was not declare
d in this scope
if (isinf(fpu.regs[st].d) && isinf(fpu.regs[other].d)) {
^
core_dyn_x86/../../fpu/fpu_instructions.h:457:27: note: suggested alternative:
In file included from core_dyn_x86/../../fpu/fpu_instructions.h:324:0,
from core_dyn_x86/dyn_fpu.h:51,
from core_dyn_x86/decoder.h:1963,
from core_dyn_x86.cpp:234:
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\cmath:621:5: note: 'std::isinf'
isinf(_Tp __x)
^
make[4]: *** [core_dyn_x86.o] Error 1
Last edited by emendelson on 2017-4-25 @ 15:56, edited 2 times in total.
emendelson
Oldbie
 
Posts: 640
Joined: 2010-2-14 @ 02:00

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2017-4-25 @ 15:34

emendelson wrote:
Dominus wrote:You just need to stop using those project files but use mingw(64?) for this ;)


Now why didn't I think of that? ;)

I can build DOSBox SVN in mingw (32-bit Windows 7), so I tried this, but I came up against the lack of the endian.h file that The Great Codeholio mentioned. Here's the error:

make[4]: Entering directory `/home/Edward/dosbox-x-master/src/cpu'
g++ -DHAVE_CONFIG_H -I. -I../.. -I../../include -I/usr/local/include/SDL -D_GNU
_SOURCE=1 -Dmain=SDL_main -g -O2 -Wall -mmmx -msse -msse2 -D_FILE_OFFSET_BITS=6
4 -Wno-strict-aliasing -std=gnu++0x -MT callback.o -MD -MP -MF .deps/callback.T
po -c -o callback.o callback.cpp
In file included from ../../include/callback.h:24:0,
from callback.cpp:24:
../../include/mem.h:34:21: fatal error: endian.h: No such file or directory
compilation terminated.


So I'm still at a loss here, unfortunately.


Hm? Why doesn't mingw have an endian.h?
DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.
TheGreatCodeholio
Member
 
Posts: 369
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2017-4-25 @ 15:35

emendelson wrote:Wait, I found this renamed it endian.h and put it include, and got past that error:

https://gist.github.com/panzi/6856583#f ... e_endian-h

But then I got this error much later:

mv -f .deps/core_prefetch.Tpo .deps/core_prefetch.Po
g++ -DHAVE_CONFIG_H -I. -I../.. -I../../include -I/usr/local/include/SDL -D_GNU
_SOURCE=1 -Dmain=SDL_main -g -O2 -Wall -mmmx -msse -msse2 -D_FILE_OFFSET_BITS=6
4 -Wno-strict-aliasing -std=gnu++0x -MT core_dyn_x86.o -MD -MP -MF .deps/core_d
yn_x86.Tpo -c -o core_dyn_x86.o core_dyn_x86.cpp
In file included from core_dyn_x86/dyn_fpu.h:51:0,
from core_dyn_x86/decoder.h:1963,
from core_dyn_x86.cpp:234:
core_dyn_x86/../../fpu/fpu_instructions.h: In function 'void FPU_FCOM(Bitu, Bitu
)':
core_dyn_x86/../../fpu/fpu_instructions.h:457:27: error: 'isinf' was not declare
d in this scope
if (isinf(fpu.regs[st].d) && isinf(fpu.regs[other].d)) {
^
core_dyn_x86/../../fpu/fpu_instructions.h:457:27: note: suggested alternative:
In file included from core_dyn_x86/../../fpu/fpu_instructions.h:324:0,
from core_dyn_x86/dyn_fpu.h:51,
from core_dyn_x86/decoder.h:1963,
from core_dyn_x86.cpp:234:
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\cmath:621:5: note: 'std::isinf'
isinf(_Tp __x)
^
make[4]: *** [core_dyn_x86.o] Error 1


It looks like for mingw you'll need to #include <cmath> for isinf to work.

isinf is fairly messy across multiple targets, apparently.
DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.
TheGreatCodeholio
Member
 
Posts: 369
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby emendelson » 2017-4-25 @ 15:46

TheGreatCodeholio wrote:It looks like for mingw you'll need to #include <cmath> for isinf to work.

isinf is fairly messy across multiple targets, apparently.


So I tried adding this line to fpu_instructions.h (I'm only guessing that that's where it should go), below #include <math.h>

#include <cmath>


But on building, I seem to get the same error as before:

core_dyn_x86/../../fpu/fpu_instructions.h: In function 'void FPU_FCOM(Bitu, Bitu
)':
core_dyn_x86/../../fpu/fpu_instructions.h:458:27: error: 'isinf' was not declare
d in this scope
if (isinf(fpu.regs[st].d) && isinf(fpu.regs[other].d)) {
^
core_dyn_x86/../../fpu/fpu_instructions.h:458:27: note: suggested alternative:
In file included from core_dyn_x86/../../fpu/fpu_instructions.h:20:0,
from core_dyn_x86/dyn_fpu.h:51,
from core_dyn_x86/decoder.h:1963,
from core_dyn_x86.cpp:234:
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\cmath:621:5: note: 'std::isinf'
isinf(_Tp __x)
^
make[4]: *** [core_dyn_x86.o] Error 1


Should that include line go somewhere else?

Edit: I also tried reversing the order of the two includes, and tried replacing the include for math.h with the include for cmath, but got the same error each time.

Edit again: I see that <include cmath> is already defined around line 325, so I added it again here:

#if defined(WIN32) && defined(_MSC_VER)
/* std::isinf is C99 standard how could you NOT have this VS2008??? */
# include <math.h>
# include <cmath> // added
/* the purpose of this macro is to test for -/+inf. NaN is not inf. If finite or NaN it's not infinity */


But I ended up with the same error...
emendelson
Oldbie
 
Posts: 640
Joined: 2010-2-14 @ 02:00

Re: DOSBox-X branch

Postby emendelson » 2017-4-25 @ 16:54

OK, so this solved the fpu_instructions.h error (see the line below "added for mingw"):

#if defined(WIN32) && defined(_MSC_VER)
/* std::isinf is C99 standard how could you NOT have this VS2008??? */
# include <math.h>
/* the purpose of this macro is to test for -/+inf. NaN is not inf. If finite or NaN it's not infinity */
# define isinf(x) (!(_finite(x) || _isnan(x)))
# define isdenormal(x) (_fpclass(x) == _FPCLASS_ND || _fpclass(x) == _FPCLASS_PD)
#else
# include <math.h>
# include <cmath>
# define isdenormal(x) (!std::isnormal(x))
// added for mingw:
# define isinf(x) (!(_finite(x) || _isnan(x)))
// end added for mingw
#endif


I tried to build again, but ended with this (I can't see where the actual error might be):

make[3]: *** [sdlmain.o] Error 1
make[3]: Leaving directory `/home/Edward/dosbox-x-master/src/gui'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/Edward/dosbox-x-master/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/Edward/dosbox-x-master'
make: *** [all] Error 2


EDIT: I found the error; see next message.
Last edited by emendelson on 2017-4-25 @ 17:03, edited 1 time in total.
emendelson
Oldbie
 
Posts: 640
Joined: 2010-2-14 @ 02:00

Re: DOSBox-X branch

Postby emendelson » 2017-4-25 @ 17:00

For what it's worth, here's the error that I got when building gui:

sdlmain.cpp: In function 'int SDL_main(int, char**)':
sdlmain.cpp:4482:27: error: 'ImmDisableIME' was not declared in this scope
ImmDisableIME((DWORD)(-1));


EDIT: So I commented out that line in sdlmain.cpp, and got this far:

g++ -DHAVE_CONFIG_H -I. -I../.. -I../../include -I/usr/local/include/SDL -D_GNU
_SOURCE=1 -Dmain=SDL_main -g -O2 -Wall -mmmx -msse -msse2 -D_FILE_OFFSET_BITS=6
4 -Wno-strict-aliasing -std=gnu++0x -MT direct3d.o -MD -MP -MF .deps/direct3d.T
po -c -o direct3d.o direct3d.cpp
In file included from direct3d.cpp:46:0:
d3d_components.h:6975:25: fatal error: D3dx9shader.h: No such file or directory
compilation terminated.


I messed with the d3d_components.h file but got nowhere. I think I see some more things to try and will report later.
emendelson
Oldbie
 
Posts: 640
Joined: 2010-2-14 @ 02:00

Re: DOSBox-X branch

Postby emendelson » 2017-4-25 @ 17:17

I think the problem is that I added the optional DirectX components to mingw, following the method in the wiki. So I renamed four DirectX-related headers in the mingw include directory, and then got this far:

In file included from menu.cpp:23:0:
../../include/menu.h:46:36: error: '_MAX_DRIVE' was not declared in this scope
void Go_Boot(const char boot_drive[_MAX_DRIVE]);
^
../../include/menu.h:47:37: error: '_MAX_DRIVE' was not declared in this scope
void Go_Boot2(const char boot_drive[_MAX_DRIVE]);


This one I can't figure out for myself, I'm afraid!
emendelson
Oldbie
 
Posts: 640
Joined: 2010-2-14 @ 02:00

Re: DOSBox-X branch

Postby hail-to-the-ryzen » 2017-4-26 @ 02:23

Thank you for the help with interpreting the titlebar meters! It seems that performance and estimation of values has a large (or entire) role in the real-time meter values. I also wonder if a meter could be developed to test whether UT99 is running as expected. I recall that it uses the cpu speed instead of real time to calibrate the speed of its game engine. Although a cycles= setting will ensure a preset cycle rate, does this cycle rate directly correspond to cpu speed? And would a possible cpu speed setting along with cycles=max lead to faster emulation as compared to the use of cycles=? Perhaps the use of hysteresis to maintain the highest possible cycle rate on average where the dips in cycles are not too low?
hail-to-the-ryzen
Newbie
 
Posts: 64
Joined: 2017-3-09 @ 01:34

Re: DOSBox-X branch

Postby hail-to-the-ryzen » 2017-4-27 @ 04:34

On reading other posts, it seems that UT99 bases its clock on the RDTSC instruction. This makes sense since the instruction depends on cpu speed. In the normal core, tsc is set to CPU_CycleMax. This presumably will vary with cycles=max? If the variation is high, is it feasible to use a fixed real clock instead? I also assume that a fixed value for cycles will do the same.

However, an advantage of the fixed clock is that the game would keep time at a constant rate, and if the cycles did not keep up, then the game would just slow down. It seems better than the opposite. Also, it would maximize the overall average frame rate.
hail-to-the-ryzen
Newbie
 
Posts: 64
Joined: 2017-3-09 @ 01:34

Re: DOSBox-X branch

Postby zschni » 2017-5-01 @ 15:16

Hello, I am totally new here, but I ran into this forum many times before. Yesterday I did not even know, how to compile things from Git, today I successfully installed dosbox-x with sudo checkinstall. I would like to use this software for Extreme Assault mostly, but everything in the application is very and very slow, and in other applications also (Prince of Persia, Mario...) I succesfully wrote the config file, but eh.. so many options comparing to dosbox 0.74. I was messing with the game's 3dfx laucher also, without success, and sadly I do not even understand what the people are talking about, regarding glide support in linux and to compile the dosbox, with openglide and ovl and dll files... :/
So what I would like to have is more "fps" in the game. I am mostly comfortable with the original dosbox config file, but here... too many options to mess with. My cpu usage on 1 core is never more than 50% when playing.
My PC is like that. Thank you in advance.
zschni
Newbie
 
Posts: 6
Joined: 2017-5-01 @ 14:56

Re: DOSBox-X branch

Postby Zirias » 2017-5-04 @ 14:29

Just tried to build this from github using my mingw64 toolchain in msys64 .. and after a few tweaks to the code, this SEEMS to work. But running the compiled binary fails with
Code: Select all
LOG: E_Exit: D3D not supported

This is on a windows 10 machine. Any ideas what I could do about this?

edit: It indeed runs fine without D3D .. I hacked configure.ac as follows to be able to build ignoring the installed d3d9.h file:

Code: Select all
diff --git a/configure.ac b/configure.ac
index 3fc7936d..8f0e7279 100644
--- a/configure.ac
+++ b/configure.ac
@@ -499,7 +499,7 @@ int main(int argc,char * argv[]) {
 dnl Some target detection and actions for them
 case "$host" in
     *-*-cygwin* | *-*-mingw32*)
-       LIBS="$LIBS -lwinmm"
+       LIBS="$LIBS -lwinmm -limm32"
        AH_TEMPLATE(C_D3DSHADERS,[Define to 1 to use Direct3D shaders, requires d3d9.h and libd3dx9])
        AC_ARG_WITH(dx-headers,[  --with-dx-headers=DIR   DirectX include files location],
                   dx_headers="$withval", dx_headers="")
@@ -511,11 +511,13 @@ case "$host" in
        fi
        AC_LANG(C++)
        AC_CHECK_HEADERS(ddraw.h)
+       AC_MSG_CHECKING(whether direct3d display output should be enabled)
+       AC_ARG_ENABLE(d3d,AC_HELP_STRING([--disable-d3d],[Disable direct3d display output]),AC_MSG_RESULT(no),[
+       AC_MSG_RESULT(yes)
        AC_CHECK_HEADERS(d3d9.h,have_d3d9_h=yes,)
-       AC_MSG_CHECKING(whether direct3d display output will be enabled)
        if test x$have_d3d9_h = xyes ; then
-        AC_MSG_RESULT(yes)
-        AC_ARG_ENABLE(shaders,AC_HELP_STRING([--disable-shaders],[Disable d3d pixelshader support (which requires libd3dx9)]),,[
+       AC_MSG_RESULT(yes)
+       AC_ARG_ENABLE(shaders,AC_HELP_STRING([--disable-shaders],[Disable d3d pixelshader support (which requires libd3dx9)]),,[
                AC_MSG_CHECKING(whether direct3d pixelshaders will be enabled)
                ac_save_LIBS=$LIBS
                if test x$dx_libs != x ; then
@@ -535,9 +537,11 @@ case "$host" in
                fi
        ],)
        else
-        CPPFLAGS=$ac_save_CPPFLAGS
-        AC_MSG_RESULT(no)
+       CPPFLAGS=$ac_save_CPPFLAGS
+       AC_MSG_RESULT(no)
+       AC_MSG_WARN(d3d9.h not found, disabling direct3d display output)
        fi
+       ],)
        AC_DEFINE(C_DIRECTSERIAL, 1, [ Define to 1 if you want serial passthrough support (Win32, Posix and OS/2 only).])
        AC_DEFINE(C_DIRECTLPT, 1, [ Define to 1 if you want parallel passthrough support (Win32 only).])
        if test x$have_sdl_net_lib = xyes -a x$have_sdl_net_h = xyes ; then

This enables a new configure switch --disable-d3d.
Zirias
Newbie
 
Posts: 39
Joined: 2010-5-08 @ 07:22

Re: DOSBox-X branch

Postby gulikoza » 2017-5-06 @ 07:27

Perhaps you shouldn't select direct3d in the config then if it's not supported?
User avatar
gulikoza
Oldbie
 
Posts: 1698
Joined: 2004-6-25 @ 14:53

Re: DOSBox-X branch

Postby Zirias » 2017-5-09 @ 13:51

I didn't select anything, it just exits immediately when built with D3D. I don't hack the M4 autotools madness just for fun ;)
Zirias
Newbie
 
Posts: 39
Joined: 2010-5-08 @ 07:22

Re: DOSBox-X branch

Postby hail-to-the-ryzen » 2017-5-10 @ 22:30

Is it possible to declare cycle_count as "extern" only once in the source code?
hail-to-the-ryzen
Newbie
 
Posts: 64
Joined: 2017-3-09 @ 01:34

Re: DOSBox-X branch

Postby gulikoza » 2017-5-14 @ 06:21

Direct3D is set as default:

Code: Select all
#ifdef __WIN32__
      Pstring = sdl_sec->Add_string("output",Property::Changeable::Always,"direct3d");
#else


yet, the init function is set to trigger the error when d3d is initialized:

Code: Select all
#ifdef __WIN32__
static void d3d_init(void) {
#if 1
   E_Exit("D3D not supported");
#else


I don't see the reason autotools should be hacked, when the fault clearly lies in the code.
If D3D is not supported, then it should not be selected as the output mode.
User avatar
gulikoza
Oldbie
 
Posts: 1698
Joined: 2004-6-25 @ 14:53

Re: DOSBox-X branch

Postby James-F » 2017-5-16 @ 11:36

Hi.

Is there any way to extract the diff between the sblaster.cpp code to implement ESS and proper Filtering into the vanilla DOSBox?
I can create a diff, but I have to know what files are responsible for ESS audio changes.
mixer.cpp, sblaster.cpp, dosbox.cpp?

Thanks!
User avatar
James-F
Oldbie
 
Posts: 1400
Joined: 2015-11-30 @ 04:10

Re: DOSBox-X branch

Postby hail-to-the-ryzen » 2017-5-18 @ 22:01

The dosbox-x normal core handles the virtual memory system of cwsdpmi (djgpp dpmi provider). However, with unusually high memory use by a dos program, the x86 based core handles the paging slowly which can lead to a page fault. It seems best to avoid paging in these instances by specifying high values of RAM and testing the parameter to disable paging by the dpmi provider. I haven't tested this thoroughly, but this effect is mainly seen where the requirement is >128Mb of RAM.
hail-to-the-ryzen
Newbie
 
Posts: 64
Joined: 2017-3-09 @ 01:34

Submitting a patch for DOSBox-X

Postby delta^1_1 » 2017-5-23 @ 21:10

How should I submit a patch for inclusion in DOSBox-X?

I've got this old patch that's been sitting around for years. What it does is add support for DOS's legacy CPM entry point -- and I know people who run old programs using this, so it would be really good to get the support added to a public version of DOSBox.

I did send the patch to the original DOSBox developer team, but they didn't seem to be very interested in it (and there hasn't been much activity from them anyway). Maybe it will get a better reception here.
delta^1_1
Newbie
 
Posts: 1
Joined: 2017-5-23 @ 19:33

PreviousNext

Return to DOSBox Patches

Who is online

Users browsing this forum: No registered users and 1 guest