VOGONS


Reply 40 of 398, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
DosFreak wrote:

Mingw is still being updated.

I doubt. I am using mingw-get to manage MinGW.org packages and I think I had never seen anything getting update. Packages such as mingwrt and w32api are fixed at 5.0.2 for years with GCC 6.3.0 and binutils-2.28. However, I am not complaining as things were worse before that I had to compile my own GCC and binutils. There seems to be some focus on the WSL development but that was not what I would switch to. And MSYS2/MinGW-w64 is maturing and I am almost totally migrated over there. I only keep MinGW.org for older codes which was initially developed there. For any new development, I think MSYS2/MinGW-w64 is the way to go, especially for the native WIN64 build.

Reply 41 of 398, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

Like alot of projects that don't post nightly SVN builds you'll have to compile yourself.

I worked with ghandig on figuring out an SSE issue a year back which prevented programs compiled with mingw from working on operating systems without SSE support which was put into mingwrt 5.0.2 which was released that Dec 2017.

Also https://sourceforge.net/p/mingw/mingw-org-wsl … 5.1-trunk/tree/

Yeah mingw activity is nowhere as high as mingw-w64 and you're probably better off with mingw-w64 but mingw is still being updated so if you don't open a ticket for an issue that's really on you.

DOSBox Compilation Guides
DosBox Feature Request Thread
PC Game Compatibility List
How To Ask Questions The Smart Way
Running DRM games offline

Reply 42 of 398, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

Patch updated in 1st post. No change to guest wrappers.

Improved LFB shared memory implementation to work for the peculiar Glide 2.1.1 LFB semantics when using Glide2x to emulate Glide 2.1.1 APIs.

Reply 43 of 398, by robertmo

User metadata
Rank l33t++
Rank
l33t++

adding
--disable-stack-protector
to configure
makes msys2 ming64 compile a working .exe
if you want to read about it:
https://www.mail-archive.com/qemu-devel@nongn … /msg557409.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86832
-------------------------
the new 3dfx patch made msys2 ming32 produce a working .exe too
-------------------------
other thing is both exes quit qemu when initialising glide:

testXX.exe

glidept: DLL loaded - glide2x.dll
trace: _grGlideGetVersion@4 called
glidept: grGlideGetVersion Glide 2.43

pressing any key:

trace: _grGlideInit@0 called
glidept: grSstWinOpen called, buf 2 aux 1 gLfb 0xfb000000

Reply 44 of 398, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
robertmo wrote:

other thing is both exes quit qemu when initialising glide:

Perhaps you are not using dgVoodoo2. If you are not compiling your own open-sourced glide wrappers such as OpenGlide or psVoodoo, then the only prebuilt glide wrapper that works is dgVoodoo2. Or, QEMU 3Dfx requires additional configuration option in glide.cfg to spawn glide rendering window instead of rendering into the same QEMU window. Your console trace looked like QEMU crashed when glide wrapper was taking over.

 $ echo "CreateWindow,1" > glide.cfg 

QEMU 3Dfx Glide Pass-Through (WHPX/KVM works!!!)

When everything works, this is what you should be getting in console output. The example is running TEST04 from 3Dfx SDK.

glidept: DLL loaded - glide2x.dll
trace: _grGlideGetVersion@4 called
glidept: grGlideGetVersion Glide 2.45 - OpenGLide 0.09rc9
trace: _grGlideInit@0 called
glidept: grSstWinOpen called, buf 2 aux 1 gLfb 0xfb000000
glidept: LFB mode is Shared Memory (fast)
window 640x480
glidept: grSstWinClose called
glidept: grGlideShutdown called, fifo 0x00be data 0x0dae shm 0x00436b8 lfb 0xfb000000
glidept: DLL unloaded

Well, dgVoodoo2 requires beefy GPU shaders and tend to be slow on older generation of GPUs when the GPU shaders are overloaded.

Reply 45 of 398, by robertmo

User metadata
Rank l33t++
Rank
l33t++

quiting after this now when i click on the new window that is black:

glidept: DLL loaded - glide2x.dll
trace: _grGlideGetVersion@4 called
glidept: grGlideGetVersion Glide 2.43
trace: _grGlideInit@0 called
glidept: grSstWinOpen called, buf 2 aux 1 gLfb 0xfb000000
window 640x480
glidept: LFB mode is Shared Memory (fast)

Reply 46 of 398, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
robertmo wrote:

quiting after this now when i click on the new window that is black:

Just don't click on the Glide window. It will crash. You can only click on QEMU window. Unfortunately, using separate Glide rendering window is a debug mode which I don't have plan to make it better. For simplicity sake, just use dgVoodoo2 for same-window rendering.

Reply 48 of 398, by robertmo

User metadata
Rank l33t++
Rank
l33t++

glidept: DLL loaded - glide2x.dll
trace: _grGlideGetVersion@4 called
glidept: grGlideGetVersion Glide 2.43
trace: _grGlideInit@0 called
glidept: grSstWinOpen called, buf 2 aux 1 gLfb 0x11400000
window 640x480
glidept: LFB mode is Shared Memory (fast)
301 frames in 5.0 seconds, 60.0 FPS

Reply 49 of 398, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
robertmo wrote:

ok works in that window when i disabled -accel hax

Intel HAXM acceleration for QEMU is not as robust as WHPX on Windows 10 or KVM on Linux. Unfortunately, it is the ONLY way to run QEMU accelerated for i686 build. It usually works for running Linux as its focus mostly for running Android emulator on Windows.

In future, I believe Intel HAXM will be fading away, as the 3 main OS camps now shipped with their own user-space APIs for hardware accelerated VM.
KVM on Linux as the pioneer, WHPX on Windows 10 and HVF on MacOS.

Reply 53 of 398, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

Fine... Here's the list of options available from glide.cfg:
CreateWindow,1
Forced Glide rendering into separate spawned window.
ScaleWidth,[width]
Scale Glide resolution to width. Work seamlessly with dgVoodoo2 and psVoodoo. For patched OpenGlide that supports scaling, this option requires a matching scaling factor in the OpenGlide INI configuration file.
LfbHandler,1
Forced LFB mode to use MMIO handlers, slow but more accurate. Extremely slow on accelerated VM.
LfbNoAux,1
Fake LFB locks for AUX/DEPTH buffer without passing through to Glide wrappers, especially for Glide wrappers that do not support this.
LfbLockDirty,1
A more accurate LFB semantics for shared memory at the expense of some performance hit. Every lock will refills shared memory within the same frame. Fix rendering errors for Pyl (fire & flare seen through closed doors) and BioFreak (fight actions in black screen).
LfbWriteMerge,1
LFB writes to BACK buffer are merged and deferred til buffer swap. Improved performance and compatibility of OpenGlide for games that do multiple lock/unlock within a frame (eg. Pyl, Archimedean Dynasty).

Just create a text file glide.cfg in the startup folder of QEMU. For eg.

CreateWindow,1
ScaleWidth,1024
LfbHandler,1
LfbNoAux,1
LfbLockDirty,1
LfbWriteMerge,1
Last edited by kjliew on 2020-05-05, 03:43. Edited 5 times in total.

Reply 54 of 398, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
robertmo wrote:
adding --disable-stack-protector to configure makes msys2 ming64 compile a working .exe […]
Show full quote

adding
--disable-stack-protector
to configure
makes msys2 ming64 compile a working .exe

By the way, I don't think this is necessary if you keep the MSYS2/MinGW-w64 current. I had built QEMU without it and it worked. The GCC from MSYS2/MinGW-w64 is pretty current and updated especially for the x86_64 compiler. However, the configure option is good to get rid of libssp-0.dll dependency, so that Windows version binary distribution does not need to include the additional DLL.

Reply 55 of 398, by robertmo

User metadata
Rank l33t++
Rank
l33t++

may be easily reproducible:
install msys2-x86_64-20180531.exe from http://www.msys2.org to a new separate folder
pacman -Syu
restart the MSYS2 console
pacman -Su
pacman -S --needed base-devel mingw-w64-x86_64-toolchain git python
pacman -S --needed mingw-w64-x86_64-glib2 mingw-w64-x86_64-gtk3 mingw-w64-x86_64-SDL2
pacman -S --needed mingw-w64-x86_64-capstone
start mingw64 console
./configure --target-list=x86_64-softmmu
make

this might also bring further light to why dgvoodoo2 doesn't generate picture for me in qemu's window and i have to use glide.cfg CreateWindow,1 setting

btw Pyl works even "better" with glide as in software mode it is either sound or picture 😉 depending on your pyl sound setting (any sb or none) 😉 Though it works with Haxm in soft mode 😉

Reply 56 of 398, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
robertmo wrote:

./configure --target-list=x86_64-softmmu

The QEMU target should be i386-softmmu. You only need WIN64 build for better performance, not the x86_64 emulator. In fact, x86_64 emulator will be slower and no 3Dfx Glide would ever require x86_64 instruction emulation.
However, this has nothing to do with dgVoodoo2 not rendering into the same QEMU window. I just tried my x86_64 QEMU build and dgVoodoo2 worked just fine on the same QEMU window. Forcing Glide to render into separate window is of no fun at all.

What version of QEMU are you using? Can you share your QEMU configure summary listing?

Well, the dgvoodoo.conf has option to work better with QEmu.

Environment                          = QEmu

But it is not a must for dgVoodoo2 to take over the QEMU window. As I had already mentioned earlier, dgVoodoo2 window hooking is very robust and magical.

robertmo wrote:

btw Pyl works even "better" with glide as in software mode it is either sound or picture 😉 depending on your pyl sound setting (any sb or none) 😉 Though it works with Haxm in soft mode 😉

I don't quite get the meaning. Were you able to get it working with 3Dfx Glide or just software rendering? Yeah, accelerated QEMU can be very fast for software rendering, too, if the software rendering is capable of similar visual effects as hardware rendering, but high resolution will not be sustainable. 640x480x16bpp should be fine with today's >3GHz CPUs.

Last edited by kjliew on 2019-01-11, 23:09. Edited 1 time in total.

Reply 57 of 398, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

I see that you are interested in getting Pyl (Dust) working and it's a DOS game. Well for DOS Glide, most likely QEMU TCG would be better for a couple of reasons:-
1. DOS Glide games are mostly early Glide games and their target CPU performance (anything less than P166MMX) is achievable with QEMU TCG with a reasonably fast modern CPUs. Examples Tomb Raider 1, Blood 1.
2. Early DOS Glide games which target Voodoo1 hardware are notorious of insane/abusive LFB access. They would just lock the LFB once and treat it as dumb frame buffer. This sounds silly but 3Dfx actually allowed this for Voodoo1 hardware, Carmageddon 1 an example of such silly LFB access. This would later haunt 3Dfx in revising the APIs to enforce better LFB sanity. For those, yeah, you will need the "LfbHandler,1" option and forget about accelerated VM.
3. DOS Glide games with poor frame rate regulation. For those, while accelerated VM works for them, it makes them too fast and the games exhibit "Matrix" slow-motion effect in animation, even though the QEMU console perfstat logged at constant 60FPS. Redguard and Blood 1 are examples of this. Tomb Raider 1 is a remarkable exception as it fixed its frame rate at constant 30FPS regardless of how fast the frame time. As a result, Tomb Raider 1 works out pretty well on either QEMU TCG or QEMU with acceleration. The later may be useful for low-end mobile CPUs, otherwise, it is a moot point for going into acceleration for nothing when QEMU TCG already provides constant 30FPS.

Reply 58 of 398, by robertmo

User metadata
Rank l33t++
Rank
l33t++

a new problem but nothing to do with 3dfx patch as it happens with a plain qemu 3.1.0 build too

\qemu>qemu-system-x86_64.exe -accel whpx
Windows Hypervisor Platform accelerator is operational

geting this soon after starting (without boot image while qemu looks for boot disk)
or with a simple "dir" when booted to dos with no autoexec.bat
or lots of other cases at the exact same moment generally at the very beginning of different types of boot of windows

qemu-system-x86_64.exe: WHPX: Failed to emulate MMIO access with EmulatorReturnStatus: 2
qemu-system-x86_64.exe: WHPX: Failed to exec a virtual processor

looks the guy here encountered exactly the same error later in his deduction and somehow hacked it:
https://github.com/xqemu/xqemu/issues/112