There was just one type of error among many lines in the glide3x source code. I tried to typecast the pointer as intended, but attached is a patch for verification. Also, attached the resulting libraries, although I can build the sdk tests, too.

The sdk tests are using the older symbolic naming scheme from 204: _fenceVar. At least I think so, so I'll try to make test00.exe with that change (and the others tests have the same issue).

Okay. Once you get a binary produced I can test it out on some real hardware (I believe dosbox supports glide now, I know pcem does)

Thanks. I built the above with the default makefile set (from h5 directory which corresponds to V3/Banshee cards), so I should customize the build process according to V2 (cvg directory; given those files are available in the version of glide3x). I'll work on this for a while to make sure it's built properly and the automake binaries are versions that setup the files as intended.

Also, there is a P6 requirement for this file set (even though it's djgpp friendly).

Edit: a snippet from INSTALL documentation:
--enable-fx-glide-hw=<asic> Build for the given asic.
asic HW
h5 Voodoo4/VoodooV
h3 Voodoo3/Banshee
cvg Voodoo2. (It's not clear that this
works at all.)

I have a Voodoo 2, 3 and 5. So I should be able to test anything you can send to me.

That's great. It may take some time, but I'll work on this. Duplicate effort will be ok because it requires some automake magic. 😀

ggorts_ wrote:

--enable-fx-glide-hw=<asic> Build for the given asic. asic HW h5 Voodoo4/VoodooV […]
Show full quote

--enable-fx-glide-hw=<asic> Build for the given asic.
asic HW
h5 Voodoo4/VoodooV
h3 Voodoo3/Banshee
cvg Voodoo2. (It's not clear that this
works at all.)

You can try the h3 or h5 path for now. I'm not too worried about voodoo 2 just yet, but that would open the possibility for any old shitty P1 MMX to be able to play it at a decent frame rate at 640x480

Also, when I was peeking at the SDK earlier it looks like most of it is locking a buffer (or unlocking?) at the beginframe, do your stuff, then flip flop locking/unlocking. I spoke with someone who programmed for Daikatana a few days ago about it and he said the biggest pain in the ass with glide was that it required all triangles in the scene to clipped? Something I really have no idea about, but I guess that means if the proper functions to convert are mostly there one would hope it would be fixing some rendering errors related to that and possibily sanity checks for texture sizes and the like. But I'm sure there's other gotchas that only seasoned 3dfx programmers know about.

Ok, cool. It may build by default without automake in that case, and there is a small possibility that the above binaries work, but the sdk tests look for fenceVar. I believe that (fenceVar) is part of the P6 requirement which is based on P6 friendly inline assembly. I'll try to look at this further.

I've heard about the buffer locking requirement, but didn't know about the clipping. However, there may be code samples to help. Is there Quake2 source code on 3dfx output? Does it translate opengl to 3dfx instructions?

That special 3dfxgl mini driver never had source. I think 3dfx specifically wrote it to wrap around the ref_gl, but who knows for sure. But also, when they were working on daikatana glide3x was new so maybe the clipping stuff was removed in glide3x (they mention something: In Glide 3.0, vertices no longer need to be snapped to sub-pixel precision. The newer platforms perform snapping in hardware; ) but it may be entirely unrelated to the potential problem.

I would think that glide3x is more opengl compatible. That's a real shame they didn't open source the mini driver, and I wish ID left us the Rendition code, too. 😀

I saw a somewhat recent post mentioning that glide3x hadn't been used yet in a DOS game and that the API was fairly distinct from glide2x, too. I would think that it is much more advanced, as you said, especially given how new glide2 was at the time.

Do you think it is even remotely possible to use HDPMI and then access the 3dfxgl mini driver directly? One problem is that HDPMI, I believe, is openwatcom friendly, but the system isn't documented for djgpp.

Yeah, afaik 3dfx never distributed DOS blobs for glide3x. They did for glide2x, but it was closed source and required WATCOM so it wouldn't have been useful for Q2DOS. At some point before they closed, the released the source to glide3x apparently) and this project is the result of fixing it up to be cross platform. The GL3PGM.DOC (reading it over now) mentions how to set somethings up for DOS, so I guess they had glide3x in mind for DOS. Whether it was ever distributed or fully tested only 3dfx would know.

I'm not interested in HDPMI as it's not very well tested and the guy dropped off the face of the earth.

I agree. I wonder if 3dfx used Mesa to create their binary blob.

But I'll work on the automake toward the glide3 binary. I've built from these sources before, just not in djgpp.

You're just having problems with the fenceVar? Also, there is a test program at the end of that document which sets up the card and draw a shape and exits. It has ifdef __DOS__ for pressing a key so you at least get a chance to see it.

Thanks, I'll look at the document. Also, it was just a linker error for test00.exe (and others) for that symbol (fenceVar). I verified in the source code for glide3x library that fenceVar is related to a required P6 function (including inline assembly). There is some possibility that the code is using MMX instructions, but I haven't verified for sure.

I also have to verify the automake system for building and whether it is possible to call makefile.DJ without preparation. If the above glide3x binary is ok, and it did eventually build without error, then perhaps the test binaries require another step.

This doesn't look right either in the source:
linhwc.c

1static FxU32 fenceVar;
2#define P6FENCE asm("xchg %%eax, %0" : : "m" (fenceVar) : "eax");

but minihwc.c has this:

1#elif defined(__DJGPP__) || defined (__MINGW32__)
2#define P6FENCE __asm __volatile ("xchg %%eax, fenceVar":::"%eax")
3#else
4#error "P6 Fencing in-line assembler code needs to be added for this compiler"

Here is a hint on the fenceVar once the warnings were enabled in gcc:

1h5/minihwc/minihwc.c:994:14: warning: 'fenceVar' defined but not used [-Wunused-variable]
2 static FxU32 fenceVar;

Edit: I'll try to define this outside the condition block (specific to djgpp):
#define P6FENCE __asm __volatile ("xchg %%eax, fenceVar":::"%eax")

The file linhwc.c is for linux but the minihwc.c is active for djgpp. That explains the difference. Also, I think now that the makefile.dj doesn't require a configure or other prior steps to build.