VOGONS


DOSBox ECE (for Windows & Linux)

Topic actions

Reply 760 of 1550, by Dagar

User metadata
Rank Newbie
Rank
Newbie
Yesterplay80 wrote:

Okay, I had to adjust some other patches after applying the "new" 3Dfx patch from kjliew, but I managed to get the windows version working again. I still have to get openglide into my Linux VM so I can try to compile the code there, too. In the meantime, it'd be nice if someone could give me some feedback if and how the new windows version (r4267) works, especially with the two 3Dfx emulation options!

Thanks for updating ECE with the new 3Dfx patch. Just tried r4267 (Windows) along with Elder Scrolls: Redguard and it seems to be working fine.

Reply 761 of 1550, by Delfino Furioso

User metadata
Rank Newbie
Rank
Newbie

thank you yesterplay!

I'll be glad to help with testing the new glide support options
I'd like however to try describing how these options work: I want my feedback to be useful, and so I need to use the software properly

Please let me know if there's something wrong with my recap

the "usual" kekko method

  • actually emulates voodoo1 hw in software (or opengl)
  • is configured using the [PCI] section of dosbox.conf

the "new" gulikoza method

  • it needs its own gliei2x.ovl library to be present alongside the dosbox.exe binary (ECE download currently does not include it)
  • it relies on an external glide wrapper (openglide, nglide, dgvoodoo) installed on the host system
  • is configured using the [GLIDE] section of dosbox.conf

WE SHOULD NOT ENABLE BOTH OF THEM AT THE SAME TIME
one should set alternatively:
(pci.voodoo=software/opengl AND glide.glide=false)
XOR
(pci.voodoo=false AND glide.glide=true)

Reply 762 of 1550, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
Delfino Furioso wrote:
WE SHOULD NOT ENABLE BOTH OF THEM AT THE SAME TIME one should set alternatively: (pci.voodoo=software/opengl AND glide.glide=fal […]
Show full quote

WE SHOULD NOT ENABLE BOTH OF THEM AT THE SAME TIME
one should set alternatively:
(pci.voodoo=software/opengl AND glide.glide=false)
XOR
(pci.voodoo=false AND glide.glide=true)

That is so wrong, both can actually be enabled at the same time.

For DOS, if you place the special pass-through copy of GLIDE2X.OVL in the same path that DOSBox was invoked, it will shadow a copy in its internal Z:\ drive. DOSBox default PATH is set to Z:\. And, you place the true GLIDE2X.OVL from 3Dfx in the root of the mounted directory or disk image. You then let the game to choose which Glide emulation mechanism by changing the order of PATH the OVL will be found first. At the default PATH, it will be the copy in Z:\, which is the pass-through mechanism, which technically gives better performance and visual. To switch to chip emulation, you simply change PATH=C:\;Z:\ and the game will find the 3Dfx copy of OVL.

For Win9x, it will be slightly more complicated. The default drivers/DLLs will be from 3Dfx and they are in the WINDOWS directory, so most of the Windows Glide games will start with chip emulation. If you would like the game to choose pass-through mechanism, then you would explicitly place the special pass-through GLIDE2X.DLL in the GAME directory. For games that pre-install a copy of GLIDE2X.DLL, it should be deleted or replaced accordingly.

Always check for the file size of DLL. The pass-through version is quite a magnitude smaller than the 3Dfx version for obvious reasons that its purpose is only to wrap the APIs.

If DOSBox console is available, then you can also look at the console output if Glide pass-through or VOODOO chip emulation is in action when the game activated 3D scene.

Glide:LFB access: read-write (no aux)
Glide:Activated
Glide:Resolution:640x480, LFB at 0x60000000 (physical) / 0x60000000 (linear)
VOODOO: OpenGL: mode set, resolution 640:480
VOODOO: OpenGL: quit
VOODOO: OpenGL: mode set, resolution 800:600
VOODOO: OpenGL: quit
Glide:Activated
Glide:Resolution:800x600, LFB at 0x60000000 (physical) / 0x60000000 (linear)
Last edited by kjliew on 2019-10-06, 04:21. Edited 1 time in total.

Reply 763 of 1550, by Delfino Furioso

User metadata
Rank Newbie
Rank
Newbie

uh ok thanks

so basically both "virtual devices" can co-exist as if they were two different video cards installed on the same pc
which one of them will be actually used it's a matter of which OVL library the application has access to...

The gulikoza OVL will activate the passthrough device which will forward every glide API call directly to the wrapper
the API calls conversion and the rendering will then happen in a different application context than the dosbox one

A game-provided OVL will find kekko's emulated voodoo1 and talk to it as if it was real hw
the emulated device will then convert the glide calls to OpenGL calls that dosbox will process within its own rendering context

Reply 764 of 1550, by Delfino Furioso

User metadata
Rank Newbie
Rank
Newbie

hello again, I'm back after some testing

I've tried to test different scenarios, here are the results:

  • 3DFX diagnostics kit (url) => OK with both kekko's emulation and gulikoza's passthrough
  • "TRIP" demoscene product (url) => OK with kekko's emulation, it crashes using gulikoza's OVL (i believe this to be an issue with the demo, not the patch)
  • Tomb Raider 1 => it does not rely on any OVL library and tries to interact directly with the hardware => OK with kekko's emulation, we'll never be able to test gulikoza's OVL
  • GTA1 (using DOS32/A after unbinding all executable, which is how I setup my game library by default): it crashes with both kekko's emulation and gulikoza's passthrough;
  • GTA1 (after re-enabling the embedded DOS4/GW extender): OK with both kekko's emulation and gulikoza's passthrough
  • Lands Of Lore 2 => same results as GTA1

NOTE:
I've had an issue with GTA, unrelated to glide emulation: the game cd-check failed.
the ISO+OGG image mounted fine, the game refused to recognize it as its own cd
it works only if I comment-out every "index" entry in the cue sheet

I've had a similar issue with Destruction Derby in the past wich was resolved (url) with the integration in ECE of the krcroft patch, which was in early stages of development at the time
I've tested DD again with ECE r4267 and the cd check fails here too - though, unlike GTA1, there's no workaround in commenting the PREGAP and/or INDEX entries

here are both CUE file I'm using

FILE "GTA1_01.iso" BINARY
TRACK 01 MODE1/2048
INDEX 01 00:00:00
FILE "GTA1_02.ogg" OGG
TRACK 02 AUDIO
INDEX 01 09:23:59
FILE "GTA1_03.ogg" OGG
TRACK 03 AUDIO
INDEX 01 11:42:61
FILE "GTA1_04.ogg" OGG
TRACK 04 AUDIO
INDEX 01 19:09:63
FILE "GTA1_05.ogg" OGG
TRACK 05 AUDIO
INDEX 01 28:52:65
FILE "GTA1_06.ogg" OGG
TRACK 06 AUDIO
INDEX 01 38:31:67
FILE "GTA1_07.ogg" OGG
TRACK 07 AUDIO
INDEX 01 46:04:69
FILE "GTA1_08.ogg" OGG
TRACK 08 AUDIO
INDEX 01 57:05:71
FILE "GTA1_09.ogg" OGG
TRACK 09 AUDIO
INDEX 01 60:18:73
FILE "GTA1_10.ogg" OGG
TRACK 10 AUDIO
INDEX 01 69:06:00
FILE "GTA1_11.ogg" OGG
TRACK 11 AUDIO
INDEX 01 70:09:02
FILE "dd1_01.iso" BINARY
TRACK 01 MODE1/2048
INDEX 01 00:00:00
FILE "dd1_02.ogg" OGG
TRACK 02 AUDIO
PREGAP 00:00:00
INDEX 01 01:19:51
FILE "dd1_03.ogg" OGG
TRACK 03 AUDIO
INDEX 01 06:55:31
FILE "dd1_04.ogg" OGG
TRACK 04 AUDIO
INDEX 01 12:16:51
FILE "dd1_05.ogg" OGG
TRACK 05 AUDIO
INDEX 01 17:40:60
FILE "dd1_06.ogg" OGG
TRACK 06 AUDIO
INDEX 01 22:55:44
FILE "dd1_07.ogg" OGG
TRACK 07 AUDIO
INDEX 01 28:14:16
FILE "dd1_08.ogg" OGG
TRACK 08 AUDIO
INDEX 01 33:27:17
FILE "dd1_09.ogg" OGG
TRACK 09 AUDIO
INDEX 01 35:49:51
FILE "dd1_10.ogg" OGG
TRACK 10 AUDIO
INDEX 01 38:57:39
FILE "dd1_11.ogg" OGG
TRACK 11 AUDIO
INDEX 01 39:22:19
FILE "dd1_12.ogg" OGG
TRACK 12 AUDIO
INDEX 01 39:34:06
FILE "dd1_13.ogg" OGG
TRACK 13 AUDIO
INDEX 01 39:46:40
FILE "dd1_14.ogg" OGG
TRACK 14 AUDIO
INDEX 01 42:26:21
FILE "dd1_15.ogg" OGG
TRACK 15 AUDIO
INDEX 01 45:04:47
FILE "dd1_16.ogg" OGG
TRACK 16 AUDIO
INDEX 01 50:15:38
FILE "dd1_17.ogg" OGG
TRACK 17 AUDIO
INDEX 01 54:52:23
FILE "dd1_18.ogg" OGG
TRACK 18 AUDIO
INDEX 01 55:03:04
FILE "dd1_19.ogg" OGG
TRACK 19 AUDIO
INDEX 01 60:01:37
FILE "dd1_20.ogg" OGG
TRACK 20 AUDIO
Show last 2 lines
    INDEX 01 60:22:29
Last edited by Delfino Furioso on 2019-10-07, 12:38. Edited 2 times in total.

Reply 765 of 1550, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie

Delfino, thanks for flagging the regression in Destruction Derby and your thorough testing.

When investigating https://sourceforge.net/p/dosbox/bugs/497/ I wound up convincing myself that my minute, second, frame handling code was no longer needed and could use the baseline code plus the update suggested bt RibShark in the bug.

I recall testing my MSF-specific games at the time. I will revisit the testing and if needed re-add MSF control , but possibly with the syntax suggested by RibShark in the bug. Will keep this thread posted as to the progress.

Reply 766 of 1550, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
Delfino Furioso wrote:
[…]
Show full quote
  • Tomb Raider 1 => it does not rely on any OVL library and tries to interact directly with the hardware => OK with kekko's emulation, we'll never be able to test gulikoza's OVL
  • GTA1 (using DOS32/A after unbinding all executable, which is how I setup my game library by default): it crashes with both kekko's emulation and gulikoza's passthrough;
  • GTA1 (after re-enabling the embedded DOS4/GW extender): OK with both kekko's emulation and gulikoza's passthrough
  • Lands Of Lore 2 => same results as GTA1

Tomb Raider 1 has 2 versions of patch, one called "3Dfx" and another called "Voodoo/Rush". The former is a static linked binaries that has in in-built real 3Dfx OVL so only kekko's emulation would work and only works with Voodoo1 in real hardware. The later is newer version of patch and it looks for the OVL in the path. This one works for both kekko's emulation and Glide pass-through, but it has missing shadow bug on kekko's emulation (and I presume the same bug will apply for real 3Dfx hardware). The missing shadow bug has a workaround in Glide pass-through to restore the shadow.

DOS32/A does not support DOS4G/GW DOS DLL required by GLIDE2X.OVL. Re-stubbing or running 3Dfx DOS binaries with DOS32/A is a no-no.

Reply 767 of 1550, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie

Delfino,

Regarding MSF handling for Destruction Derby, I've asked if this is something the core developers are interested in implementing in the near term: Re: DOSBox Feature Request Thread

Reply 768 of 1550, by willow

User metadata
Rank Member
Rank
Member
Yesterplay80 wrote:

Okay, I had to adjust some other patches after applying the "new" 3Dfx patch from kjliew, but I managed to get the windows version working again. I still have to get openglide into my Linux VM so I can try to compile the code there, too. In the meantime, it'd be nice if someone could give me some feedback if and how the new windows version (r4267) works, especially with the two 3Dfx emulation options!

in your site:
"Emulation of a 3Dfx Voodoo card via internal (software or OpenGL) or external wrapper"
Which are the options in .conf file to use 3dfx emulation with external wrapper ? Can we use dgvoodoo or nglide with this emulation?

Reply 770 of 1550, by Kisai

User metadata
Rank Member
Rank
Member
willow wrote:
in your site: "Emulation of a 3Dfx Voodoo card via internal (software or OpenGL) or external wrapper" Which are the options in […]
Show full quote
Yesterplay80 wrote:

Okay, I had to adjust some other patches after applying the "new" 3Dfx patch from kjliew, but I managed to get the windows version working again. I still have to get openglide into my Linux VM so I can try to compile the code there, too. In the meantime, it'd be nice if someone could give me some feedback if and how the new windows version (r4267) works, especially with the two 3Dfx emulation options!

in your site:
"Emulation of a 3Dfx Voodoo card via internal (software or OpenGL) or external wrapper"
Which are the options in .conf file to use 3dfx emulation with external wrapper ? Can we use dgvoodoo or nglide with this emulation?

nGlide is 32-bit only.

However there is a supported-in-QEMU dgvoodoo2 build in the regular dgvodoo2 build. So that would probably be the solution there. Incidentally they post here, Topic 60950

It might be interesting to see if a straight recompile to Win x64 can work with it.

Reply 771 of 1550, by willow

User metadata
Rank Member
Rank
Member
robertmo wrote:

glide, yes

How?
I have tried all options of dosbox ece.conf file and nglide is not launched.
At each time, it's just internal emulation.

If nglide doesn't worked, how use dgvoodoo 2 with dosbox exe? Where must I copy glide.dll, glide2x.dll and glide3x.dll of dgvoodoo 2? Must I use 64 bit dll or 32 bit dll?

Thanks.

Reply 772 of 1550, by willow

User metadata
Rank Member
Rank
Member
Delfino Furioso wrote:
thank you yesterplay! […]
Show full quote

thank you yesterplay!

I'll be glad to help with testing the new glide support options
I'd like however to try describing how these options work: I want my feedback to be useful, and so I need to use the software properly

Please let me know if there's something wrong with my recap

the "usual" kekko method

  • actually emulates voodoo1 hw in software (or opengl)
  • is configured using the [PCI] section of dosbox.conf

the "new" gulikoza method

  • it needs its own gliei2x.ovl library to be present alongside the dosbox.exe binary (ECE download currently does not include it)
  • it relies on an external glide wrapper (openglide, nglide, dgvoodoo) installed on the host system
  • is configured using the [GLIDE] section of dosbox.conf

Where can we download this glide2x.ovl ?
I cant' find it.

Reply 774 of 1550, by Yesterplay80

User metadata
Rank Oldbie
Rank
Oldbie

I added the OVL file to the DOSBox downloads now, too.

My full-featured DOSBox SVN builds for Windows & Linux: Vanilla DOSBox and DOSBox ECE (Google Drive Mirror)

Reply 776 of 1550, by Charles D. Ward

User metadata
Rank Newbie
Rank
Newbie

Hello, I'm building from source on MX Linux 18.3 (x64), and ./configure reports:

checking whether x86 dynamic cpu core will be enabled... no
checking fluidsynth.h usability... no
checking fluidsynth.h presence... no
checking for fluidsynth.h... no
checking for main in -lopengl32... no
checking whether ddraw display output will be enabled... no

How can I make these lines say 'yes'? I want the binary to support all possible configurations and to be compatible with 32 bit systems

And if I try to run the binary downloaded from the official ECE Site, the binary repots the following:

./dosbox: /lib/i386-linux-gnu/libm.so.6: version `GLIBC_2.27' not found (required by ./dosbox)

Where can I download libm.so.6?

Last edited by Charles D. Ward on 2019-10-20, 03:26. Edited 1 time in total.

Reply 777 of 1550, by Kisai

User metadata
Rank Member
Rank
Member
Charles D. Ward wrote:

In file included from midi.cpp:77:0:
midi_mt32.h:7:29: fatal error: mt32emu/mt32emu.h: No such file or directory
#include <mt32emu/mt32emu.h>

You need to compile MUNT first.
https://github.com/munt/munt

Charles D. Ward wrote:

./dosbox: /lib/i386-linux-gnu/libm.so.6: version `GLIBC_2.27' not found (required by ./dosbox)

Where can I download libm.so.6?

You don't. That's a version mismatch with the system GLIBC.

Reply 778 of 1550, by Charles D. Ward

User metadata
Rank Newbie
Rank
Newbie

You need to compile MUNT first.
https://github.com/munt/munt

Thanks, I edited my post before reading yours

Have a new problem compiling 😜:

In file included from flac.c:46:0:
dr_flac.h: In function ‘drflac_read_pcm_frames_s16__decode_left_side__sse2’:
dr_flac.h:8243:60: warning: implicit declaration of function ‘drflac__mm_packs_interleaved_epi32’ [-Wimplicit-function-declaration]
_mm_storeu_si128((__m128i*)(pOutputSamples + i*8), drflac__mm_packs_interleaved_epi32(left, right));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
dr_flac.h:8243:60: error: incompatible type for argument 2 of ‘_mm_storeu_si128’
In file included from dr_flac.h:1052:0,
from flac.c:46:
/usr/lib/gcc/x86_64-linux-gnu/6/include/emmintrin.h:714:1: note: expected ‘__m128i {aka __vector(2) long long int}’ but argument is of type ‘int’
_mm_storeu_si128 (__m128i *__P, __m128i __B)
^~~~~~~~~~~~~~~~
In file included from flac.c:46:0:
dr_flac.h: In function ‘drflac_read_pcm_frames_s16__decode_right_side__sse2’:
dr_flac.h:8378:60: error: incompatible type for argument 2 of ‘_mm_storeu_si128’
_mm_storeu_si128((__m128i*)(pOutputSamples + i*8), drflac__mm_packs_interleaved_epi32(left, right));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from dr_flac.h:1052:0,
from flac.c:46:
/usr/lib/gcc/x86_64-linux-gnu/6/include/emmintrin.h:714:1: note: expected ‘__m128i {aka __vector(2) long long int}’ but argument is of type ‘int’
_mm_storeu_si128 (__m128i *__P, __m128i __B)
^~~~~~~~~~~~~~~~
In file included from flac.c:46:0:
dr_flac.h: In function ‘drflac_read_pcm_frames_s16__decode_mid_side__sse2’:
dr_flac.h:8593:64: error: incompatible type for argument 2 of ‘_mm_storeu_si128’
_mm_storeu_si128((__m128i*)(pOutputSamples + i*8), drflac__mm_packs_interleaved_epi32(left, right));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from dr_flac.h:1052:0,
from flac.c:46:
/usr/lib/gcc/x86_64-linux-gnu/6/include/emmintrin.h:714:1: note: expected ‘__m128i {aka __vector(2) long long int}’ but argument is of type ‘int’
_mm_storeu_si128 (__m128i *__P, __m128i __B)
^~~~~~~~~~~~~~~~
In file included from flac.c:46:0:
dr_flac.h:8629:64: error: incompatible type for argument 2 of ‘_mm_storeu_si128’
_mm_storeu_si128((__m128i*)(pOutputSamples + i*8), drflac__mm_packs_interleaved_epi32(left, right));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from dr_flac.h:1052:0,
from flac.c:46:
/usr/lib/gcc/x86_64-linux-gnu/6/include/emmintrin.h:714:1: note: expected ‘__m128i {aka __vector(2) long long int}’ but argument is of type ‘int’
_mm_storeu_si128 (__m128i *__P, __m128i __B)
^~~~~~~~~~~~~~~~
In file included from flac.c:46:0:
dr_flac.h: In function ‘drflac_read_pcm_frames_s16__decode_independent_stereo__sse2’:
dr_flac.h:8738:60: error: incompatible type for argument 2 of ‘_mm_storeu_si128’
_mm_storeu_si128((__m128i*)(pOutputSamples + i*8), drflac__mm_packs_interleaved_epi32(left, right));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from dr_flac.h:1052:0,
from flac.c:46:
/usr/lib/gcc/x86_64-linux-gnu/6/include/emmintrin.h:714:1: note: expected ‘__m128i {aka __vector(2) long long int}’ but argument is of type ‘int’
_mm_storeu_si128 (__m128i *__P, __m128i __B)
^~~~~~~~~~~~~~~~
Makefile:455: recipe for target 'libdecoders_a-flac.o' failed
make[4]: *** [libdecoders_a-flac.o] Error 1
make[4]: Leaving directory '/mnt/data/Linux Software/DOSBox ECE r4259 (Linux source)/src/libs/decoders'
Makefile:332: recipe for target 'all-recursive' failed
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory '/mnt/data/Linux Software/DOSBox ECE r4259 (Linux source)/src/libs'
Makefile:444: recipe for target 'all-recursive' failed
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory '/mnt/data/Linux Software/DOSBox ECE r4259 (Linux source)/src'
Makefile:396: recipe for target 'all-recursive' failed
Show last 4 lines
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/mnt/data/Linux Software/DOSBox ECE r4259 (Linux source)'
Makefile:337: recipe for target 'all' failed
make: *** [all] Error 2

Reply 779 of 1550, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie

Charles, this was a known issue reported by Yesterplay80 that was fixed ( AUDIO Patch supporting FLAC, Opus, and MP3 audio tracks), but now that you've flagged it we see the update is not in the current ECE sources; maybe Yesterplay80 can generate an updated source pack for you 😀