Winquake-Z. Attached is a binary and source code patch of Winquake-Z, and the binary is archived along with the required SDL.dll library file. This third version has Winquake-X features and disclaimer, but instead SDL handles the video and other peripherals; the major difference is the SDL/OpenGL-HQ driver, requiring an opengl compatible video card, which replaces DirectX for the video processing. Another difference is the music volume has values 0.0 or 1.0.

The binary archive also includes a file named "wq-z-fullscreen.bat" and this may be copied to the Quake directory. If that "batch file" is run while Winquake-Z and SDL.dll are in the same directory, then Winquake-Z will upscale a 800x600 game window to full screen size using a scaler similar to the hq2x algorithm. Given that upscaling is desired because of a very high resolution monitor or so that the HUD and console text appear larger, then this upscaling technique should be compared against the alternative methods.

The source code is from Winquake-X, a Winquake SDL patch, and several utility functions from Quakespasm. For the SDL dependency, the SDL 1.2 library was patched with OpenGL-HQ and built separately in mingw/gcc.

Forgive the naggyness of the post but what about Engoo?

For years I've had several volunteers promise MinGW/GCC/SDL ports (without replacing the native Windows VC6 build) and none of them delivered.

Ideally, we should have a 64-bit vanilla-like winquake (wq) client. One method is to have the Quakespasm (QS) team incorporate the dx code into their 64-bit build and bypass any code which is gl-only; I don't know of any wq-like builds which have certain 64-bit compatibility, and which likewise requires extensive use of the debugger. Even if qbism super8 has this feature, it may not port easily back to wq.

It would also be interesting to have an enhanced software renderer in a wq build, like all the features in Engoo. I noted a post about qbism's loss of overbright lighting in his renderer. If Engoo lighting has no loss of vanilla features, then that should provide compatibility with recent maps, such as those by "sock" who I believe is a professional map designer. I think fog is another enhancement that is cited.

The problem is that enhancing the software renderer with gl-like features barely reaches the full capacity of the gl-specific renderer, such as the QS port. There is a loss of speed, color depth, filtering, and HUD/text scaling. My uncertain opinion is that specific maps should be selected and then used as goals for the software renderer. Also, the map designers should be aware of targeting gl-only renderers in quake. The quake community has drifted in this direction, notwithstanding the use of bsp2 maps. This divides the users into quake, as shown by recent gog.com posts, and fitzquake-like camps, given the latter considers the former obsolete.

Engoo maintains the canonical software look of Quake by default. All overbrights are there, colored or not. It'll switch on fog when a map wants fog. The fog is fast because it works on the wall, sprite, particle and model spans, as opposed to reading the screen buffer and applying it from the depth (what qbsuper8 does)

The only problem with engoo's default vanilla behavior is the sound looping being regressed, the waterwarp screen effect regressed and the cd audio support broke. 🙁

sadly during engoo's development, demands for even higher 'standard' limits were constantly proposed and closed to some "remake quake" engine of a project that was way too ambitious for its own good. and then there's strange demand for translucent brushes and alphatest textures like Half-Life, just out of the blue. I got fed up with it all and stopped, after implementing most of the "Quake Standards BasE" which was agreed upon by port authors years earlier. New protocol/standards creep is too much to keep up of

It appears that your port already has the MGL dependency removed. The SDL code is much less tested and incorporating it may require debugging across both quake and SDL code. However, if the above SDL port shows stability over time, then it would definitely be worthwhile to add it to engoo. The mingw makefile system should be simpler to add and perhaps a more efficient system toward testing potential regression fixes.

The quake map archival web sites could further "flag" maps by game engine type, and noting where maps have been enhanced from an original q1-compatible version. Also, I don't find many active public servers, so I wonder whether the newer protocols are used in locally organized games.

I've always wondered, what's with the lack of good Quake sourceports? I just want to see something for Quake like Chocolate Doom; an engine focused on delivering the original look and feel, while still working on modern systems.

Engoo started off as that, but many were uninterested in a straight-up DOS quake recreation project and wanted the shinies so I started off on QIP (which had a bunch of boring fixes) instead.

When I recreated the Quake 1.01 menu tint and got 360x400 working in Windows, the reception was just "Whoopdeefuckingdoo" and "do work whit rygel texture's????"

leileilol wrote:

Engoo started off as that, but many were uninterested in a straight-up DOS quake recreation project and wanted the shinies so I started off on QIP (which had a bunch of boring fixes) instead.

When I recreated the Quake 1.01 menu tint and got 360x400 working in Windows, the reception was just "Whoopdeefuckingdoo" and "do work whit rygel texture's????"

Engoo is neat, but the one problem it has is that it's extremely resource demanding, at least the last time I checked. I wonder, could some of the game's software-only effects be replicated in hardware on modern graphics cards? Also, why don't any ports support FLAC music playback?

mr_bigmouth_502 wrote:

I wonder, could some of the game's software-only effects be replicated in hardware on modern graphics cards?

That's a question DirectQ answers with pixel shaders, but i think that's drifting far off the thread's subject

I have a (partial) list of 64-bit changes that apply to Winquake, but not yet able to test it. Noted that the necessary changes for Win32 to Win64 is simpler than converting for Linux.

In the meanwhile, I tested 32-bit Quakespasm (QS) where the GL renderer approximates the features of the software renderer; this client also provides a 64-bit path to making a binary.

However, I noted 2 noticeable differences during testing of the 32-bit QS client. One is the weapon positioning which is the same (or similar) to GLQuake, but different from Winquake where the position is higher on the screen. Second, the HUD is non-centered during DM games; this is the behavior in the released source code but not in the released binary version of Winquake. Attached a patch to workaround both issues (credit: Qrack code for weapon position adjustment). Also, attached a binary to test these two changes which are visible by default; this binary also has the mp3/ogg libraries statically built instead of as external library files (only SDL.dll is required which is in the archive). Static built by use of the codec libraries from Winquake-X and removing the *.dll.a files bundled with QS.

Attached two "waypoint" files for the excellent quake1 omicron bot, one for the e3m6 official ID map and the other for e4m3. Both maps are suitable for DM even if they are large in area, but e3m6 has armor and other items which are not reachable by the bots and cause them to pause in their navigation. The attached e3m6 waypoint file has these items removed** from the map so this problem is avoided. To activate these waypoint files for these two maps, first extract the original maps e3m6 and e4m3 from the quake 1 pak1.pak file (pakscape.exe has this capability), then use the commandline tool qbsp.exe to concatenate the attached waypoint files and the map files while all these files are in the same directory, like so:
qbsp -onlyents e3m6.ent
qbsp -onlyents e4m3.ent

The resulting bsp formatted map files are placed in the omicron directory under maps/. Omicron natively supports dm1-6 while external waypoint files are available and are activated as above. Tested in Winquake-Y and -X.

** Used trenchbroom v1.0.2 to identify the problematic entities and then a "plain text" editor to remove them from the map file (first used bsp2map to convert the original ID maps in bsp format to the map format).

leileilol wrote:

mr_bigmouth_502 wrote:

I wonder, could some of the game's software-only effects be replicated in hardware on modern graphics cards?

That's a question DirectQ answers with pixel shaders, but i think that's drifting far off the thread's subject

DirectQ at least has the same physics as vanilla Quake though, right? Or is it based on QuakeWorld like pretty much every other sourceport? 😵

Updated above QS-Test for recent release of of Cataractnacon (OMS3) map by "Orl". This updated QS-Test includes ericw's experimental branch of QS with tested enhancements for running OMS3 map; above QS_changes.diff applied to reposition weapon like Winquake; and a compact binary with mp3/ogg file-based music capability along with an already applied patch to revert a recent change to this feature (r1262_partial.diff; for ease of building this test binary only).

OMS3 map is available here:
http://qrf.servequake.com/~orl/oms3.zip
http://www.quaketastic.com/files/single_player/oms3.zip

Instructions in README of archive, but this is a summary of them:
1. Download oms3 map
2. Copy oms3.bsp and oms3_2.bsp to /Quake/Id1/maps/ directory
3. Copy QS-OMS3.exe and SDL.dll files from the attached archive to /Quake/ directory
4. Backup original autoexec.cfg and copy autoexec.cfg from attached archive to /Quake/Id1/ (only for OMS3, otherwise rename to autoexec_OMS3_cfg.)
5. Run QS-OMS3.exe to start game

Updated above QS-Test (ericw's experimental branch; r_1262_partial & QS_changes patches) with a patch for "contrast" levels to complement the "gamma" level. This code is derived from the RMQ engine.

Attached is a test build along with the "contrast" patch (gl_texturemode defaults to '3'). User accepts responsibility for use of the binary.

The Omicron bot (v1.20) is compatible with Quakespasm, but it may require selecting a new multiplayer game so that "maxplayers" is greater than 1, and it seems optional to change sv_protocol to 15 which corresponds to the original quake network protocol.

One issue is that this version of Omicron bot has two sound files which are essentially empty, dland2.wav and h2ohit1.wav. I presume these were added because these sounds did not fit well with the bot mod. However, Quakespasm will frequently warn about these sound files, so attached is a patch (QS-obot_warnings.diff) to optionally avoid these reports to the quake console. The quake 'cvar' parameter is "obot_sound_warning", where a value of 1 makes no modification and 0 avoids the warnings. The patch defaults to 0.

In rocketarena, the Omicron bot (v1.20) has an option to not load its player models and is selected by the commandline 'cvar' value: "registered 2". This works in vanilla Quake but does not in Quakespasm. Attached is a patch to restore this option.

If it's of interest:

Tested under Windows 98SE, with a Radeon 7000 w/ final drivers from ATI, DirectX 8.2.

Winquake-X and Winquake-Y both have distortion issues. (see attached).
Winquake-Z works okay (aside from lowish framerate), but the mouse pointer won't move from the center of the screen after exiting. Starting Winquake-X and exiting seems to fix it.