yquake2/yquake2remaster
0
0
Fork 0
mirror of https://github.com/yquake2/yquake2remaster.git synced 2024-11-21 20:21:09 +00:00
Code Issues Projects Releases Packages Wiki Activity

Mention the Vulkan renderer on all appropriate places.

Browse source
This commit is contained in:
Yamagi 2021-01-17 10:05:04 +01:00
parent a9914efde7
commit 531cbdcdae
4 changed files with 74 additions and 51 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

28
doc/020_installation.md
View file

@ -25,9 +25,9 @@ missing assets or even crashes.
The easiest way to install Yamagi Quake II is to start with the patch.
Please note that the patch is **required** for all full versions of the
game. Without the patch the game won't work correctly!
game. Without the patch the game will not work correctly!
1. Download the patch from our mirror or somewhere else. Its MD5
1. Download the patch from our mirror or somewhere else. The MD5
checksum is `490557d4a90ff346a175d865a2bade87`:
https://deponie.yamagi.org/quake2/idstuff/q2-3.20-x86-full-ctf.exe
2. Extract the patch into an empty directory. The patch comes as an
@ -78,7 +78,7 @@ The MD5 checksums of the pakfiles are:
The retail releases of Quake II and both addons contain up to 11 Audio
CD tracks as soundtrack. Since modern computers lack the ability for
direct CD playback Yamagi Quake II reads the music from OGG/Vorbis
direct CD playback, Yamagi Quake II reads the music from OGG/Vorbis
files.
Later Quake II releases, for example the one included with Quake IV and
@ -112,8 +112,9 @@ may be supported in the future.
An easy way to extract the music on unixoid platforms (BSD, Linux and
MacOS) is to use *stuff/cdripper.sh*, a simple shellscript. It needs
*cdparanoia* and *oggenc* (from the *vorbis-tools* package) installed.
Use the package manager (apt, dnf, homebrew, pkg, ...) to install them.
Just execute the script and copy the resulting *music/* directory to:
Use the package manager (apt, dnf, homebrew, pacman, pkg, ...) to
install them. Just execute the script and copy the resulting *music/*
directory to:
* *baseq2/* for Quake II.
* *xatrix/* for The Reckoning.
* *rogue/* for Ground Zero.
@ -129,7 +130,7 @@ just *music/*, next to *baseq2/*. **Not** inside *baseq2/*.
### Alternate Startup Configuration
Yamagi Quake II ships with an alternative startup config that overrides
some global settings to saner defaults. To use is copy *stuff/yq2.cfg*
some global settings to saner defaults. To use it copy *stuff/yq2.cfg*
into the *baseq2/* directory.
@ -219,8 +220,9 @@ To compile Yamagi Quake II from source the following dependencies
* A GCC compatible compiler like *gcc*, *clang* or *mingw*.
* A LibGL implementation with system headers.
* An OpenAL implementation, *openal-soft* is highly recommended.
* SDL 2.0.
* libcurl.
* SDL 2.0.
* Vulkan Headers version 1.2 or higher.
While Yamagi Quake II ships with an CMakeFile.txt using the GNU Makefile
for release builds is recommended. The GNU Makefile offers more options
@ -233,7 +235,7 @@ On Windows a MinGW environment is needed. A preconfigured environment
with all necessary dependencies and compatibles compilers can be found
at: https://deponie.yamagi.org/quake2/windows/buildenv/
The environment must be extracted into *C:\MSYS2\*. Other directores
The environment must be extracted into *C:\MSYS2*. Other directores
will likely work, but are unsupported. So don't complain if you
experience problems. Either the 32 bit version can be started through
*C:\MSYS2\msys32.exe* or the 64 bit version through
@ -247,11 +249,15 @@ Studio.
The build dependencies can be installed with:
* On Arch Linux based distributions: `pacman -S base-devel mesa openal
curl sdl2 vulkan-headers`
* On Debian based distributions: `apt install build-essential
libgl1-mesa-dev libsdl2-dev libopenal-dev libcurl4-openssl-dev`
* On FreeBSD: `pkg install gmake libGL sdl2 openal-soft curl`
libgl1-mesa-dev libsdl2-dev libopenal-dev libcurl4-openssl-dev
libvulkan-dev`
* On FreeBSD: `pkg install gmake libGL sdl2 openal-soft curl
vulkan-headers`
* On MacOS the dependencies can be installed with Homebrew (from
https://brew.sh): `brew install sdl2 openal-soft`
https://brew.sh): `brew install sdl2 openal-soft vulkan-headers`
Other distributions or platforms often have package named similar to the
Debian or FreeBSD packages.

47
doc/030_configuration.md
View file

@ -8,7 +8,7 @@ with the defaults and the options that can be set through the menu.
## Choosing a Renderer
Yamagi Quake II ships with 3 renderers:
Yamagi Quake II ships with 4 renderers:
* The **OpenGL 3.2** renderer: This renderer was developed for the needs
of modern graphics hardware and is usually the best choice for OpenGL
@ -20,16 +20,22 @@ Yamagi Quake II ships with 3 renderers:
* The **OpenGL 1.4** renderer: This is a slightly enhanced version of
the original OpenGL renderer shipped in 1997 with the retail release.
It's provided for older graphics cards, not able to run the OpenGL 3.2
renderer. The OpenGL 1.4 renderer has some limitations. The look and
feel is highly dependent on the GPU driver and the platforms OpenGL
implementation, especially the texture rendering may vary to a wide
margin. The global lighting may not be rendered correctly, especially
liquids may be too dark or too bright.
or Vulkan renderer. The OpenGL 1.4 renderer has some limitations. The
look and feel is highly dependent on the GPU driver and the platforms
OpenGL implementation, especially the texture rendering may vary to a
wide margin. The global lighting may not be rendered correctly,
especially liquids may be too dark or too bright.
* The **Software** renderer: Shipped for historical reasons only.
Setting the OpenGL 3.2 renderer to match the software renderers look
and feel is often the better choice, since it's faster and provides
colored lighting. The software renderer may show some rendering errors
on widescreen resolutions.
Setting the OpenGL 3.2 or Vulkan renderer to match the software
renderers look and feel is often the better choice, since it's faster
and provides colored lighting. The software renderer may show some
rendering errors on widescreen resolutions.
* The **Vulkan** renderer: The Vulkan renderer was ported from vkQuake2
to support plattform with no or bad OpenGL 3.2 support. Like the
OpenGL 3.2 renderer the look and feel is always the same, regardless
of the GPU driver. It's lightning rendering matches the OpenGL 1.4
renderer. Unlike the OpenGL renderers the underwater warp effect is
supported.
## Choosing a Sound System
@ -77,7 +83,8 @@ have the choice:
* Keep precise timings and the cost of a less accurate frame rate. With
this approach the timings are optimal, e.g. movement like strafejumps
and the clipping against walls are a precise as possible. But the
frame rate may be a little off, leading to tearing and missed frames.
frame rate may be a little off, leading to slight tearing and missed
frames.
The first approach is the default. To switch over to precise timing the
following console variables must be altered. There's no need to alter
@ -97,8 +104,8 @@ the GPU driver and the preferences of the player.
With `r_vsync` set to 1 that's the display refresh rate and otherwise
the value of `vid_maxfps`. Yamagi Quake II enforces this restriction
with an margin of 5%. For example, if `r_vsync` is set to 1 on an 60hz
display 60 * 0.95 = 57 FPS. if `cl_maxfps` is set too high (above 90)
the famous 125hz bug will trigger and the physics will be off. That
display 60 * 0.95 = 57 FPS. If `cl_maxfps` is set too high (above 90)
the infamous 125hz bug will trigger and the physics will be off. That
may be desired.
* `vid_displayrefreshrate` must be set to the framerate of the display.
The default is `-1` which means autodetect. In most cases that's okay,
@ -113,7 +120,8 @@ the GPU driver and the preferences of the player.
desired target frame rate.
Putting it all together we come up with three so to say standard
configurations that can be used as a baseline for experiments:
configurations that can be used as a baseline for experiments. For
a 60hz display:
* Precise frame rate and slightly imprecise timings:
* `busywait` set to `1`.
@ -217,8 +225,10 @@ support colored lighting.
General cvars:
* `cl_lights` set to `0` disables the dynamic lightning.
* `gl_texturemode` set to `GL_NEAREST_MIPMAP_LINEAR` disables the
* `cl_lights`: Set to `0` to disable the dynamic lightning.
Both OpenGL renderers:
* `gl_texturemode`: Set to `GL_NEAREST_MIPMAP_LINEAR` to disable the
texture filtering, giving a classic pixel look.
The OpenGL 1.4 renderer:
@ -232,6 +242,11 @@ The OpenGL 3.2 renderer:
* `gl3_particle_square`: When set to `1` the particles are rendered as
squares.
The Vulkanrenderer:
* `vk_pixelsize`: Pixelates the image, simulating a lower resolution.
* `vk_texturemode`: Set to `VK_MIPMAP_LINEAR` to disable the texture
filtering, giving a classic pixel look.
## Retexturing Packs

48
doc/040_cvarlist.md
View file

@ -32,6 +32,7 @@ are prefixed with a `+`, arguments are starting with a `-`. For example
it's `+set busywait 0` (setting the `busywait` cvar) and `-portable`
(setting the `portable` argument).
* **cfgdir**: The name (not the path) of the configuration directory.
* **datadir**: Directory from which the game data is loaded. Can be used
in startup scripts, to test binaries, etc. If not set, the directory
containing the binaries is used.
@ -97,8 +98,8 @@ it's `+set busywait 0` (setting the `busywait` cvar) and `-portable`
* **coop_pickup_weapons**: In coop a weapon can be picked up only once.
For example, if the player already has the shotgun they cannot pickup
a second shotgun found at a later time, thus not getting the ammo that
comes with it. This breaks the balacing. If set to `1` a weapon can be
picked up if a) the player doesn't have it or b) it wasn't already
comes with it. This breaks the balancing. If set to `1` a weapon can
be picked up if a) the player doesn't have it or b) it wasn't already
picked up by another player. Defaults to `1`.
* **coop_elevator_delay**: In coop it's often hard to get on the same
@ -170,16 +171,6 @@ it's `+set busywait 0` (setting the `busywait` cvar) and `-portable`
## Graphics (all renderers)
* **vid_displayrefreshrate**: Sets the displays refresh rate. The
default `-1` let the game determine the refresh rate automatically.
Often the default setting is okay, but some graphics drivers report
wrong refresh rates. For example 59hz are reported while the display
has 59.95hz.
* **vid_renderer**: Selects the renderer library. Possible options are
`gl1` (the default) for the old OpenGL 1.4 renderer, `gl3` for the new
OpenGL 3.2 renderer and `soft` for the software renderer.
* **cin_force43**: If set to `1` (the default) cinematics are displayed
with an aspect ratio of 4:3, regardless what the actual windows size
or resolution is.
@ -202,14 +193,6 @@ it's `+set busywait 0` (setting the `busywait` cvar) and `-portable`
to calculate an optimal horizontal and vertical field of view,
independent of the window or screen aspect ratio or resolution.
* **vid_gamma**: The value used for gamma correction. Higher values look
brighter. The OpenGL 1.4 and software renderers use "Hardware Gamma",
setting the Gamma of the whole screen to this value in realtime
(except on MacOS where it's applied to textures on load and thus needs
a `vid_restart` after changing). The OpenGL 3.2 renderer applies this
to the window in realtime via shaders (on all platforms). This is
also set by the brightness slider in the video menu.
* **r_consolescale** / **r_hudscale** / **r_menuscale** and
**crosshair_scale**: Scale the console, the HUD, the menu and the
crosshair. The value given is the scale factor, a factor of `1` means
@ -226,6 +209,24 @@ it's `+set busywait 0` (setting the `busywait` cvar) and `-portable`
to `1` the limit is increased to 8192 units. This helps with some
custom maps and is problematic with other custom maps.
* **r_vsync**: Enables the vsync: frames are synchronized with
display refresh rate, should (but doesn't always) prevent tearing.
Set to `1` for normal vsync and `2` for adaptive vsync.
* **vid_displayrefreshrate**: Sets the displays refresh rate. The
default `-1` let the game determine the refresh rate automatically.
Often the default setting is okay, but some graphics drivers report
wrong refresh rates. For example 59hz are reported while the display
has 59.95hz.
* **vid_gamma**: The value used for gamma correction. Higher values look
brighter. The OpenGL 1.4 and software renderers use "Hardware Gamma",
setting the Gamma of the whole screen to this value in realtime
(except on MacOS where it's applied to textures on load and thus needs
a `vid_restart` after changing). The OpenGL 3.2 and Vulkan renderers
apply this to the window in realtime via shaders (on all platforms).
This is also set by the brightness slider in the video menu.
* **vid_maxfps**: The maximum framerate, if `cl_async` is `1`. Otherwise
`cl_maxfps` is used as maximum framerate. See `cl_async` description
above for more information. *Note* that vsync (`r_vsync`) also
@ -233,9 +234,10 @@ it's `+set busywait 0` (setting the `busywait` cvar) and `-portable`
enabled, the game won't render more than frame than the display can
show.
* **r_vsync**: Enables the vsync: frames are synchronized with
display refresh rate, should (but doesn't always) prevent tearing.
Set to `1` for normal vsync and `2` for adaptive vsync.
* **vid_renderer**: Selects the renderer library. Possible options are
`gl1` (the default) for the old OpenGL 1.4 renderer, `gl3` for the new
OpenGL 3.2 renderer, `soft` for the software renderer and `vk` for the
Vulkan renderer.
## Graphics (GL renderers only)

2
doc/060_multiplayer.md
View file

@ -11,7 +11,7 @@ overflows, leading to all kinds of trouble.
This problem has always existed in Quake II and is not fixable (at least
not without breaking compatibility with the existing network protocol),
but back in Win9x days this was less of a problem because Windows
crashed frequently anyways and Win9x had the same bug and crashed after
crashed frequently anyways and Win9x had the same bug and crashed after
49 days or so...
Apart from this, we'll only document changes/additions here.