Schleichfahrt starts up, initializes glide (the glide window pops up for a split second and OHQ disables itself), then glide is obviously deinitialized and Schleichfahrt hangs at a blank screen with text cursor blinking when usually the BlyeByte logo would appear.

Here's the debug output:

Glide:MemBase: 0x0xe7522008
Glide:Memory allocated at 0xd9bd0 (segment: 55741)
Glide:Port read. Returning 55741
Glide:Port read. Returning 217
Processing call 142, return address: 0x0
Processing call 165, return address: 0x16d91c
Glide:Port read (165). Return address: 0x16d91c, value: 1
Processing call 169, return address: 0x0
Processing call 174, return address: 0x16d900
Processing call 175, return address: 0x16d900
Glide:Resolution set to:640x480, LFB at 0x17b000
Glide:GLIDE_PageHandler installed for 0x17b000 (379 + 150 pages)
Glide:Port read (175). Return address: 0x16d900, value: 1
Processing call 145, return address: 0x0
Glide:Resetting page handler for page 379 (150 pages)
Function 142: 1 calls
Function 145: 1 calls
Function 165: 1 calls
Function 169: 1 calls
Function 174: 1 calls
Function 175: 1 calls
0 framebuffer locks (0 read, 0 write)

"Processing call 145, return address: 0x0" looks quite suspicious.

Moe, could you please test if the Schleichfahrt installation works for you?
See Topic 13846

No, return address = 0x0 simply means that the function is returning void. Call 145 is grGlideShutdown (see include/glide.h), by then it is already too late. I still stand by my original assumption. grSstQueryHardware (165) will also return a string naming the voodoo board. Openglide returns "Openglide v0.9rc" or something like that, the game might decide that is not a supported voodoo board 😀

Hmm...I just noticed something. The functions in glide2x.ovl should all be uppercase. They are not.

Try this ovl file. It should be the same, just uppercased all the exported functions.

edit: I added some functions the game uses, but were previously not exported

No change at all, sorry.

Yeah, so I noticed. I managed to get the game installed. Will play with it a little bit, see what happens 😀

Thanks. It is one of my all-time favourite games. Boy I was so disappointed when the successor Aquanox came out and they stripped the realistic physics model.

Well...it doesn't look promising. I have no idea why the game behaves like that. It opens the window, then it closes it down. For no apparent reason. It only calls 4 functions, only two of which even return something. One is OpenWindow which can return 1 or 0...and it obviously returns 1. The other is QueryHardware which returns something like Voodoo version, texture memory size, etc...I've tried to change these parameters in openglide, to get as close to V1 as possible, but no luck.
The funny thing is that then the game continues (this can be seen with the debug build), so maybe it is all perfectly normal so far...It opens desktop3.exe and a bunch of gfx files, and stops at loading hiob.des. I've left it some 10 min or so but it did not continue (the processor usage varied quite a lot so it was doing something...). The software version loads cursor at this point and then some other files after it finally shows the intro screen.
It might be hitting some dosbox issue, that the software version doesn't, I don't know. It doesn't seem glide related...as glide is not even active at that point.

Maybe try putting it onto an msdos disk image, should avoid bugs due to
odd environment configurations or other limitations.
If vesa isn't needed you might also want to try loading some vga bios,
but i doubt that'd help in this case.

Well, the game works fine in software mode (even the 3dfx-executable has software fallback which is used when glide is disabled), so I doubt environment has something to do with it.

Which doesn't mean that it is not the cause for the 3dfx executable not working 😉
It's just a general measure to exclude a large amount of possible bugs.

I haven't checked the debugger, but using a simple MS-DOS 6.22 boot image, I get the same result.

Any ideas where to look now?

There are some more nice things to try with a disk image, like using
himem.sys, emm386.exe, no memory manager at all etc.
Other than that backtracing why the window is closed, can be tedious 🙁

I really doubt all that can affect it, it's a DOS4GW executable so it should be quite independent of these issues, shouldn't it?

BTW, it was a plain MS-DOS 6.22 boot floppy image.

It should, but especially with emm386 loaded much stuff is different,
like interrupts/callbacks are handled in v86 mode, emm386 intercepts
ports and so on.
It's just meant to quickly (um sort of) exclude the dos subsystem and
a few other things to be the cause of the failure (as gulikoza said
"It might be hitting some dosbox issue").
Of course it might still be some dosbox bug in the cores, some stuff
that doesn't like the kick-in page fault handling (though the dynamic
core is quite goot at this now) etc.

Ok, you've convinced me. Above result was using HIMEM only. Here is no mem manager at all:

ALSA:Client initialised [128:0]
MIDI:Opened device:alsa
Glide:MemBase: 0x0xe753f008
Using partition 0 on drive; skipping 63 sectors
Mounted FAT volume is FAT16 with 64222 clusters
Mounted FAT volume is FAT12 with 2847 clusters
BIOS INT14: port 3 does not exist.
BIOS INT14: port 2 does not exist.
Glide:Memory allocated at 0xd9bc0 (segment: 55740)
Glide:Port read. Returning 55740
Glide:Port read. Returning 217
Processing call 142, return address: 0x0
Processing call 165, return address: 0x15991c
Glide:Port read (165). Return address: 0x15991c, value: 1
Processing call 169, return address: 0x0
Processing call 174, return address: 0x159900
Processing call 175, return address: 0x159900
Glide:Resolution set to:640x480, LFB at 0x167000
Glide:GLIDE_PageHandler installed for 0x167000 (359 + 150 pages)
Glide:Port read (175). Return address: 0x159900, value: 1
Processing call 145, return address: 0x0
Glide:Resetting page handler for page 359 (150 pages)
Function 142: 1 calls
Function 145: 1 calls
Function 165: 1 calls
Function 169: 1 calls
Function 174: 1 calls
Function 175: 1 calls
0 framebuffer locks (0 read, 0 write)
Exit to error: INT:Gate Selector points to illegal descriptor with type 0

Using HIMEM.SYS alone or in conjunction with EMM386 (umbs only, no EMS) behaves like before. In all cases, DOSBoxes memroy extenders were all turned off.

Well no real difference to the log before.
You could try moving around that allocated memory segment
Glide:Memory allocated at 0xd9bc0 (segment: 55740)
for example raise the dos memory start and put it below, or use
0xc801 fixed (how much memory does it need?).
That's just guessing though.

Needs about 80 bytes for passing the functions and parameters. This could probably be done differently I guess...