As Jack Whitham noticed [0], animated textures freeze at their first
frame if they're on a transparent surface. This can be seen in base3
(Com Centre), for example. At least for the OpenGL renderer this is
caused by the fact that the animation chain is never forwarded if the
texture is bound to a transparent surface. The fix is to do exactly
that...
I can only speculate why the animations on transparent surfaces were
never used / implemented. Maybe performance issues or it was just
forgotten.
0: http://blog.jwhitham.org/2015/04/more-fun-with-floating-point-numbers.html
sounds easy, right?
Except some genius decided to save CVAR_LATCH cvars in buffers of
MAX_OSPATH length into savegames.. so just changing MAX_OSPATH
breaks savegame compatibility.
Fortunately, this assumption only matters in SV_WriteServerFile() and
SV_ReadServerFile() so I worked around it by introducing a
platform-specific LATCH_CVAR_SAVELENGTH (because MAX_OSPATH was 256 on
Windows but 128 on other systems..)
it's saved in $HOME/.yq2/$mod/history.txt
While I was at it, I made the max number of lines in the history
configurable at compiletime by introducing a NUM_KEY_LINES #define
See https://github.com/yquake2/yquake2/issues/71
and https://github.com/yquake2/xatrix/issues/4
In ClientThink(), the float value ent->velocity[i]*8 is saved into
a short and if the value is too big for a short, in 32bit gcc builds
the short is set to SHRT_MIN, resulting in the player being pressed
down instead of up.
Now we put the result in a 32bit int first (which should be big enough)
and assign the int to the short. This still overflows, but with -fwrapv
at least in a defined way (most probably the same way the original
binaries did).
And while I was at it, when the game lib is loaded, it prints the date
it was built, this is especially interesting for our Win32 binaries.
* remove link to our debian packages, we don't do that anymore
-> mention debian/ubuntu packages instead
* remove references to libjpeg, we don't use that anymore
* Link to retex pack was broken, replace with our mirror, mention that
the ones in models.zip suck
* Fix some typos
Daniel is more or less sure that a stuck Alt key can occure if the user
switches through several windows by Alt-Tab. That sounds resonable,
because the keyup event for Alt may happen when the focus is not on
Quake II. In that case SDL2 misses it and for Quake II the key stays
down. Solve this by capturing the focus loss event and mark all keys
as up.
It's apparently not enough to clear key repeats, we'll need to clear
the down states too. Without this Alt stays pressed after toggeling
fullscreen trhough Alt-Enter.
Switching to fullscreen through a SDL2 call is nice, but the renderer
needs to be reinitialized. Without it some things will break, for
example the gamma setting.
Deleted frameworks from inside the .app template.
Install them with home-brew before compiling:
libogg
libvorbis
libjpeg
openal-soft
sdl2
Note, current compilation is dynamic linking, so the end user will also
need these dependencies installed. Will change to static linking or
copying the libs into the .app through makefile in a future commit.
Unfortunately we can’t generate the whole .app in the makefile as we
are relying on a third party app for the game selector GUI. This could
be replaced in yquake2 code, but I don’t know ObjectiveC :O Maybe it’s
a good opportunity to learn.
Can now build a 32bit version.
Note that all your dependencies will also need to support 32-bit.
Install SDL2, libel, libvorbis, openal-soft in Homebrew using
‘--universal’ flag
No changes to source were needed, just to makefile.
The build process is now also different.
Frameworks are no longer needed, but you will need to get some packages
from Homebrew to compile.
Install homebrew, then get the following packages before compiling.
openal-soft
libogg
libvorbis
sdl2
No, this is not a rage quit but the result of a long discussion. There
are several reasons for us to drop OS X support:
- OS X support was always more or less hacky. For example is was never
really integrated into the build system and some features like the
OpenAL sound backend never worked well.
- The OS X support never grew into the new world based upon SDL2.
- It was broken since at least Lion which was released 4 years ago.
- None of the developers has a Mac or plans to buy one. Supporting
a software for a platform not used by the developers is more or
less impossible.
- And despite several appeals no one from the OS X community ever
stept up and send patches.
Removed are:
- Makefile support
- The OpenAL quirks
- The Cocoa bindings
- The framworks
Not removed is:
- Savegame support
- Memory management support
- Platform detection
- OpenGL and SDL includes
So, if someone steps up and does a modern, fully integrated port based
upon SDL2 we're happy to merge it back. The requirements are:
- It must be a clean port, without any hacks
- Full build system integration must be provided
- The port must be maintained even after it was merged. At every release
binaries must be build, API / ABI changes with new OS X versions must
be tracked.
Retexturing support is now always on (you can still switch it off with
the gl_retexturing CVAR), as we don't have the additional libjpeg
dependency anymore.
stb_image is used for tga, jpg and the newly supported png, so the
old tga and jpeg loading code has been removed.
I furthermore cleaned up the somehow messy and possibly slightly broken
retexturing selection code in R_FindImage()
Check and use GL_ARB_texture_non_power_of_two and use it if present to allow using all textures unscaled. This makes a huge visual improvement since most skins are not power-of-two textures.
Conflicts:
src/client/refresh/header/local.h
Okay, I tried to solve this issue the gentle way. But apparently it's
not enough to track if a key is down. We must consider if the key is
just down or if it's already repeating... Therefor raise the white flag
and just put the original logic back in place. This may fix issue #57.
When we're building command we must make sure, that all command for
one keystroke will have the timestamp in microseconds. If that's not
the case the command may end up in differend server frames, breaking
things subtile. This may be part of bug #57, but I'm not sure.
