The sprname field of struct sprite_frame_t is supposed to contain the
four byte prefix for the sprite names, not an actual string with a
NULL byte delimiter.
This fixes a new compiler warning detected by @turol, fixes#1031.
Thanks @turol and @AXDOOMER for the discussion!
If game mode/mission don't match then the client can't connect to the
server. But give some details about the mismatch in the error message
to aid in debugging.
Thanks to AgitationSkeleton and GuyNamedErick for help with this.
Since we surface error messages in dialog boxes, it's important that
the full context of why a connection attempt was rejected is shown to
the user, otherwise it just appears as "failed to connect" with no
indication of why or how to fix the problem.
Thanks to AgitationSkeleton and GuyNamedErick for help identifying this
problem.
This check was designed to warn users if they did not have hardware
acceleration that performance might be poor and to suggest toggling
force_software_renderer. However the check is not reliable: it can't
determine whether hardware acceleration is taking place on Linux, as
Mesa front-ends both hardware and software implementations.
We explored alternatives (checking SDL_GL_ACCELERATED_VISUAL) but
these proved similarly unreliable.
On Linux, GLX offers glxIsDirect, but this is of no use where GLX
is not available, including (I think) Linux framebuffer or Wayland.
Rather than continue to mislead people, delete the test and warning.
Fixes#825.
Due to a misunderstanding of the rendering buffers, the prior commit
was a little pointless. To achieve the same effect, instead use
`max_scaling_buffer_pixels 64000` in the extra cfg.
This reverts commit f48bc14086.
Suggested by @vanfanel in #1009, nearest filtering can produce poor
results in low resolutions. Now, in the extra config file, scaling_filter
can be set to "linear" which normally results in Blur-O-Vision, but
might be desirable in low resolutions.
