VOGONS


FitzQuake for DOS [fxMesa]

Topic actions

First post, by Maraakate

User metadata
Rank Oldbie
Rank
Oldbie

After the fun with Q2DOS and using fxMesa to get 3DFX support working I went ahead and ported QDOS and QWDOS (http://dk.toastednet.org/QDOS) to use it as well. I then proceded to port FitzQuake for even more fun 😈

It's been slightly tweaked for BSP2/PSB2 support and fence textures. This means that Rubicon Rumble Pack and other huge mods will play properly.

I'm not bothering to reimplement 8-bit textures as you really need at least a Pentium 3 and Voodoo 3 (really should be using a V5 5500 IMO) for this port if you're planning to play the larger mods.

Binaries: https://bitbucket.org/maraakate/fitzquake-dos … Z_EXE_LATEST.7Z
Source: https://bitbucket.org/maraakate/fitzquake-dos/

I should mention that all of my Quake DOS projects also included the MPXPLAY library for PCI sound card support. This includes Intel HD audio and some other soundcards. Start the game with the -hda parameter to enable it. It's hit or miss if it works, but if it works in MPXPLAY it's very likely it will work in my ports. So if some of you out there are on some crazy fast modern machines with later generation PCI Voodoo cards I'd love to hear if it works for you, and how fast it is.

Wav and OGG music streaming from QDOS are also imported, as well as WATTCP so you can play it online.

I'm not including any screenshots because it looks the same as FitzQuake. However, do be sure that R_skyalpha is off or you will have severe slow downs in maps (on a Voodoo 3 anyways, untested on my Voodoo 5).

Reply 1 of 86, by __ggorts

User metadata
Rank Member
Rank
Member

I've been using fitzquake-dos and it's excellent work. I also noted your recent work on dmesa which is novel and which provides, at the very least, a welcome test environment. I've been running the Rubicon maps, too.

[As an aside, if leilei is still interested in tinygl, then it may be possible to use dmesa under an alternate name space while linking to tinygl, thereby allows one to address specific functions to tinygl and to dmesa for the remainder. However, this is untested, but q1 provides a good test case to measure the performance and whether tinygl is compatible.]

Reply 2 of 86, by Maraakate

User metadata
Rank Oldbie
Rank
Oldbie

I got DMesa 5.1 working which has some bug fixes, and specifically, it supports the gl_extensions properly according to the changelog. I had some problems in SLI so I didn't use it yet, but the last version of glide3x from the development branch on sourceforge appears to fix these issues. Have to do a bit more testing, but after that and sezeros OK we may move to that version.

Reply 3 of 86, by __ggorts

User metadata
Rank Member
Rank
Member

That is all good news and impressive work. It's difficult to implement what you did since there are little to no examples in a context outside glut demos. 😀 I'm glad to hear that there had been further work on the glide3 library, too. I also look forward to seeing how comparable the resulting screen image is between fxmesa and dmesa.

Reply 4 of 86, by Maraakate

User metadata
Rank Oldbie
Rank
Oldbie

It's more like rather annoying. There are very subtle quirks all around between testing these versions.

CVG (Voodoo 2) hard locks on real hardware with the last glide3x version and sezeros for me when I build it. Can you try to build it from QDOS's mesa51 branch or Q2DOS (master branch) for me? Maybe its a GCC 4.84 issue.

Reply 5 of 86, by __ggorts

User metadata
Rank Member
Rank
Member

Be glad to. I'll work on this and send binaries (I presume this is a cvg only issue).

Reply 6 of 86, by __ggorts

User metadata
Rank Member
Rank
Member

I'm using the qdos mesa51 branch....

Edit: turning on FX in makefile (FX=1).

Reply 7 of 86, by Maraakate

User metadata
Rank Oldbie
Rank
Oldbie

Okay. Yeah I just need the glide3x.dxe. It needs USE_X86=1 for CVG apparently according to makefile

Reply 8 of 86, by __ggorts

User metadata
Rank Member
Rank
Member

Roger. 😀

Edit: FX_GLIDE_HW ?= cvg and export USE_X86 ?= 1

Edit2: took 7 seconds to build!

Reply 9 of 86, by __ggorts

User metadata
Rank Member
Rank
Member

Here it is. I'll also test the sst1 to verify the build process.

Reply 10 of 86, by Maraakate

User metadata
Rank Oldbie
Rank
Oldbie
__ggorts wrote:

Roger. 😀

Edit: FX_GLIDE_HW ?= cvg and export USE_X86 ?= 1

Edit2: took 7 seconds to build!

Changnig the export is unnecssary you can do this

make -f Makefile.DJ FX_GLIDE_HW=cvg USE_X86=1 USE_MMX=1 USE_3DNOW=1 USE_SSE=1 USE_SSE2=1
without having to change makefiles

Reply 11 of 86, by __ggorts

User metadata
Rank Member
Rank
Member

Thank you for the hint!

Reply 12 of 86, by Maraakate

User metadata
Rank Oldbie
Rank
Oldbie

Yes your compile works. Can you do a compile with the make flags I just sent you

make -f Makefile.DJ FX_GLIDE_HW=cvg USE_X86=1 USE_MMX=1 USE_3DNOW=1 USE_SSE=1 USE_SSE2=1

Also what is your build environment.

Reply 13 of 86, by __ggorts

User metadata
Rank Member
Rank
Member

Verified that the sst1 glide3x.dxe is functioning so far in qdosfx (the glide3 just built from qdosfx/51).

Reply 14 of 86, by __ggorts

User metadata
Rank Member
Rank
Member

I'll build a binary as you specified.

Reply 15 of 86, by __ggorts

User metadata
Rank Member
Rank
Member

Using djgpp204/gcc295.

Reply 16 of 86, by Maraakate

User metadata
Rank Oldbie
Rank
Oldbie

Wow on real hardware it's actually quite a bit faster. I can actually play Q1 properly on the p1 mmx without a lot of shitty framerate drop.

Reply 17 of 86, by __ggorts

User metadata
Rank Member
Rank
Member

Awesome!

Reply 18 of 86, by __ggorts

User metadata
Rank Member
Rank
Member

And the highly optimized cvg glide3 binary:

Reply 19 of 86, by __ggorts

User metadata
Rank Member
Rank
Member

I don't think the binary built with all the optimizations yet, even though I ran the command line correctly. However, I'll continue to test the compiles until it shows all optimizations in stdout/stderr while building.