- some reorganization of texture precaching so that the renderer can decide what to do with actors.
Just marking the sprite textures loses too much info if more is needed than just loading the images into memory.
Ideally the warping shouldn't be a property of the texture class itself but an effect processor that can get added to a texture. Unfortunately the current setup will not allow this, requiring some significant refactoring of texture access first.
The only reason this even existed was that ZDoom's original VC projects used __fastcall. The CMake generated project do not, they stick to __cdecl.
Since no performance gain can be seen by using __fastcall the best course of action is to just remove all traces of it from the source and forget that it ever existed.
- replaced some uses of FRACUNIT with OPAQUE when it was about translucency.
- simplified some overly complicated translucency multiplications in the SBARINFO code.
- Worked aorund modern GCC bug where C++ exceptions in Objective-C++ code would result in an ICE (bug is already on their tracker, but I doubt it will be fixed unless I decide to dig into the issue myself).
- Turn off fused floating point instructions since these can cause slight deviations in floating point code.
- Use -static-libgcc when compiling on the Mac with GCC since we need to use a custom version of GCC to do so now.
- Note: ZDoom will currently still crash on exit on PowerPC since it seems to be deciding that NameManager needs to be destructed before the console commands.
This was to resolve some circular dependencies with the portal code.
The most notable changees:
* FTextureID was moved from textures.h to doomtype.h because it is frequently needed in files that don't want to do anything with actual textures.
* split off the parts from p_maputl into a separate header.
* consolidated all blockmap related data into p_blockmap.h
* split off the polyobject parts into po_man.h
# Conflicts:
# src/CMakeLists.txt
# src/p_setup.cpp
# src/r_defs.h
# src/version.h
This only updates to a compileable state. The new portals are not yet functional in the hardware renderer because they require some refactoring in the data management first.
- For grayscale images drawn with the paletted renderer, the value here
was treated as always full range [0,65535]. The max value is actually
determined by the bit depth.
- For RGB images drawn with the paletted renderer, the tRNS chunk was
ignored.
- For grayscale images drawn with the RGB renderer, having a tRNS chunk
present resulted in undefined behavior.
- For RGB images drawn with the RGB renderer, the tRNS chunk was ignored.
