which just called R_PolyBlend().. no idea what that all was about..
and no idea why it happend in 3D mode, it's much easier after
SetGL2D(), then it can share code with GL3_Draw_FadeScreen() and doesn't
need any additional messing with transformation matrices
* The particles look more fuzzy than in old renderer - I think it looks
better this way ;)
* Not sure I keep the way they're rendered - instead of calculating and
passing the distance in GL3_ShutdownShaders() I could set the player
(camera) origin in a UBO and calculate distance (and based on that
the size) in the vertex shader. I could also pass the basic point size
via UBO, it's the same for all particles..
* Deleting shader programs is a lot shorter now and using a loop and
the fact that consecutive fields of the same type in a struct have
the same memory layout as an array of that type.
Now I can just add a gl3ShaderInfo_t to gl3state, set it up in
GL3_InitShaders() and don't have to add anything to
GL3_ShutdownShaders() (this is good, I forgot that all the time and
didn't notice, as it doesn't cause visible errors)
* Of course the color attribute has 4 floats, not 2..
* I read that updating UBOs with glBufferData() is kinda slow.
I didn't change that (yet), but at least all three GL3_UpdateUBO*()
functions now call updateUBO() which can easily be changed to do
whatever is best without touching the other three functions.
* When using gl_pointparameters, the particles always had the same size
regardless of resolution, i.e. they look bigger (use bigger part of
screen) at lower resolutions. Now I scale gl_particle_size according
to the resolution, assuming the configured size looks good at 800x600
(or generally 600px vertical)
* When not using gl_pointparameters, a textured triangle is rendered.
The texture had a resolution of 8x8 pixels and looked like a cross,
now it's 16x16 and has rounded ages, looking more like a circle.
So particles with "gl_pointparameters 0" should look much better now.
turns out R_MYgluPerspective() was not the same as gluPerspective()
and thus not equivalent to HMM_Perspective() either. Because of this,
the weapon and corresponding arm looked different in GL3 vs GL1.
Created GL3_MYgluPerspective() to fix that.
Also tested optimized code in GL3_RotateForEntity() and
rotAroundAxisZYX(), use this code from now on and cleaned it all up by
removing commented out code.
that was easy..
however, not related to this change or left vs right hand, the gun
seems to be drawn too far back, we should see more of the arm..
I wonder where that went wrong...
introducing vertex color attributes GL3_ATTRIB_COLOR (it's used for
lighting models and to render models flat-colored, I think that's used
for quad damage effect and similar)
kind of messy commit with all the shit from last weekend, finished now
Most importantly the common vertex attribute layout stuff using
glBindAttribLocation()
still no 3D rendering, but in theory it should be able to load models,
bsps etc, just not render them yet.
also moved/copied md2.c and sp2.c to gl/ and gl3/ because they use
renderer-specific types
only for 2D rendering, as we don't have 3D yet; also this might need
a more flexible solution later, as some textures are not supposed to
have intensity applied.
According to the old R_Upload32*() and R_LightScaleTexture() the ones
without mipmaps didn't get intensity. Those were it_pic and it_sky (and
the ones in the "scrap", but those were it_pic too)
when called from R_FindImage() the palette wasn't used anyway.
R_FindImage() now passes NULL.
(LoadPCX() is still called with non-NULL palette from Draw_GetPalette())
the arguments were not used anyway, and returning true/false is clearer
than returning -1 (for error) or sth else (which has no deeper meaning
anyway).
Also:
* PrepareForWindow() can now return -1 if there's an error
* suppress some warnings in Makefile
* fix error for building ref_gl.dylib on OSX
So in all code in the reflib (ref_gl.dll/.so/.dylib) calls to
ri.Con_Printf(print_level, fmt, ...) have been replaced by calls to
R_Printf(print_level, fmt, ...) which uses ri.Com_VPrintf().
somehow all the printf()-like things in Q2 wrap each other and each
one prints into a buffer and then calls the next one with ("%s", buf).
That's not very clever and kinda annoying.
As in the end everyone calls Com_Printf() I created Com_VPrintf()
that can be called instead with the va_list.
I also added printf-format annotation to Com_Printf() and Com_DPrintf()
and fixed places where Com_Printf() was called with the wrong type.
and the changes in the including files for this.
(also removed gl.h includes from local.h, as it's already included in
qgl.h which is included by local.h)
Repeat 10 times:
- strcat() is evil
- strcat() is evil
...
While here fix another small inconsistency: Vorbis playback should
stop when switching 'shuffle' on.
The overflow was reported by @tomgreen66 in pull request #168.
Until now autoexec.cfg was a special case. It was read several
times, whenever the 'game' cvar was altered or when the client was
restarted. But only if it was in the right directory in the right
position of the internal search path... Remove this altogether and
replace it by an ordinary 'exec autoexec.cfg' at startup.
This may break some mods that depend on an autoexec.cfg if the user has
his own version in ~/.yq2/. Such mods should use default.cfg instead.
This closes issue #163.
Multitexturing was never part of any official Quake II release. It was
added in version 3.21, which was released only in source. Over the years
many developers tried to fix multitexturing, including myself. Yamagi
Quake II had it even enabled by default for several releases... But:
* Multitexturing is poorly implemented and **slow**
* Multitexturing leads to render errors, for example in city3
* Multitextring is ortogonal to the normal render path and adds a
lot of special cases to the renderer
Remove it for good. Ciao, it wasn't a nice time. :) The last version
before this commit was at least somewhat fixed, read some of the worst
problems were fixed. If someone's ever going to resurrect it, it would
be a good idea to start at that point.
Otherwise at least one key may be still marked as down causing an
immediate abort of playback. While here be a little bit paranoid
and clean up key states when focus is gained. In theory that's a
no-op.
When the video is scaled through OpenGL we can just throw it on our
vertexes and everything's alright. But when we're softscaling the video
we must consider that the videos size doesn't really match the vertex
size...
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.
