VOGONS

Common searches


DOSBox-X branch

Topic actions

Reply 1200 of 2397, by emendelson

User metadata
Rank Oldbie
Rank
Oldbie
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 […]
Show full quote

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.

Reply 1201 of 2397, by TheGreatCodeholio

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

Reply 1202 of 2397, by emendelson

User metadata
Rank Oldbie
Rank
Oldbie

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

https://gist.github.com/panzi/6856583#file-portable_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 - […]
Show full quote

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-04-25, 15:56. Edited 2 times in total.

Reply 1203 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
emendelson wrote:
Now why didn't I think of that? ;) […]
Show full quote
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 […]
Show full quote

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.

Reply 1204 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
emendelson wrote:
Wait, I found this renamed it endian.h and put it include, and got past that error: […]
Show full quote

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

https://gist.github.com/panzi/6856583#file-portable_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 - […]
Show full quote

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.

Reply 1205 of 2397, by emendelson

User metadata
Rank Oldbie
Rank
Oldbie
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:4 […]
Show full quote

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 […]
Show full quote

#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...

Reply 1206 of 2397, by emendelson

User metadata
Rank Oldbie
Rank
Oldbie

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 […]
Show full quote

#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] […]
Show full quote

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-04-25, 17:03. Edited 1 time in total.

Reply 1207 of 2397, by emendelson

User metadata
Rank Oldbie
Rank
Oldbie

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 - […]
Show full quote

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.

Reply 1208 of 2397, by emendelson

User metadata
Rank Oldbie
Rank
Oldbie

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_Boo […]
Show full quote

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!

Reply 1209 of 2397, by hail-to-the-ryzen

User metadata
Rank Member
Rank
Member

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?

Reply 1210 of 2397, by hail-to-the-ryzen

User metadata
Rank Member
Rank
Member

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.

Reply 1211 of 2397, by zschni

User metadata
Rank Newbie
Rank
Newbie

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.

Reply 1212 of 2397, by Zirias

User metadata
Rank Newbie
Rank
Newbie

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

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:

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.

Reply 1216 of 2397, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie

Direct3D is set as default:

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

#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.

http://www.si-gamer.net/gulikoza

Reply 1217 of 2397, by James-F

User metadata
Rank Oldbie
Rank
Oldbie

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!


my important / useful posts are here

Reply 1218 of 2397, by hail-to-the-ryzen

User metadata
Rank Member
Rank
Member

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.

Reply 1219 of 2397, by delta^1_1

User metadata
Rank Newbie
Rank
Newbie

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.