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.
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)
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.
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
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
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.
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.
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
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?
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.
How?
I have tried all options of dosboxece.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?
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.
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.
1In file included from flac.c:46:0: 2dr_flac.h: In function ‘drflac_read_pcm_frames_s16__decode_left_side__sse2’: 3dr_flac.h:8243:60: warning: implicit declaration of function ‘drflac__mm_packs_interleaved_epi32’ [-Wimplicit-function-declaration] 4 _mm_storeu_si128((__m128i*)(pOutputSamples + i*8), drflac__mm_packs_interleaved_epi32(left, right)); 5 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 6dr_flac.h:8243:60: error: incompatible type for argument 2 of ‘_mm_storeu_si128’ 7In file included from dr_flac.h:1052:0, 8 from flac.c:46: 9/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’ 10 _mm_storeu_si128 (__m128i *__P, __m128i __B) 11 ^~~~~~~~~~~~~~~~ 12In file included from flac.c:46:0: 13dr_flac.h: In function ‘drflac_read_pcm_frames_s16__decode_right_side__sse2’: 14dr_flac.h:8378:60: error: incompatible type for argument 2 of ‘_mm_storeu_si128’ 15 _mm_storeu_si128((__m128i*)(pOutputSamples + i*8), drflac__mm_packs_interleaved_epi32(left, right)); 16 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 17In file included from dr_flac.h:1052:0, 18 from flac.c:46: 19/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’ 20 _mm_storeu_si128 (__m128i *__P, __m128i __B) 21 ^~~~~~~~~~~~~~~~ 22In file included from flac.c:46:0: 23dr_flac.h: In function ‘drflac_read_pcm_frames_s16__decode_mid_side__sse2’: 24dr_flac.h:8593:64: error: incompatible type for argument 2 of ‘_mm_storeu_si128’ 25 _mm_storeu_si128((__m128i*)(pOutputSamples + i*8), drflac__mm_packs_interleaved_epi32(left, right)); 26 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 27In file included from dr_flac.h:1052:0, 28 from flac.c:46: 29/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’ 30 _mm_storeu_si128 (__m128i *__P, __m128i __B) 31 ^~~~~~~~~~~~~~~~ 32In file included from flac.c:46:0: 33dr_flac.h:8629:64: error: incompatible type for argument 2 of ‘_mm_storeu_si128’ 34 _mm_storeu_si128((__m128i*)(pOutputSamples + i*8), drflac__mm_packs_interleaved_epi32(left, right)); 35 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 36In file included from dr_flac.h:1052:0, 37 from flac.c:46: 38/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’ 39 _mm_storeu_si128 (__m128i *__P, __m128i __B) 40 ^~~~~~~~~~~~~~~~ 41In file included from flac.c:46:0: 42dr_flac.h: In function ‘drflac_read_pcm_frames_s16__decode_independent_stereo__sse2’: 43dr_flac.h:8738:60: error: incompatible type for argument 2 of ‘_mm_storeu_si128’ 44 _mm_storeu_si128((__m128i*)(pOutputSamples + i*8), drflac__mm_packs_interleaved_epi32(left, right)); 45 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 46In file included from dr_flac.h:1052:0, 47 from flac.c:46: 48/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’ 49 _mm_storeu_si128 (__m128i *__P, __m128i __B) 50 ^~~~~~~~~~~~~~~~ 51Makefile:455: recipe for target 'libdecoders_a-flac.o' failed 52make[4]: *** [libdecoders_a-flac.o] Error 1 53make[4]: Leaving directory '/mnt/data/Linux Software/DOSBoxECE r4259 (Linux source)/src/libs/decoders' 54Makefile:332: recipe for target 'all-recursive' failed 55make[3]: *** [all-recursive] Error 1 56make[3]: Leaving directory '/mnt/data/Linux Software/DOSBoxECE r4259 (Linux source)/src/libs' 57Makefile:444: recipe for target 'all-recursive' failed 58make[2]: *** [all-recursive] Error 1 59make[2]: Leaving directory '/mnt/data/Linux Software/DOSBoxECE r4259 (Linux source)/src' 60Makefile:396: recipe for target 'all-recursive' failed
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 😀