1 compiler error.
2 compiler warnings.
1 runtime warning.
Note that at this time, CPLUSPLUS=1 LUNATIC=1 fails to build due to C++ function mangling, and Win64 Lunatic crashes.
DONT_BUILD.
git-svn-id: https://svn.eduke32.com/eduke32@4540 1a8010ca-5511-0410-912e-c29ae57300e0
NOTE: changes such as these are best viewed with something like
git diff (...) --color-words='[a-zA-Z0-9_]+|[^[:space:]]'
git-svn-id: https://svn.eduke32.com/eduke32@3176 1a8010ca-5511-0410-912e-c29ae57300e0
This reverts r3159..r3161.
Conflicts:
eduke32/build/include/compat.h
(Handled so that r3163's changes are kept applied.)
git-svn-id: https://svn.eduke32.com/eduke32@3165 1a8010ca-5511-0410-912e-c29ae57300e0
I think there's also a fix for the CON precache system breakage in here (lost it in my local tree when I started getting the C++ build working in MSVC, sorry!)
git-svn-id: https://svn.eduke32.com/eduke32@3159 1a8010ca-5511-0410-912e-c29ae57300e0
The command-line utility can query and set the frame rate of IVF files, since
apparently encoders don't care too much about setting proper values in the IVF
header. Also, add the utility to the synthesis build.
On the playback side in EDuke32, get rid of the 1/(2*fps) "correction" if the
FPS numerator is <1000 (presumably used in older encoders) and properly print
the frame rate's fractional part.
git-svn-id: https://svn.eduke32.com/eduke32@3131 1a8010ca-5511-0410-912e-c29ae57300e0
Credit to Plagman for the idea and doing the work on the game side, which is included in this commit.
(Building as C++ will give us features with which we can make improvements and optimizations on the multiplayer code and Polymer.)
git-svn-id: https://svn.eduke32.com/eduke32@3116 1a8010ca-5511-0410-912e-c29ae57300e0
Currently, the FPS determination is based on libvpx's vpxdec.c code, which uses
the FPS provided in the IVF file in one case, and simply sets it to 30 FPS in
the other. For the first case, a "correction" is carried out for something
which the comments suggest to originate from other (old?) VPX encoder versions.
git-svn-id: https://svn.eduke32.com/eduke32@3110 1a8010ca-5511-0410-912e-c29ae57300e0
On an AMD Phenom II X4 system with generic memory modules, this brings down
the mean time for this conversion from 16.5 to 10.5 ms.
(GCC 4.6.1, optimized build)
git-svn-id: https://svn.eduke32.com/eduke32@2830 1a8010ca-5511-0410-912e-c29ae57300e0
the loop. For the release build and the test animation, this lowers the time
to 3-4 ms per conversion of one frame on my desktop machine.
git-svn-id: https://svn.eduke32.com/eduke32@2241 1a8010ca-5511-0410-912e-c29ae57300e0
three individual loops and compile the enclosing function at -O3 (-O1 for
debugging builds). Now, the time for this conversion ranges from 7 to 18
ms per frame across various tested machines, a clear improvement.
git-svn-id: https://svn.eduke32.com/eduke32@2042 1a8010ca-5511-0410-912e-c29ae57300e0
* New shade/visibility calculation code, which is activated with 'r_usenewshading' (on by default), and is closer to the classic look. Also tweak the FOGSCALE macro to have approximately the same fog distance with all renderers.
* Mapster32: END modifier to RShift. If it's pressed when RShift is released, sprites which are in grayed out sectors are also selected; Make changing shade affect all highlighted sprites in 3D mode (when aiming at one of them).
* some debug code to watch out for suspicious glGenTexture/glDeleteTextures calls, not active.
git-svn-id: https://svn.eduke32.com/eduke32@1943 1a8010ca-5511-0410-912e-c29ae57300e0
Usage: For an ANM file <somefile>.anm/ANM, EDuke32 looks for <somefile>.ivf, which is the VP8 stream transported by an IVF container. It can be extracted from a WebM file with e.g.
mkvextract tracks <filename>.webm 1:<filename>.ivf
(part of Mkvtoolnix, the Matroska toolset)
Libvpx is required, and the 'YUV'-->RGB conversion is implemented using a fragment shader, so it's for OpenGL modes only. Also, this commit doesn't enable the code.
Unfinished: sound, aspect correction for fullscreen w/ non-square pixels, ... ?
---
Make MAXNODESPERLINE in engine_priv.h actually a macro that depends on MAXYSAVES and MAXDIM instead of using the obsolete precomputed value. I think this might have been the cause for the latest patched-up overhead view crash.
git-svn-id: https://svn.eduke32.com/eduke32@1933 1a8010ca-5511-0410-912e-c29ae57300e0
