If you have the sources it might be more worthwhile. Not sure if older DXEs are compatible with DJ 2.05. I think the last version to be maintained with FXMesa was 6.4, but I haven't tried to compile it yet.
I did just manage to get 6.4 to compile properly. Going to test it out now
Does sezero intend on updating Thyrion with these changes?
Probably not, he's not too thrilled about the whole using mesa into glide thing. He would have preferred we wrote an entire glide driver specifically for quake. But that's beyond my knowledge and I don't have that much time on my hands to learn a dead API and work with it's shortcomings. I talked to someone who worked on Daikatana awhile ago about that approach and he said when they attempted it the Voodoo cards are really picky about clipping the triangles properly and all kinds of state switching and other stuff that they gave up on it and 3dfx ended up writing a mini gl driver instead (or they used Quake 2s not sure which).
I may add it to QDOS and QWDOS at some point.
I appreciate all the trouble to analyze the opengl functions and enhance the existing libraries (probably they are new versions in themselves!). And I noted sezero's excellent work, particularly on the glide library. It's invaluable to have one that introduces further stability to the system. I'm now trying to build a "period correct" computer to run q2dos with a V3 or higher card, I may be away learning about that (it will probably take me a month to setup).
I noticed doing a lot of benchmarks it really works the best with a Pentium 3 system if you can build one. It will run fine at 640x480 that way, but if you want high-res it's best to get the voodoo 5 as the framerates appear to be almost the same across the board.
Thanks, that's a helpful guide before ebay-ing the necessary components. Ironically, the P3 era is not all that far from my main desktop system, notwithstanding no space for full size cards.
wrote:Thanks, that's a helpful guide before ebay-ing the necessary components. Ironically, the P3 era is not all that far from my main desktop system, notwithstanding no space for full size cards.
Well if you erally want to get crazy and build a P4 system with a Voodoo 5 PCI then go for it, but everyone wants a lot of money for those cards...
I'll plan for "period correctness" in that case. 😀
I also just got QDOS compiling as glquake as well.. I have to fix a few things with it mainly the BSP2 support from earlier breaks loading maps but it does start up at the console. Was fairly trivial to port the gl_vidlinux over for it
That's exciting news to hear! I'm glad it wasn't too much trouble. It now will be difficult to refer to Dos fps games as having blocky graphics. 😀
Well it's got some odd hard lock issue after you load the map. Not sure how far it gets... If I use the ancient dos timer stuff from the original sys_dos.c it can play the demo briefly for about 5-10 seconds then locks up again. Dunno. 😒
I hope it is not difficult to find the cause. Please let me know if I can ever help. Either way it's promising that you have the code worked up and all.
I have a dosbox debugger build that is 3dfx capable. It's far from perfect for this purpose (built it mainly from dosbox-x source), but it outputs all sorts of informative logging. Q2 makes it easier along with its gl_log parameter, however!
Yeah, I can send the code to you then if you want to take a crack at it.
If that's convenient for you. I'll activate the pm here. Otherwise, I realized that dosbox-x (and ykhwong's) has debugger builds, or at least I recall, and they are 3dfx active.
Nice work on the palette and particle functions! The colors are now more vibrant.
I found a dosbox-x debugger which corresponds one-to-one with source code, in addition to the alternative "ykhwong dosbox" debugger which is available inside his latest archive here.
Also, on the qdos effort, I think it's possible that there is a page fault, but that the hard lock of the video screen is overlaying the message. It may be possible to disable the 3dfx video so that the text message is seen. However, a simpler way may be the dosbox debugger and the gdb tool with a debug enabled qdos.
When the program locks or otherwise, the alt-pause combo (dosbox debugger) will stop qdos from running. The debugger window should then show the current eip address while some other keypress steps backwards through prior eip address values. Those eip values can then be used against the gdb tool to find the functions in qdos before and at the time of the hard lock. This is the gdb command for this: x/i eip-value. Part of this is a summary of the last paragraph here: http://www.delorie.com/djgpp/v2faq/faq12_2.html.
Perhaps this faq has a better method for the last part: assuming that the EIP value is NNNNNNNN, type this at the GDB prompt: list *0xNNNNNNNN
You may have already considered this or solved the issue, but hopefully this is useful.
wrote:Nice work on the palette and particle functions! The colors are now more vibrant. […]
Nice work on the palette and particle functions! The colors are now more vibrant.
I found a dosbox-x debugger which corresponds one-to-one with source code, in addition to the alternative "ykhwong dosbox" debugger which is available inside his latest archive here.
Also, on the qdos effort, I think it's possible that there is a page fault, but that the hard lock of the video screen is overlaying the message. It may be possible to disable the 3dfx video so that the text message is seen. However, a simpler way may be the dosbox debugger and the gdb tool with a debug enabled qdos.
When the program locks or otherwise, the alt-pause combo (dosbox debugger) will stop qdos from running. The debugger window should then show the current eip address while some other keypress steps backwards through prior eip address values. Those eip values can then be used against the gdb tool to find the functions in qdos before and at the time of the hard lock. This is the gdb command for this: x/i eip-value. Part of this is a summary of the last paragraph here: http://www.delorie.com/djgpp/v2faq/faq12_2.html.
Perhaps this faq has a better method for the last part: assuming that the EIP value is NNNNNNNN, type this at the GDB prompt: list *0xNNNNNNNN
You may have already considered this or solved the issue, but hopefully this is useful.
I'll create a zip of what I have currently and post it a little later. Let me know what you find, if anything.
There's a few odd-ball bugs with the whole mesa thing which I don't think will ever be resolved:
* SLI does work properly, there are speed improvements (it's enabled by default, but can be controlled with an environment variable). However, sometimes doing vid_restarts will screw the screen up. My assumption is that there's still processing of a frame going on and you happened to get stuck in it.
* V-sync disabling does work, but requires to do a vid_restart as soon as the game loads. You can control the vsync at startup though with SST_SCREENFRESH=<HZ>. A hacky way around would be to parse the CVAR earlier... Maybe if moved to cl_main.c it would apply those values immediately. But, I haven't tested this method yet.
* gl_ext_pointparameters fails on SSE machines. According to the OpenGL spec it's some kind of math trick for rendering particles. My guess is that whatever code mesa is using for SSE aware machines is clashing somehow with point parameters causing a hardlock or infinite loop. However, in the knownbugs file of Mesa 5.0.2 it mentions that gl_ext_pointparameters has issues with Quake 2. So it's rather hard to say.
Despite these shortcomings the rest of it works quite well. I did some tests running it against the Windows builds on the V3 and V5 because these cards have actual opengl32.dlls to specification and the speeds are about 10fps difference in timedemos (with Windows winning). Keep in mind, this is compared to using regular default Opengl, NOT the 3dfx OpenGL option from the video menu! 3dfxgl is a special mini driver that contains only the GL functions needed to play Quake and they likely have some kind of hacky optimizations to allow for more speed. I don't know enough about glide semantics or even opengl to attempt to strip mesa away and write my own minigl driver for this purpose. But, someone else with enough time on their hands and the knowledge could certainly do so (though this seems unlikely).
Well i fixed the vsync and refresh rate control. Just needed to be parsed earlier in VID_Init.
Anyways, here is the source: http://dk.toastednet.org/QDOS_MESAFX_SRC_082015.7z
Build using make -f makefile.gl
Thank you for sharing such interesting results. It seems that you have found solutions to all problems! I appreciate this as you now have solved that 2nd issue in short order. I actually noted that disabling "gl_ext_pointparameters" may have solved a hard lock in the V1 emulation of dosbox. I had this happen yesterday, started testing today, but your latest commits fixed it. I was quite glad, and I'm not positive it was the pointparameters, but it would be a good guess. This all seems perfect.
The SLI also doesn't seem like an issue because the user could just avoid "vid_restarts" in that case. Perhaps the vid_restart could be disabled in the case SLI is detected and inform the user to restart the game instead. It must have been a lot of work to find any corner cases and it shows how stable your builds are. It doesn't sound like there is any reason to parse newer mesa source or modify further for improvements; I noted how impressive the palette changes are, I never noted the early Voodoos having the vibrant colors as it has now (perhaps attributed to true opengl, too).
The performance tests are interesting. I wonder if the mesa dll in Windows would compare favorably with that in Dos. If those are similar, then perhaps the 3dfx dlls are doing something undocumented and not very reproducible.
Thank you for posting the link! I'll give it a try and report in detail on any results. Given the work that you and sezero have done on the fxmesa compatibility, I would think any glquake issue is in quake itself, fortunately.
