VOGONS


First post, by x86++

User metadata
Rank Newbie
Rank
Newbie

Winquake-X. Attached is Winquake-X, a derivative of the original Winquake with file-based music (tested with OGG), custom video resolutions at default video aspect (directx8), hor+ scaling, and inclusion of essential fixes only. This is a Quake engine; but it is not a "Fitzquake" derivative engine, also sometimes called a "modern quake engine" even though all Quake features and modifications are typically not supported.

Attached both the Winquake-X source code and a test binary. These are available for others' convenience, so the user takes full responsibility for running the binary and for any editing of code.

Instructions on use
To customize the video resolution, modify lines in the config.cfg; for example:
vid_config_y "400"
vid_config_x "1020"

Other settings
fov_adapt (hor+), scr_centersbar (affects HUD in netplay), m_look

Music files are copied to MUSIC subdirectory under the ID1 directory (the game directory in the case of Quake 1 and its music). The console commands are: music, music_pause, music_resume, music_loop, music_stop.

For example:
music track01
music_pause
music_resume

Thanks to other authors: uhexen2 for file-based music and hor+ scaling code; MH and qbism for directx video code; and Id for releasing the source code to their game engine.

Optional build instructions
Winquake-X builds with mingw32/gcc. If the directx headers/libraries are not in searchable paths recognized by the compiler/linker, then the makefile has examples to add additional paths to directories where the files are located.

*************************************************

Winquake-Y. Also attached is Winquake-Y (both source code and binary). This different version has the above features and disclaimer, but it is not based on the original Winquake. Instead, it is based on "glquakebjp" by Bengt Jardrup, and contains extensive improvements to the original Winquake engine, including increased map-related limits so that specially designed large maps will load (this is specific to the BSP file format for Quake 1).
***

Attachments

  • Filename
    Winquake-X.zip
    File size
    360.7 KiB
    Downloads
    402 downloads
    File comment
    Winquake-X binary
    File license
    Fair use/fair dealing exception
  • Filename
    src_wq-X.zip
    File size
    1.16 MiB
    Downloads
    205 downloads
    File comment
    source code to build Winquake-X
    File license
    Fair use/fair dealing exception
  • Filename
    Winquake-Y.zip
    File size
    381.54 KiB
    Downloads
    264 downloads
    File comment
    Winquake-Y binary
    File license
    Fair use/fair dealing exception
  • Filename
    src_wq-Y.zip
    File size
    1.19 MiB
    Downloads
    174 downloads
    File comment
    source code to build Winquake-Y
    File license
    Fair use/fair dealing exception

Reply 1 of 17, by x86++

User metadata
Rank Newbie
Rank
Newbie

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.

Attachments

  • Filename
    Winquake-Z.zip
    File size
    490.02 KiB
    Downloads
    282 downloads
    File comment
    Winquake-Z binary
    File license
    Fair use/fair dealing exception
  • Filename
    WQ-X-Z-src.diff
    File size
    38.88 KiB
    Downloads
    177 downloads
    File comment
    Patch to build Winquake-Z from Winquake-X (SDL library not included)
    File license
    Fair use/fair dealing exception

Reply 2 of 17, by leileilol

User metadata
Rank l33t++
Rank
l33t++

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.

apsosig.png
long live PCem

Reply 3 of 17, by x86++

User metadata
Rank Newbie
Rank
Newbie

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.

Reply 4 of 17, by leileilol

User metadata
Rank l33t++
Rank
l33t++

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

apsosig.png
long live PCem

Reply 5 of 17, by x86++

User metadata
Rank Newbie
Rank
Newbie

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.

Reply 6 of 17, by mr_bigmouth_502

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 7 of 17, by leileilol

User metadata
Rank l33t++
Rank
l33t++

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????"

apsosig.png
long live PCem

Reply 8 of 17, by mr_bigmouth_502

User metadata
Rank Oldbie
Rank
Oldbie
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?

Reply 9 of 17, by leileilol

User metadata
Rank l33t++
Rank
l33t++
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

apsosig.png
long live PCem

Reply 10 of 17, by x86++

User metadata
Rank Newbie
Rank
Newbie

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.

Attachments

  • Filename
    QS-Test.zip
    File size
    569.75 KiB
    Downloads
    146 downloads
    File comment
    QS test binary
    File license
    Fair use/fair dealing exception
  • Filename
    QS_changes.diff
    File size
    4.38 KiB
    Downloads
    147 downloads
    File comment
    QS patch (r1256) for above modifcations
    File license
    Fair use/fair dealing exception

Reply 11 of 17, by x86++

User metadata
Rank Newbie
Rank
Newbie

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).

Attachments

  • Filename
    omicron-e3m6-e4m3.zip
    File size
    17 KiB
    Downloads
    125 downloads
    File comment
    Omicron waypoints e3m6 and e4m3
    File license
    Fair use/fair dealing exception

Reply 12 of 17, by mr_bigmouth_502

User metadata
Rank Oldbie
Rank
Oldbie
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? 😵

Reply 13 of 17, by x86++

User metadata
Rank Newbie
Rank
Newbie

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

Attachments

  • Filename
    QS-OMS3-Test.zip
    File size
    580.8 KiB
    Downloads
    134 downloads
    File comment
    QS-OMS3-Test binary
    File license
    Fair use/fair dealing exception

Reply 14 of 17, by x86++

User metadata
Rank Newbie
Rank
Newbie

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.

Attachments

  • Filename
    QS-Contrast-Test.zip
    File size
    573.07 KiB
    Downloads
    126 downloads
    File comment
    QS-Contrast-Test.zip
    File license
    Fair use/fair dealing exception

Reply 15 of 17, by x86++

User metadata
Rank Newbie
Rank
Newbie

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.

Attachments

  • Filename
    QS-obot_warnings.diff
    File size
    1.92 KiB
    Downloads
    130 downloads
    File comment
    QS patch for Omicron bot
    File license
    Fair use/fair dealing exception

Reply 16 of 17, by x86++

User metadata
Rank Newbie
Rank
Newbie

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.

Attachments

  • Filename
    QS-obot_registered.diff
    File size
    1.01 KiB
    Downloads
    123 downloads
    File comment
    QS patch #2 for Omicron bot
    File license
    Fair use/fair dealing exception

Reply 17 of 17, by aka286dos

User metadata
Rank Newbie
Rank
Newbie

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.

Attachments

  • winquake-x.png
    Filename
    winquake-x.png
    File size
    263.39 KiB
    Views
    3013 views
    File license
    Fair use/fair dealing exception