Appreciate the suggestions! I'll spend some time reviewing those. I have several single player levels from a site with reviews, given that the top maps are much better than those in the middle; but if even the middle rated maps are fun, then I should try to search for decent map packs/archives after trying the above.
Mesa3d has a site to browse their commits: http://cgit.freedesktop.org/mesa/mesa/. Under branches, I was looking at these: mesa_5_0_branch; mesa_6_0_branch; mesa_20040127_branch.
And these particular commits looked interesting to try, even though probably not worthwhile unless they bring an obvious benefit:
mesa6 readme - http://cgit.freedesktop.org/mesa/mesa/commit/ … nch&id=0849ed12
mtex - http://cgit.freedesktop.org/mesa/mesa/commit/ … ch&id=0ee5f6203
nasm updates - http://cgit.freedesktop.org/mesa/mesa/commit/ … ch&id=6d4afe2a9
I also noted that the SLI function is in glide3x. I wonder if the other version(s) of glide3x also show that same SLI issue.
wrote:Mesa3d has a site to browse their commits: http://cgit.freedesktop.org/mesa/mesa/. Under branches, I was looking at these: mesa_ […]
Mesa3d has a site to browse their commits: http://cgit.freedesktop.org/mesa/mesa/. Under branches, I was looking at these: mesa_5_0_branch; mesa_6_0_branch; mesa_20040127_branch.
And these particular commits looked interesting to try, even though probably not worthwhile unless they bring an obvious benefit:
mesa6 readme - http://cgit.freedesktop.org/mesa/mesa/commit/ … nch&id=0849ed12
mtex - http://cgit.freedesktop.org/mesa/mesa/commit/ … ch&id=0ee5f6203
nasm updates - http://cgit.freedesktop.org/mesa/mesa/commit/ … ch&id=6d4afe2a9
Frank had no success using MesaLib-6.2.x (IIRC he had a black screen), but we
may try again this time using 6.2.x _with_ changing code to use only dmesa instead
of fxmesa functions.
I can try to hand-pick and apply those patches to our 5.0.x too: maybe it helps with
the multitexture silliness Frank has been experiencing.
The demos work well with mesa51, but as I think has been noted earlier, there is a black screen on starting q2dos. I hope the regressions in code don't occur too quickly. Any application of commits and your results on dmesa should be especially insightful.
D. Borca (fxmesa) had further conversation on a thread at 3dfxzone, but of particular interest was that trilinear and multitexturing are mutually exclusive (if I'm able to interpret it correctly, that there is a single pass trilinear only where multitexturing is off, but it definitely sounded like a work-in-progress). He also noted that the minigl drivers are faster than mesa because they are optimized for q1/2 and nothing else. Likewise, the different mesa versions may show different performance (and this may include official drivers) often because of the parameters fx_glide_swapinterval and mesa_fx_swap_pending (fxapi.c), suggesting that the benchmarking may be misleading between different drivers. I don't know of any particular scenarios where these parameter values are expected to have a large effect.
I have already done extensive testing on running swapinterval and swap_pending and here's the deal...
Leave swap_pending at it's default value, 3. This is just like the maximum number of frames to read ahead or whatever it's called in nvidia. Unless you're having odd input lag issues don't fool with it. I tried 0,1, and 2. Each time you go lower the framerate drops a little bit in timedemos.
And yes, I recommend disabling swap interval. V-sync is pretty useless to me and it can effect framerate. I don't know if it affecting framerate by it's artificial cap is a hardware or software issue, but since even back to my early nvidia days after 3dfx went out of business I remember v-sync having the same results so I've just been conditioned to disable it in general and the game typically moves at such a fast pace I've never even noticed the screen tearing (if any) any more.
And yes, it's true the minigl was basically for the quake 1/2 family of games.
Of even more interest to you might be that I finally got CVS setup and grabbed the final development branch of glide3x that was worked on. The last commit was in 2008. There are two things to fix and they are in minihw.c. fenceVar has to be changed to be non-static or the DXE resovler will complain about "_fenceVar" missing. There is also another thing where an ifdef/elif/else statement falls back to adding something like
boardinfo->devName, <two other vars that are windows unique types>. Removing the last two things will make it work just fine.
Now, I did some compares to the fedora release from 2005 that sezero got working and they are almost the same except xdraw2.asm has some small fixes and the pending frame buffers count has been rasied from 3 to 6 as the clamp variable and has a mention that 6 is the absolute limit because of the way the bit is set.
Testing resulted in an approximately 2fps boost in timedemo demo1.dm2 in quake 1 at 640x480 on the P3/V3 combo.
Of note is an interesting ifdef that is not set, FAST_C_CLIP which is used if the ASM is defined. I added it to the makefile and tested it. You lose about 2fps when I tested it on the same setup... however it does contain ASM and it may result in a speed on older machines or higher resolutions but I have yet to test that.
The FAST_C_CLIP code is also available in the fedora code version. It was simplified in the final dev branch build to not contain so much code duplication, but otherwise is basically the same.
wrote:... CVS setup and grabbed the final development branch of glide3x that was worked on. ... Testing resulted in an approximately 2fps boost in timedemo demo1.dm2 in quake 1 at 640x480 on the P3/V3 combo.
Not worth upgrading only for that 1 or 2 fps gain, considering the possibility of something else might be broken on the way.
wrote:Frank had no success using MesaLib-6.2.x (IIRC he had a black screen), but we may try again this time using 6.2.x _with_ changin […]
wrote:Mesa3d has a site to browse their commits: http://cgit.freedesktop.org/mesa/mesa/. Under branches, I was looking at these: mesa_ […]
Mesa3d has a site to browse their commits: http://cgit.freedesktop.org/mesa/mesa/. Under branches, I was looking at these: mesa_5_0_branch; mesa_6_0_branch; mesa_20040127_branch.
And these particular commits looked interesting to try, even though probably not worthwhile unless they bring an obvious benefit:
mesa6 readme - http://cgit.freedesktop.org/mesa/mesa/commit/ … nch&id=0849ed12
mtex - http://cgit.freedesktop.org/mesa/mesa/commit/ … ch&id=0ee5f6203
nasm updates - http://cgit.freedesktop.org/mesa/mesa/commit/ … ch&id=6d4afe2a9Frank had no success using MesaLib-6.2.x (IIRC he had a black screen), but we
may try again this time using 6.2.x _with_ changing code to use only dmesa instead
of fxmesa functions.I can try to hand-pick and apply those patches to our 5.0.x too: maybe it helps with
the multitexture silliness Frank has been experiencing.
The multitexture patch sounds interesting. I would like to try it as apparently the Voodoo 4/5 (aka "Napalm" chipset) has support for this and that is where this code is applied to.
wrote:wrote:... CVS setup and grabbed the final development branch of glide3x that was worked on. ... Testing resulted in an approximately 2fps boost in timedemo demo1.dm2 in quake 1 at 640x480 on the P3/V3 combo.
Not worth upgrading only for that 1 or 2 fps gain, considering the possibility of something else might be broken on the way.
I'm going to run some tests of it on the pentium 1 and 2 and see if helps anything at all. But, it may be wishful thinking and may even be the reason it wasn't enabled by default nor is it mentioned in any of the docs that I read. (regarding FAST_C_CLIP)
All interesting findings and discussion! I'll follow the recommendations on the parameters where running the fx versions. The additional cvs source code is a good find, too (and thanks for the 'build' fixes). All this is nicely documenting the mesa/glide past progress and even if difference files are not incorporated into q2dos, perhaps they could be added to an archive along with the source? They may find use in the future or at least point to key spots in the code.
wrote:I did just port fitzquake to dos, 🤣. I'll test out the performance differences.
haha wow, that actually gives me a bit more optimism about Q3A / OA on DOS. 😀
wrote:wrote:I did just port fitzquake to dos, 🤣. I'll test out the performance differences.
haha wow, that actually gives me a bit more optimism about Q3A / OA on DOS. 😀
https://bitbucket.org/maraakate/fitzquake-dos
Done very half-assed in under an hour, but it is enough to play it. You'll probably need a hefty p3 1.0ghz or something I would imagine to play Q3A at a consistent 60fps in DOS if you ported it.
Added BSP2 support to fitzquake: https://bitbucket.org/maraakate/fitzquake-dos … Z_EXE_LATEST.7Z have fun.
That's great work! I just loaded the "rubicon map pack" in your latest version. Used this line: qdfitz -width 512 -height 384 -game rrp -heapsize 256000 -zone 4096 (mem=256 in dosbox/V1 with lfn). This map pack has hefty requirements, but the visual quality is outstanding.
you need zone 4096? I don't think I recall coming across too many map packs that required more zone memory.
There was some crazy huge map I just played recently... https://www.quaddicted.com/reviews/something_wicked.html
You're right, it didn't require the zone parameter. Thanks for the tip. Also, I just tried the "something_wicked" map and it doesn't find the map. This issue is noted in the comments at quaddicted.com and the map's reliance on special quake clients. My guess is the "gamedir" command is not available; but that's just from the comments.
I played wicked somehow before but I forget how I got it to load. I'll have to check my P2 pc.
Also, you tried rubicon 2 in qdosfx? I don't think it works there. I had to raise some limit for the map locust and the map telefragged fails with sz_getspace overflow without allow overflow set.
I'll try rubicon2, that's a good idea.
Oh, when you said rrp i thought you meant rubicon 2 thats why i was confused because even fitzquake wont load the map "telefragged" but locust loads ok
