I'm using djgpp204.

I'm using 2.05 with gcc 4.84 but you can probably use GCC 5 now that Rayer found out using -std=gnu90 will force it to use the older style inlines.

In either case, it just appears to be a bug related to the file extension. When you are ready, please send me the source files to the mods and I will update them to use the developer flags and add them to Q2DOS. I added your patch with credit to our git repository and made sure to keep WIN32 compatibility as I "cheat" and do most of my debugging in windows.

It's also a lot easier if you get a copy of git with git gui (if you are on windows) and fork our project. When you are ready you just submit a pull request then I can merge it and we can keep this unified. I don't want this to be like the old days of doom and q1's early source days where there was all kinds of ideas branching off too many branches and it took years for those guys to get unified engines.

The source code is now posted alongside the other archives earlier in this thread.

Thanks for the source. What is specific that Action Quake 2 required it's own executable?

Your welcome. Was that executable a batch file with AQ2? It was there for convenience since that mod required a lot of testing. If it was the Q2 binary with ChaosDM, then that was for expediency and lack of testing the new binary with the other mods, although it should be fully compatible with them. Those files are from the 3rd post. The 1st post is sort of obsolete now since you implemented dxe3.

I have went ahead and added all of your mod ports (with credit of course) at https://bitbucket.org/neozeed/q2dos/downloads … S_EXE_062815.7Z

Can you update the first thread to point to it?

Thank you. I'll add the update, too.

Thanks a lot. The Chaos mod is pretty interesting. It reminds me of an early weapons mod and painkeep. 3ZB2 is especially interesting that the website is still available for it.

I agree, they are both exceptional and the Chaos mod artwork holds up well today. I think the mod Weapons Factory 4.2 will port, but I tried to include the Eraser bot code. The important bot code, including navigation functions, are in p_trail.c. This enhanced file is unavailable to the public, but the author distributed an object file instead (compiled by MSVC5 and gcc/linux). I haven't found an email address for the author so that we can request an object file compiled in the djgpp coff format. If that was available, then other mods with Eraser could be ported, although it's not necessary since we already have a number of good mods. I already tried automatically converting the file with tools, and there are reports that manual conversion is near impossible, along with another problem if the object file is not in a flat memory addressing mode (which it probably is).

Releasing source reminds me. I have to finish cleaning up some small things on the gamespy emulator i wrote specifically for this project and my QWDOS project. It's based off the gloom/q2 master server code with some helper functions from aluigi for the encryption. Currently, it's just hardcoded to grab the raw server lists from qtracker and quakeservers.net.

I look forward to trying out an online game via your emulator. At some point it may be interesting to test the robustness of bots on a quake2 server with stock maps, and whether they persist between map loads.

The emulator only works in early gamespy games that use the "basic" protocol and some support for a weird transition between "basic" and the 1st revision

The games that are tested to be supported:

blood 2
daikatana
any game utility that uses "gamespy lite" (i.e. kingpin, south park, turok 2)
hexenworld (an engine would have to be coded to send a heartbeat to it, but this is trivial)
kingpin
nolf 1
quake 1 (an engine would have to be coded to send a heartbeat to it, but this is trivial)
quake 2
quakeworld
sin
south park
turok 2
unreal 1
unreal tournament 1999

I originally wrote it for use with Daikatana but expanded it's capabilities when I started merging part of the gamespy SDK into QWDOS.

If you're interested in taking a peek at the emulator (this is a special hardcoded version just for QW and Q2) it's available at
https://bitbucket.org/maraakate/qdos/src/c22e … STER/?at=master

For it to work you have enable quickvalidate and either disable validation or at least enable it for clients (obviously QW and Q2 aren't going to respond to the encrypted keys, but games like Daikatana will and it's required for those games).

That's wonderful work, thanks! I'll try it out now. :)

Also, please avoid stripping the q2 executables. There is a bug where the particles appear tiny. Observed before and after stripping any q2 executable on start base1 map (which makes me wonder about the dxe files, too).

ggorts wrote:

That's wonderful work, thanks! I'll try it out now. 😀

Also, please avoid stripping the q2 executables. There is a bug where the particles appear tiny. Observed before and after stripping on start base1 map.

They're not stripped as far as I know. I am only using UPX, but I have previously run into issues with UPX in the past... Maybe it has to go.

Also you can manually change the master server with cl_master_server_ip CVAR to test it out to yourself.

Here is the batch file i use to run the public server:
master.exe -debug -quickvalidate -validationrequired 1 -heartbeatinterval 5

Maybe it's the pragma code I suggested. I'll check further into it.

ggorts wrote:

Maybe it's the pragma code I suggested. I'll check further into it.

It may very well be, that's why I tried to avoid the use of GCC optimizations and various flags unless they were tried and tested (i.e. the ones in use now are the ones used by Yamagi).
I recall a couple of years ago I ran into issues with either UPX or a combination of GCC flags (or even both I can't really remember anymore) with QDOS and odd graphical glitches.

The main reason I have been using UPX -9 for the binary is for transferring across floppy disks as I have multiple computers and sometimes I'm just too lazy to load up all the packet drivers across them.

I have to be honest, I played through xatrix again with your optimizations and there was no speed increase or decrease. At least nothing I could tell or measure and this was tested on real hardware.

Confirmed its the -ffast-math optimization. :( Perhaps it's better to remove those 2 lines until we can determine whether the speedup is significant, maybe by a counter on that function and printf the counter after a timedemo completes.

I think the asm code in the math.s has no known drawback, but the pragma stuff is definitely an issue. At least now we know for sure that any cflag is suspect.

I pushed the change to the repository for now and will update the binaries on the site.