especially in the intermission videos, the text looked broken, as parts
of the characters were missing.
This is because Draw_StretchRaw() converts the 320x240 video frame into
a 256x256 texture, without doing proper interpolation (just skipping
some pixels instead).
Now, if the GPU supports non-power-of-two texture sizes, the video
frames are uploaded as textures in their original size.
(Also fixed a harmless typo in common.h)
The original client crashed (or survived by pure luck) when muzzle
flash offsets >210 were send. Our fix was to bail out, but that broke
some buggy mods... So just return and print an optional debug message.
This fixes issue #153.
This step height is used by several evelators, leading to stuttering due
to misspredictions. Additionally half height steps weren't smoothed by
the synchronous client.
Predicting these steps leads to a heavily stuttering elevator in
hangar1. I think that steps between 94 and 98 can't appear on stairs, so
just remove them. If I'm wrong we need a hack to the hack ontop of the
hack... ^^
This fixes#119. As always I've chosen the least invasive way to solve
this problem. Trying to open players/$model/trix.md2 is hack, but solves
the problem without changes to filesystem.c and it's API.
With vsync enabled the render times of consecutive frames can diverge.
The first frame arrives right at the next display frame and is rendered
without waiting time. The next frame has to wait 20ms. The leads to some
problems with the move prediction if the client is asynchronous. Fix
this by capping the desired frame rate at the display refresh rate. Also
make sure that the network framerate is never higher then the renderer
framerate.
With the commit the timing is always correct:
* With no limit as much frames as possible are rendered. In this case
rfps > nfps and everything's good.
* With vsync enabled rfps > nfps or rfps == nfps is given. Also rfps
will never exceed the display refresh rate.
* On slow hardware either rfps > nfps or an implicit rfpc == nfps is
given.
While the bugfix in a6f4a3b made the steping prediction working for
stairs, elevators are still stuttering. r1q2s code solves this problem
and is a little bit faster. Use it instead.
Yesterday I chose setting cl_async to 0 since I saw some movement
changed with the async client enabled. Especially when clipping against
bevels the game started to stutter and there were small rendering
problems. After some debugging I realized that it is caused by slight
inaccuracies in the move prediction. When cl_maxfps is too low, the
movement error between two render frames becomes to big, leading to
misspositions. There're two ways to solve this problem:
* Processing more client frames. Most async clients I've looked on
process 60 or even 90 render frames. I chose to stay at 60 since
I was unable to see differences with higher rates.
* Changed to pmove.c and the pmove_t struct. Some multiplayer focused
clients go that way. But there's a very high of breaking singleplayer
movement and pmove_t is part of the server <-> game API. Additionally
the network code must / should be altered. So this is unsuitable for
YQ2.
Please note that there's still a change in movement. Before 4ae8706 and
when cl_async is set to 0 movement is dependend on the render framerate.
At low framerate bevel clipping isn't working too good, at high
framerates prediction causes physics changes like the famous 125hz bug.
With cl_async set to 1 the network framerate is stable, leading to a
more consistant behahiour.
Most (all?) clients implement the synchronous and the asynchronous
client by seperate code pathes. Instead of doing that we force the
asynchronous path to process one network frame for each render frame.
We're missusing the current frame to pass data from the input subsystem
to the movement prediction without a server frame. While we can use the
current frame for the movements itself, it's not finished and thus
unsuitable for stair step prediction. Also oldframe is determined
wrongly. As a result the player "jumps" over stairs.
This is a slighty revised version of id Software original code. Icculus
code may have some advantages on broken drivers or underpowered GPUs.
Today it's just a performance hook. This is a first step in fixing #147.
This is more than enough for everyone and prevents wasting CPU time.
Without this change as many client frames as possible are rendered,
Quake II uses a complete core.
This is based on work submitted by Scott "pickle" Smith. It's said that
vertex arrays are somewhat faster and more compatible than the old way.
This may remove support of some very, very old GPUs like the Riva128.
This is more less cosmetics since gl_tex_solid_format == GL_RGB and
GL_LIGHTMAP_FORMAT == GL_RGBA. No measurable FPS change on Nvidia and
Intel. Based upon the OpenGL ES patch by Scott "pickle" Smith.
This is based upon the original OpenGL ES patch by Scott "pickle"
Smith. This change gives about the same frame rate on an 750TI but
about 3% more frames on an Ivy Bridge IGP with Mesa3D...
This is largely based upon the cl_async 1 mode from KMQuake2, which in
turn is based upon r1q2. The origins of this code may be even older...
Different to KMQuake2 the asynchonous mode is not optional, the client
is always asynchonous. Since we're mainly integrating this rather
fundamental change to simplify the complex internal timing between
client, server and refresh, there's no point in keeping it optional.
The old cl_maxfps cvar controls the network frames. 30 frames should be
enough, even Q3A hasn't more. The new gl_maxfps cvar controls the render
frames. It's set to 95 fps by default to avoid possible remnant of the
famous 125hz bug.
I'm not quite sure if this really makes a difference. But it's the only
idea I have regarding several "Quake II hangs at shutdown when OpenAL is
run with Pulseaudio backend" bugs.
Hardware gamma is broken, especially in fullscreen, and a Mac user told me
that setting HW/screen gamma on OSX is a bad idea anyway, because it resets
the monitor calibration.
The game /should/ look ok with vid_gamma 1 (if your display is configured
properly), but if you think it's too dark set it a bit higher and do
vid_restart.
Multitexturing was enabled by default in 0f7b422. It gives a small but
on todays hardware neglectable performance boost, but caused several
problems over the years. For example gl_showtris doesn't work with it
and there's at least one render glitch in city3.bsp.
turns out the if the console is opened while no game is currently
running, cls.key_dest is not key_console but still key_game.
Changing it to key_console in those cases blows up in interesting ways.
So in Char_Event() we send events to the console in those cases.
This clamps the UI scale, limiting the relative size of the UI
elements to what they would be at scale 1 in a 320x240 resolution.
Allowing bigger scales is not useful, and would make it possible
for the user to shoot him-/herself in the foot by setting a
"too big" UI scale value in the menu. (Since this would mess up
the menu, it could be hard te recover from for a casual user.)
AL_PlayChannel() is only called by AL_AddLoopSounds() and
S_IssuePlaysound() - but only the latter set a volume there.
Because of that, loopsounds weren't hearable anymore after the last
commit which removed adding s_volume to all volumes in AL_PlayChannel().
This is fixed by setting the volume for looped sounds in
AL_AddLoopSounds() as well.
Looped sounds don't seem to have a customizable volume and are always
played at full volume (the volume is only changed by distance, but
OpenAL does that automatically).
The CD music enable / disable box wasn't used by many users for two
reasons: CD music playback needs a CDROM drive with analog output.
Such drives aren't available for at least 10 years. And CD music is
unsupported with SDL2. A OGG volume slider is much more usefull.
Con_DrawConsole() assumed that the version string was always 21chars
long, we changed it to allow longer strings with other lenghts.
In Unix main() we changed the code for underlining
"Yamagi Quake II $version" with === so the underlining is as long
as the underlined string.
Moving the check under the "do we have the file localy" check prevents
spurious "Refusing to download a path with .." messages with some game
data. The tank commander skin is one example. This change has no
security impact since FS_LoadFile() just opens and closes the file.
While at it tighten the condition to prevent pathes with colons (this
condition is added at the server side, too) and pathes starting with
slashes and dots.
When the keypad was activated key presses were processed twice.
Once as a normal char event and once as a key event (not marked
as special). The key event to console character translation
function turned the key event into a second character...
The savegame list is generated by calling FS_FOpenFile() for each
possible savegame name. When a file handle is returned the savegame
exists, otherwise the savegame slot is empty. But FS_FOpenFile()
searches in every directory known to the VFS. If a savegame file
isn't found in $moddir but in baseq2, the file in baseq2 is opened
and a baseq2 savegame is displayed in the mods / addons savegame menu.
The fix is compromise between a clean solution and invasiveness:
- Refactor FS_FOpenFile() to include FS_FOpenFileRead(). FS_FOpenFile()
was used only to open read only files, limit its's possibilities to
do exactly that.
- Introduce a new flag "gamedir_only" to FS_FOpenFile(). When true
only the gamedir directories are searched and not other directories
like baseq2.
- Change all callers to FS_FOpenFile()s new signature.
- Use the new gamedir_only flag to limit the searchpath for savegames
to the gamedir.
