_ggorts wrote:

Attached q2dos with qbism's software renderer (color lighting). Renderer is statically linked.

cvars: r_coloredlights, r_lightsaturation, sw_transmooth.

Are you having issues with compiling it as a ref_soft.dxe? I think there's some hardcoding to always default to ref_soft but that can easily be changed.

I haven't recently tried, but I think it should work. I was testing the enhanced renderer to determine whether an opengl version will port to quake2/dos. I will test the opengl code next.

Can you compile it as a DXE and I will try it that way.

I will try that after I test the opengl code. If you require the dxe sooner, then the source code is available from qbism's web site.

I misunderstood, I thought you compiled Jack Whitham's stuff instead. Have you attempted that?

Anyways, the performance hit actually isn't that bad! I tested it out on the p3 550 and lost about 8-10fps on average so it's defenitely playable on older computers. It looks pretty good for the most part except the gun has kind of a greenish tint around the light. The water looks really nice. When you get a DXE made up, send me the code for the renderer and I'll add it in as a second renderer path and add it to the video menu.

I'm assuming qbism still hasn't done correct colored model lighting code and is doing the awful samplelightpointandblenditoverthemonochromaticallylitmodel approach I quickly snuck in for screenshots.

I did try to get the real thing in before but had a lot of segfaults and since I was doing this on Win7 where MSVC6 can't debug, I had to go for the awful way for a result

really it doesnt look all that bad for "awful" it is, if the gun colour can be tweaked a bit I'd use it.

leileilol wrote:

I'm assuming qbism still hasn't done correct colored model lighting code and is doing the awful samplelightpointandblenditoverthemonochromaticallylitmodel approach I quickly snuck in for screenshots.

I did try to get the real thing in before but had a lot of segfaults and since I was doing this on Win7 where MSVC6 can't debug, I had to go for the awful way for a result

I've been able to run and compile q2dos just fine in VS2005. GL has issues, but software seems OK.

Showing progress via the attached q2dos test binary for 3dfx Voodoo 1 (untested in other 3dfx card types). The binary starts a 3dfx window and shows an in-game console, but freezes before the game starts. This was only tested in dosbox with 3fdx emulation.

Edit: test binary shows incomplete result and requires a different glide library.

Try with -nosound and -nocd. Check glide3 code for nearptr_disable and remove the line.

Can the console output stuff? i.e. can you type command and see responses? Does the intro video play?

And can you compile a voodoo 5 build?

Or even a voodoo 2 or voodoo 3 build. I can't get it to run on any of them. It complains expected voodoo graphics none detected.

I tried it in pcem and dosbox. I noticed you cant pass +disconnect or other commands as it will segfault. doing q2 +map q2dm1 will attempt to load the map but it always fails at images.

A few concerns were that I saw gl_ext strings is reporting vertex arrays and other extensions I know a voodoo card can't handle and it may be part of the problem. If you can please get an v5 or v3 build for me to test on real hardware I'd love to try it there, along with your current entire source.

Thanks for testing and confirming that the glide drivers are card specific. It may help to try mesa without hardware acceleration, removing any glide problems from the test. Also, I think linux may have used the mesa 2.6 version with glide2, so that may be tested, too.

I did try to build the h5 library, but my current djgpp/gcc environment is not as compatible. Use of the mesa without glide should make the tests run on any system (without a 3dfx card).

Can you build the vooodoo 3 version then? I have a feeling that it might work but the voodoo 1 code specifically states that they're unsure if it evens works at all.

The 3dfx models above V2 (cvg) were not building as easily, so I used the early model versions for testing. I also agree that the V1 glide3 code is not considered complete; however, testing with mesa without hardware acceleration should confirm whether that is true. Also, mesa26 relies on an older glide library, so that is another library version to test with.

You might have to go djgpp 2.04 for that particular project, but I'm unsure. Keep me posted, the fact you got anything to draw on the screen and at least write to the card is very promising.

I've been using djgpp 204. I updated the above to show that mesa5 seems like the best version for use with djgpp. However, there is both fxmesa code and the non-accelerated code within this version, so the binary can be tested without glide3.

I tried testing previously with the mesa5 stuff but I may have compiled it wrong. As soon as it would load and change the screen resolution it hard locked every time.

I will try the watcom compiler next.