Thanks!

Edit: works perfectly.

This works in XP NTVDM: q2.exe -skipwincheck -nosound +set sw_mode 2

Requires a .PIF file where "Fast pasting" is turned off in "DOS" property sheet.

Uses 640x480 banked mode. Sound not working yet (tried -dsp 2), but vdmsound and gusemu is worth testing.

doesn't work properly for me. May be my intel integrated card. I tried Win9x too and get bad results as well.

I haven't mentioned anything, but recently we went ahead and moved the gamespy code into a separate DLL/DXE since the SDK was open sourced but never licensed under the GPL. The header used for the q2.exe binary only contains the enumerator definitions required for gamespy compile now. With this way, you can actually compile it with -DGAMESPY and no gamespy.dxe and not produce warnings if you really want to omit it altogether. Although, we did an extensive bug fix to it and I recently rewrote the entire send/recv function from the SDK to work properly in windows and DOS on the same codebase and now I can ping ~300 servers on a Pentium 1 in under 10 seconds which I think is quite impressive. Previously, it used to take almost up to a minute(!). I also rewrote the browser menu to first sort the servers by ping and active users, then it will show all the inactive servers afterwards sorted by ping. The list has the ability to show all the servers now and scales somewhat by resolution for better viewing. You can even use QTracker's master server if you really wanted to.

The gamespy list also now uses non-blocking sockets properly so you can actually ping the servers while in a match or single player. Previously you had to disconnect because of the synchronous pinging.

We also found a lot of little weird/silly bugs recently in some of the mods regarding the use of just using sprintf instead Com_sprintf and converted everything to use strtok_r from OpenBSD instead of strtok.

I'll try to release a binary for testing in ntvdm which isolates the NT friendly (video) code. There is a note by "TheGreatCodeholio" about ntvdm sound emulation and the dma buffer size. This is one area to verify in the Quake 2 sound code.

The d_part* assembly code from Quake 1 may port more easily to Quake 2 instead of translating the inline code, particularly for the _100 particle case.

The strtok functions that existed may be used by other mods (such as Rogue/acebot). It may be better to allow those to export based on a definition line instead of #if 0 ... #endif. This will allow future mod porters to more easily adapt their mod.

Excellent work on the Gamespy code and method to include/exclude the functionality.

ggorts_ wrote:

I'll try to release a binary for testing in ntvdm which isolates the NT friendly (video) code. There is a note by "TheGreatCodeh […]
Show full quote

I'll try to release a binary for testing in ntvdm which isolates the NT friendly (video) code. There is a note by "TheGreatCodeholio" about ntvdm sound emulation and the dma buffer size. This is one area to verify in the Quake 2 sound code.

The d_part* assembly code from Quake 1 may port more easily to Quake 2 instead of translating the inline code, particularly for the _100 particle case.

The strtok functions that existed may be used by other mods (such as Rogue/acebot). It may be better to allow those to export based on a definition line instead of #if 0 ... #endif. This will allow future mod porters to more easily adapt their mod.

Excellent work on the Gamespy code and method to include/exclude the functionality.

d_part* uses extra stuff now for blend particles. I'm working on it, just haven't finished it yet.

Future mod porters should be using strtok_r anyways. You now have a unique pointer to your tokens. Regular strtok can be dangerous with the pointer being overwritten like a call to varargs around the same time a strtok can happen. It will also allow you to work with more than one strtok at the same time.

Theres no sense in the NTVDM shit. Quake 1 doesn't even work properly with it. Just compile with VS6 from quake2.dsw which gives you all the options. There's no speed advantage (in fact it's quite the opposite) in using q2dos in NTVDM, however in pure DOS vs win98 there can be a difference with q2dos having an advantage but this isn't always the case.

I haven't encountered any strtok related errors in-game. Perhaps the mod authors could find this information in the "mod porting" guide enclosed with q2dos? The strtok change (and others which relate to mod porting) could be documented to make the porting effort easier for others.

I tested Quake 2 in NTVDM several times. It may now be possible to transfer that functionality to Quake 1, too. I had been working on the audio issue.

I'm still confused as to why you want NTVDM support. There is 0 advantage to it. You don't even get online play working unless you use that swspkt driver which I have never been able to get working in Windows XP anyways. And now you have to emulate sound blaster.

SPOILER: The Vogons forum was founded in 2002 as a big "fuck you" to NTVDM and its drawbacks, so let's not encourage turning back to the dark "help my dos game wont work xp" ages.

It opens the possibility of linux/dosemu as another host for Quake 2. It also tests "corner cases" as TheGreatCodeholio has done with demos in dosbox-x.

It works in a 95 dos box with the parameter -nosound, too.

This may be relevant to the NTVDM soundblaster 2.0 issue:

1Problem: Programs crash with a General Protection Fault due to address wrap being unsupported:
2
3Exiting due to signal SIGSEGV
4General Protection Fault at eip= ....
5cs: sel=... base=... limit=7e27ffff
6
7If any limits have the first digit starting with "7" then this is the address wrap problem.
8Note: this is also seen on Windows NT.
9
10Workaround: Patch each DJGPP binary (here).
11
12Fix: libc/crt0/crt0.S (cvs revision 1.7), V2.03 refresh.

With sound activated inside ntvdm, the error does fit the above criteria.

And by the TheGreatCodeholio:

1In Windows XP, NTVDM.EXE's native Sound Blaster emulation makes a lot of assumptions about the DMA verses Sound Blaster DSP block length to the extent that if the DMA buffer length is not a multiple of the DSP block size, the Sound Blaster emulation will play additional audio up to 64KB past the end of the buffer

if you want, fix it. but i don't care. compile vs6.

If setting "USE_CURL=0" in Q2Dos makefile, then there is a TCP/IP Segmentation Error in XP NTVDM. The error does not occur where "USE_CURL=1". From limited testing, this is independent of the other makefile settings.

There may be leftover dependencies on the CURL library where building without it.

you should just be able to compile it in linux with the /linux c files from regular quake 2 if you are that concerned about it. I could care less about NTVDM support or even the emulators honestly. This whole port was intended for people with actual DOS computers.

Attached two patches against a recent version. Patch #1 activates a minimal build for use in NTVDM. To test, here are potential command lines to run Quake 2:

1q2.exe -skipwincheck -nosound +set sw_mode 2
2q2.exe -skipwincheck -nosound +set sw_mode 1
3q2.exe -skipwincheck +set sw_mode 1

With sound turned off, Q2 runs in 95 dos box or XP NTVDM.

Patch #2 activates "DSP version 2" mode and circumvents the "0x7..." page fault error while sound is turned on. It may also avoid the dma address wrap issue (untested). The resulting page fault error is different and not apparently related to the dma address wrap. Potential causes could be the dpmi provider, the memory model, or the audio samples. Further tried reverting code to the Quake 1 sound code without success (Quake 1 sound works in the 9x dos box).

However, linux dosemu reportedly has sb16 emulation, so that may help diagnose the issue. If it works there, then the soundblaster code could be further reverted to Quake 1.

Also, modified the PAINTBUFFER_SIZE from 2048 to 512 (default in Quake 1).

I'll give you a hint as I know partially what it is... Look at SND_BUFFER_SIZE in snd_loc.h This value was changed. If you lower that it will probably work, but I prefer you make a fork instead of posting patches.

If you lower SND_BUFFER_SIZE you may get issues with frequencies over 22khz. But the lower PAINTBUFFER_SIZE might be compensating for it. I don't know, but have fun.

I'm sure the SND_BUFFER_SIZE increase is part of this issue because I raised it in Quake 1 for QDOS and around that time QDOS was 100% broken on Win9x which is fine because it also typically crashes changing resolutions, exiting the game and other shit and I really don't care.

Thank you for the information. The decreased buffer size allows Quake 2 to report sound initialization without error, but there is not yet output of sound via the ntvdm. However, I haven't tested on another system. Perhaps vdmsound would now work.

There are reports that vdmsound has issues after XP sp1. I don't have an early version of XP, but that should be a better test system toward ntvdm compatibility. However, it is worthwhile to verify and document the audio code.

I like the enhanced R_DrawParticle function. Would it further help (avoiding function calls) to inline the other vector math functions (dotproduct; vectorsubtract), too?

This appears to be a change from the original snd_dma.c code:
// mix ahead of current position
endtime = soundtime + s_mixahead->value * dma.speed;
//endtime = (soundtime + 4096) & ~4095;

Is it better to align the endtime as originally intended?

This may be listed 2x (redundant statement) in snd_sb.c:
dma.samples = size/(dma.samplebits/8);

Lastly, the djgpp faq has interesting information on NT dpmi: http://www.delorie.com/djgpp/v2faq/faq18_6.html.