Using global variables for this is bad, and it didn't even catch all cases. Now a node build is only considered successful if everything is set up successfully.
# Conflicts:
# src/maploader/maploader.cpp
src/scripting/decorate/thingdef_parse.cpp:80:11: error: no viable conversion from 'const FName' to 'FString'
src/scripting/zscript/zcc_compile.cpp:1359:26: error: use of undeclared identifier 'Name_globalfreeze'; did you mean 'NAME_globalfreeze'?
# Conflicts:
# src/scripting/zscript/zcc_compile.cpp
They are intentionally omitted from both MAPINFO and compatibility settings.
This removes the last place where it still went through the map-modified versions of the compatflags.
# Conflicts:
# src/s_sound.cpp
This was yet another piece of code that lived or died with the assumption that there can only be one level, stored in global variables.
# Conflicts:
# src/p_saveg.cpp
- It was calling the fallback aiming in the wrong place when it should have been outside the speed check.
- Credit to _mental_ for the base code, but no gotos involved.
There are several places where a temporary change of light mode is needed, all these made this change in the global level struct. Now the change is only local to the active draw info.
If we ever want to refactor the global level data these must not reference the 'level' variable.
The main parts of the map loader cannot use this information, because it can only be created after running the node builder, so it got its own set of index functions instead.
Visual C++ will never statically initialize a class instance where a member field has a default value set, so the DEFINE_ACTION_FUNCTION variants without a direct native call need to be handled differently. The easiest way to do this is to leave out the nullptr default and omit the value in the initializer list. For trailing fields this will always get them nulled.
Also tried to sort them by renderer use but that turned out to be without any performance effect, even though the struct is a bit better aligned now and several bytes shorter.
I have to wonder why it had to use such a complicated implementation that provided no advantages whatsoever.
The new code is just 1/5th of the old one's size and much closer to Hexen's original implementation which also was a simple array but with no means to resize the queue.
This involves passing the level explicitly to many functions. What was done here may seem a bit excessive but at least it covers everything.
Most importantly, the global ActiveThinker pointer has been moved into FLevelLocals and is now getting tracked properly by the level without using dangerous assumptions about how the game organizes its data.
- upload only the dynamic AABB subtree using glBufferSubData
- change internal raytracing stack limit from 16 to 32
- update shadowmap AABB tree after R_SetupFrame for proper frame interpolation
Unlike the other classes, the places where variables from this class were accessed were quite scattered so there isn't much scriptified code. Instead, most of these places are now using the script variable access methods.
This was the last remaining subclass of AActor, meaning that class Actor can now be opened for user-side extensions.
This was the only code using the ViewBob member variable.
This also moves the range check for this variable to its application, because a badly behaved mod can just as easily change it at run time instead of just setting an absurdly large value in the class definition.
Since these can be changed on the placed light actor they have to be read from there, so this is now a pointer in FDynamicLight, just like the other properties that can be user-changed.
Also did some cleanup on the interface so that external code doesn't need to dereference the lightflags pointer but can use utility functions for all flags.
backtrace functions are not present in all libc implementations. Cmake has
module to add external libraries into build if needed so use it to fix build on
Unix systems without backtrace in libc.
ReadString allocates a buffer, so saving it in a local variable and then forgetting it will not free the buffer afterward.
(This should probably be refactored to use some safer methods to read the string than this old-school method...)
This should be less of a drag on the playsim than having each light a separate actor. A quick check with ZDCMP2 showed that the light processing time was reduced to 1/3rd from 0.5 ms to 0.17 ms per tic.
It's also one native actor class less.
Since the SpawnedThings array is still available when polyobjects are spawned it makes no sense to create an expensive linked list in P_SpawnMapThing.
This can be done far better by scanning through the array again and collect all matching items in a second array.
This thing made sense when GZDoom and ZDoom were separate projects to avoid having to change some core files for the added options.
Now, with only 3 ones remaining, one for FraggleScript and two for Extradata the overhead here is just too high. The 3 variables can just be moved to level_info_t without carrying along this much baggage.
Since actors are being spawned before the renderer gets set up this needs to fully initialize the list before spawning the actors, then take it down again for creating the vertex buffer and then recreate it.
Add 'useowncoloradd_{top,mid,bottom}' sidedef properties to the UDMF
spec
Only use side's additive colors if 'useowncoloradd_(top|mid|bottom)' is
set.
Rename UseOwnColors flag to UseOwnSpecialColors
Add UseOwnAdditiveColor flag to side_t::part
Add EnableAdditiveColor to side_t
Add Side.EnableAdditiveColor to ZScript API
Sector.SetAdditiveColor actually called Sector.SetSpecialColor
Add use boolean property, used to determine whether or not to override the sector's additive wall colour with the side's additive colour.
The new specification is more flexible, and allows assigning additive
colors to individual parts of a sector (walls, sprites, flats) and even
individual parts of a side (top, middle, bottom)
Add AdditiveColors arrays to sector_t and side_t::part
Initialize AdditiveColors arrays to 0
Export AdditiveColors to ZScript
Save AdditiveColors in saved game files
Use colors from AdditiveColors arrays when setting the additive color
for the render state
Add code to parse the new UDMF additive color properties
Remove additive color slot from sector color/part enum
Add SetAdditiveColor to sector_t and side_t
Add GetAdditiveColor to side_t
Export new methods and additive color arrays to ZScript
Rename ColorAdd to AddColor
Add AddColor to FRenderState
Tweak SpecialColors array in ZScript to include the additive color
Add uAddColor to the shader compiler
Add uAddColor to the texel
- TriggerPainChance(Name mod, bool forcedPain)
- One exception: PainThrehold is only checked in ReactToDamage, since this function does not require checking damage amount.
- Split off all reactive functionality (pain, infighting, etc) into its own function, ReactToDamage.
- Refactored all DamageMobj's damage <= 0 values.
- Any unconditional cancellations now return -1. ReactToDamage will not be called if values < 0.
- All pain/wound/target changing allowances return 0.
NOFRICTION disables all friction effects on the thing it's set on
(including the speed cap from water/crouching), and NOFRICTIONBOUNCE
disables the "bounce off walls on an icy floor" effect on the thing
it's set on.
This did no longer sort sprites in the same position reliably since the feature to render sprites which only partially are inside a sector was added.
With this, sprites in the same position are no longer guaranteed to be added to the render list in sequence.
Fixed by adding an 'order' field to AActor which gets incremented with each spawned actor and reset when a new level is started.
The software renderer will also need a variation of this fix but its data no longer has access to the defining actor when being sorted, so a bit more work is needed here.
Changed to use 32 bit and also fixed the random number call which was using the byte value variant of the access operator, effectively limiting the number of choices to 256.
Since this deletes the resolved elements one by one and needs to start at the front to ensure consistency, it is better to reverse the order so that the deletions take place at the end of the list which requires a lot less data movement.
On Total Chaos this slowed down texture setup to the point where the mod was basically unlaunchable.
The mod which prompted me to add this is "The Chosen" which is a Dehacked-based TC and repurposes many original actors for something entirely different.
The stock lights are not usable for this and would make it impossible to add a GAMEINFO lump to it because then there is no way to disable loading of lights in the startup screen.
Making callstack resolving operational will require a little bit more effort
src/scripting/vm/jit_runtime.cpp:900:31: error: use of undeclared identifier 'frames'
src/scripting/vm/jit_runtime.cpp:903:23: error: use of undeclared identifier 'cnt'
The ZScript DrawChar function was incomplete and FFont::GetChar did not always return the proper texture.
To make things clearer the OriginalPic is now only used in the few cases where substitution takes place and nothing else.
Since unfortunately this cannot be set as a general default, let's at least make it as easy as possible to disable that panning+scaling madness without having to edit the texture data.
Since the entire font setup is very much incapable of handling this during rendering, short of a complete rewrite, it was necessary to put the relevant code into the places which process the characters for drawing so that it can disable the translation table (which needs to be passed as raw data to the draw functions) and keep track of both the translatable and the original variant of the character graphics.
This particular case incorrectly factored in the sidedef's scaling factor for how to calculate the offset.
Fortunately this is a very rare case - a quick check yielded no maps depending on it.
Should any map surface that depends on this bug a compatibility option may be needed but it doesn't seem likely that this may be the case.
This particular case incorrectly factored in the sidedef's scaling factor for how to calculate the offset.
Fortunately this is a very rare case - a quick check yielded no maps depending on it.
Should any map surface that depends on this bug a compatibility option may be needed but it doesn't seem likely that this may be the case.
Between creation and resolving the texture manager will resort the textures and after that the old ids are no longer valid. The textures themselves have the correct one, so that should be used.
This was leaking memory with being handled like a regular image texture and also would prevent further changes to the in-game texture handling because the savegame picture was imposing some limitations on FPNGTexture's implementation
This is essentially a stripped down version of FHardwareTexture, which can exist on the API independent size, and which stores pointers to hardware textures instead of OpenGL texture handles.
For ad-hoc Dehacked state functions no ArgFlags are created, in this case they can just be assumed to not be relevant here, because none of these function produces reference arguments.
Initially, settings controller flag was false by default
It was not touched during construction and destruction of player_t instances though
Now, with all members initialized in class definition, this flag must be saved and restored manually
https://forum.zdoom.org/viewtopic.php?t=62830
FDummyTexture had a big problem: Whenever it was accessed by accident it crashed the app because it wasn't fully implemented.
What it should do is return empty pixels of the given size, and an unextended FImageTexture is doing just that.
This will mostly ensure that each patch used for composition is only loaded once and automatically unloaded once no longer needed.
So far only for paletted rendering, but the same logic can be used for true color as well.
* split up FMultiPatchTexture into a builder class and the actual image source.
* since images can now be referenced by multiple textures the old redirection mechanism has been removed. It can be done better and less intrusive now. Simple single patch textures already directly reference the underlying patch image now.
* allocate all image source related data from a memory arena. Since this is all static this makes it a lot easier to free this in bulk.
In ZDoom this would affect everything using a patch that got used in a front sky layer, even if the texture was totally unrelated. It is only owed to the low usability of such patches for other purposes that this hasn't caused problems.
Previously it tried to copy all patches of composite sub-images directly onto the main image.
This caused massive complications throughout the entire true color texture code and made any attempt of caching the source data for composition next to impossible because the entire composition process operated on the raw data read from the texture and not some cacheable image. While this may cause more pixel data to be processed, this will be easily offset by being able to reuse patches for multiple textures, once a caching system is in place, which even for the IWADs happens quite frequently.
Removing the now unneeded arguments from the implementation also makes things a lot easier to handle.
* it's no longer the main texture objects managing the pixel buffer but FSoftwareTexture.
* create proper spans for true color textures. The paletted spans only match if the image does not have any translucent pixels.
* create proper warp textures instead of working off the paletted variants.
As a side effect, caching of pixel buffers for texture composition is temporarily disabled, as it management of texture redirections. These things will be reimplemented once things progress further. The existing methods here had their share of serious issues that should be fixed.
This was done to make reviewing easier, again because it is virtually impossible to search for the operators in the code.
Going through this revealed quite a few places where texture animations were on but shouldn't and even more places that did not check PASLVERS, although they were preparing some paletted rendering.
This class has only meaning for software-based warping so it doesn't have to be a part of the FTexture hierarchy.
Making it a subclass of FSoftwareTexture is fully sufficient.
As a bonus this already fixes several bugs caused by the botched texture scaling implementation the original texture manager came with.
System cursors are currently disabled because they rely on functionality that needs to be moved to different classes.
- disallow bool as a return value for direct native calls because it only sets the lowest 8 bits of the return register.
- changed return type for several functions from bool to int where the return type was the only thing blocking use as direct native call.
CMakeFiles/zdoom.dir/r_utility.cpp.o: In function `R_SetupFrame(FRenderViewpoint&, FViewWindow&, AActor*)':
/home/travis/build/coelckers/gzdoom/src/r_utility.cpp:832: undefined reference to `AActor::GetCameraHeight() const'
CMakeFiles/zdoom.dir/g_shared/a_action.cpp.o: In function `A_Unblock(AActor*, bool)':
/home/travis/build/coelckers/gzdoom/src/g_shared/a_action.cpp:64: undefined reference to `AActor::GetDropItems() const'
CMakeFiles/zdoom.dir/scripting/vmthunks_actors.cpp.o: In function `AF_AActor_Distance2DSquared(VMValue*, int, VMReturn*, int)':
vmthunks_actors.cpp:(.text+0x6ab): undefined reference to `AActor::PosRelative(AActor const*) const'
CMakeFiles/zdoom.dir/scripting/vmthunks_actors.cpp.o: In function `AF_AActor_Distance3DSquared(VMValue*, int, VMReturn*, int)':
vmthunks_actors.cpp:(.text+0x75f): undefined reference to `AActor::PosRelative(AActor const*) const'
CMakeFiles/zdoom.dir/scripting/vmthunks_actors.cpp.o: In function `AF_AActor_Vec3To(VMValue*, int, VMReturn*, int)':
vmthunks_actors.cpp:(.text+0x850): undefined reference to `AActor::PosRelative(AActor const*) const'
CMakeFiles/zdoom.dir/scripting/vmthunks_actors.cpp.o: In function `AF_AActor_Vec2To(VMValue*, int, VMReturn*, int)':
vmthunks_actors.cpp:(.text+0x930): undefined reference to `AActor::PosRelative(AActor const*) const'
CMakeFiles/zdoom.dir/scripting/vmthunks_actors.cpp.o: In function `AF_AActor_DistanceBySpeed(VMValue*, int, VMReturn*, int)':
vmthunks_actors.cpp:(.text+0xa00): undefined reference to `AActor::PosRelative(AActor const*) const'
CMakeFiles/zdoom.dir/scripting/vmthunks_actors.cpp.o:vmthunks_actors.cpp:(.text+0xad3): more undefined references to `AActor::PosRelative(AActor const*) const' follow
CMakeFiles/zdoom.dir/scripting/vmthunks_actors.cpp.o: In function `AF_AActor_PosRelative(VMValue*, int, VMReturn*, int)':
vmthunks_actors.cpp:(.text+0x1200): undefined reference to `AActor::PosRelative(sector_t*) const'
CMakeFiles/zdoom.dir/scripting/vmthunks_actors.cpp.o: In function `AF_AActor_ClearInterpolation(VMValue*, int, VMReturn*, int)':
vmthunks_actors.cpp:(.text+0x127d): undefined reference to `AActor::ClearInterpolation()'
vmthunks_actors.cpp:(.text+0x1298): undefined reference to `AActor::ClearInterpolation()'
CMakeFiles/zdoom.dir/scripting/vmthunks_actors.cpp.o: In function `AF_AActor_GetBobOffset(VMValue*, int, VMReturn*, int)':
vmthunks_actors.cpp:(.text+0x135a): undefined reference to `AActor::GetBobOffset(double) const'
CMakeFiles/zdoom.dir/scripting/vmthunks_actors.cpp.o: In function `AF_AActor_Distance2D(VMValue*, int, VMReturn*, int)':
vmthunks_actors.cpp:(.text+0x222b): undefined reference to `AActor::PosRelative(AActor const*) const'
