Personally I wish someone could add acebot to sh2.

The ChaosDM mod requires a client here.

The inline assembly code of Q2 is not available outside the MSVC format. I ported some of these functions to increase performance in DOSBox. I recall that one remaining (major) function did not port, so instead the gcc pre-processor and optimizations per single function were used as an alternative method to reduce any bottleneck in performance. These features required GCC44 or higher, so GCC 4.5.3, alongside the DJGPP 204 environment, was used to build all binaries. This version is also reported to have good compatibility with DXE3.

To start a game mod, run q2dos.exe and press the key '~' to view the game console. Type game acebot to point to the ace directory containing the acebot files or any other directory name which has a quake2 modification. Then, type maxclients 12 to include up to 12 other bots (Rogue's mission pack maxclients no higher than 8), and deathmatch 1 for most cases; finally, map base2 where base2 is an example of a map file to load.
-Or instead use the Dos commandline-
Examples: q2dos +set game 3zb2 +map q2ctf1 +set ctf 1 +set maxclients 12
q2dos +set game rogue +map mine1 +set deathmatch 1 +set maxclients 8
q2dos +set game action +map punwar +exec autoexec.cfg +set deathmatch 1 +set maxclients 8
q2dos +set game dday +map dday1 +set maxclients 8 +set deathmatch 1 +set bots 1

Action Quake 2 Mod
This mod should reside in the action directory. Commands include ltk_skill to change the bot skill (1 - 10).

Dday Mod
The mod, Dday v5.0, is available here or here. To start a botmatch: bots 1; map dday1. Other settings for bots: playerminforbots #; alliedbots #; axisbots #.

ChaosDM Mod
Bots are deployed by this command: sv addbots 5. Where 5 is the number of bots. [This q2-dos.exe binary can replace that used in the q2-bots.v1.7z archive; the /chaos/ directory can likewise be added as a directory under /quake2/.]

Technical notes: libc functions appear in static table although it is possible to automatically load the dynamic library. The former method is suggested by the djgpp web pages since it avoids possible conflicts among libraries and warning messages about crt0 specific functions.

Can you send us your changes for the inline assembly and the source code for the various mods you ported? I will add it to the git repository.

You're welcome to the source code posted above. An updated archive should be posted soon.

ggorts wrote:

You're welcome to the source code posted above. An updated archive should be posted soon.

Please let me know, I'm very interested in trying out the converted assembly code. R_DrawParticles is supposed to be slow in nonwin32.

That was the "one remaining (major) function that did not port". Instead, I used the method mentioned above which involved the gcc45 pre-processor/optimizations.

thats ok, im still interested in the rest.

< consolidated the Q2-ChaosDM archive in the 3rd post above >

Attached is a patch to expand use of asm code and also the gcc optimization of that single function.

can you post the entire source to everything as a single 7z for me to check out? Is your mods converted to use my gi.dprintfs with DEVELOPER_MSG_GAME for filtering?

i added the diff but it made no discernible speed difference. At least on real hardware. I ran timedemo 1, demomap demo1.dm2 4 times and got the same result every time.

This was tested on real hardware, a P2 400 with 1GB SDRAM.

The dprintf function was not updated so that mods port with less modification. I'll work on cleaning the source tree so it can be uploaded, too, but it may take some time.

As an aside, it is best to rename the dynamic libraries with the .dxe extension only. Otherwise, given that the dxe3 system is not patched for use of other extensions, it won't work fully with dxe3gen.

The timedemo does not recover the performance difference. Try leilei's quake1 port and observe the brief lag with color particles. This effect does not lead to widely different timedemo reports.

are you using a different make file for making the dxe's? I can rename to dxe if theres a specific reason

Use dxe3gen to dump the list of functions in the file. It will work with dxe but not dx3, at last from my brief testing.

I don't understand what is the problem here? you just compile it like normally with dx3gen -U and if theres some warnings about exports you just add DXE_EXPORT.

The makefile can use the dxe3gen tool to dump the functions for a bug report. Without the dxe extension, the functions did not list, and this may have other effects, too. There may even be a way to auto-patch the sys_dos.c file with this method, but I'd have to confirm it; try other parameters in dxe3gen to observe.

Try this:
dxe3gen --show-unres gamex86.dx3

Then this:
dxe3gen --show-unres gamex86.dxe

I think you are supposed to be using dxe3res. If you run that against the dx3 it will show a header file you can use for easy exporting.

If it showing only for dxe but not dx3 it may be a bug in DJGPP 2.05 and should be reported as they are currently working on unifying everything regarding these types of issues.

EDIT: I reported the issue to DJGPP's dev mailing list. I'm also curious about using dxe3res as it showed using DXE_EXPORT_ASM for these functions instead of DXE_EXPORT and whether or not this could be a speed issue. But I haven't noticed any performance hits since switching to the DX3s over static built games.