Stiletto wrote on 2021-10-17, 22:57:
Ostensibly speaking as a project manager for the old OpenGlide Glide wrapper, and having communicated with Glidos (OpenGlide), Dege (dgVoodoo2 and ye olde dgVoodoo), and Zeus (nGlide) frequently in the past, I am sure we'd all be interested in what can be done to bring things in line with actual hardware. (Also, sounds like you didn't try Dege's dgVoodoo2.)
Since for the last version I made that made it work, I did two things at once, I'm not sure which one made it work (it might be that both, or just one of them, or neither of them, caused the issue to go away, I didn't bisect it further):
- Vertex snapping (as described in the "Floating Point Vertex Snapping and Area Calculations" section in the Glide 2.2 Programming Guide)
- Poll grBufferNumPending() -- in case it overfills the FIFO
If it was just the vertex snapping, it can probably be reproduced by using a 16-bit fixed-point (12.4) bits representation for the emulated hardware part (FBI), from the Glide docs:
A potential inconsistency may arise between Glide ́s and the Voodoo Graphics hardware ́s perception of area and vertex values when Glide ́s floating point values change upon conversion to the hardware ́s fixed point <12.4> representation
If it was the overfilling of the FIFO, limiting the FIFO is probably one option, but then everything has to be cycle-accurate including the PCI bus, and the issue might of course only happen depending on how fast the CPU feeds the FIFO, so might not have been visible on era-accurate pairings of CPUs and Voodoos.
The vertex snapping is something that I'd consider "good" to have for accuracy, since it can affect the visual output (if you want to reproduce what the SST-1 does pixel perfect). The FIFO overfilling is something that might be related to other components, and apart from "developer mode" (where you want to be bug-for-bug compatible to original hardware), it's good that the Glide wrappers don't lock up if the FIFO becomes full.
As for trying different wrappers, during development I am using Linux and DOSBox-X was readily available, PCem easy to build from source and nGlide worked fine in Wine, so didn't go for testing with all wrappers (especially since there's an OpenGL 1.1 build for anything non-Voodoo). One more fun thing to try would be to see how to reduce the OpenGL API usage to make it compatible with the MiniGL driver (I'm using vertex arrays from OpenGL 1.1, but that could be "backported" to glBegin()/glEnd() which seems to be what GLQuake has been using), or if the full OpenGL ICD that was released for Voodoo Graphics eventually actually did support the OpenGL 1.1 build properly.