Since it forwards directly to FindState and has no script bindings there is no need to keep it, it'd only complicate the full scriptification of the weapon class if it stuck around.
* it was never saved in savegames, leaving the state of dead bodies undefined
* it shouldn't be subjected to pointer substitution because all it contains is old dead bodies, not live ones.
Since the only thing it gets used for is swapping out PlayerPawns it can safely skip all global variables that never point to a live player, which allowed to remove quite a bit of code here that stood in the way of scriptifying more content
Null pointers must be allowed and non-object pointers which are not null must be explicitly checked for because the code could crash on them when performing a static_cast on an incorrect type.
For the varargs functions that used the Type field to validate their parameters, now a hidden additional argument is passed which contains a byte array with the type info for the current call's arguments. Since this is static per call location it can be better prepared once when the code is being compiled instead of being put in a runtime created array for each invocation. Everything else uses the per-function instance of the same data.
The only thing that still needed the type field with a VMValue is the defaults array, so this uses a different struct type now to store its data.
Currently used for loading parameters into registers.
For checking parameters of native functions some more work is needed to get the info to the function. Currently it doesn't receive the function descriptor.
src/scripting/vm/jit_call.cpp:164:38: warning: offset of on non-standard-layout type 'VMScriptFunction' [-Winvalid-offsetof]
src/scripting/vm/jit_load.cpp:87:50: warning: offset of on non-standard-layout type 'DObject' [-Winvalid-offsetof]
src/scripting/vm/jit_load.cpp:96:50: warning: offset of on non-standard-layout type 'DObject' [-Winvalid-offsetof]
src/scripting/vm/jit_load.cpp:257:53: warning: offset of on non-standard-layout type 'DObject' [-Winvalid-offsetof]
The amount of support code for this minor optimization was quite large and this stood in the way of streamlining the VM's calling convention, so it was preferable to remove it before moving on.
This reuses the FTexCoordInfo class the hardware renderer had been using to calculate wall texture offsetting.
The software renderers still need this sorted out to bring them in line with the rest of the code, though, but they do not have this code sufficiently well organized to make this a straightforward task.
With a proper count value available this can be done properly. The only relevant targets are the jumps immediately succeeding the IJMP instructions, nothing else.
This removes the last non-vararg cases where a native VM function checks 'numparam'. As of this commit all function calls will pass the complete list of arguments.
This isn't used for the 3 action function calls because it requires an array allocation which would be a bit too costly for something as frequently called as action functions.
They will need a different approach.
This allows retaining the functionality, even if for the JIT compiler's benefit all default arguments are pushed onto the stack instead of reading them from the defaults array.
There were some issues here:
* a check for mismatching count is too strict because it is legal to omit return values
* it failed to detect returning multiple values in a single expression.
This can happen if a state that's retrieved with FindState gets used with a different actor type and can lead to hard to trace problems if not checked.
This will now both exclude floor caps when only ceiling elements are used and everything outside the bounding box of active portal lines.
Hopefully this is enough to fix the issues with portal caps but of course it is not foolproof if someone just makes the right setup.
The main reason is to unify the portal hierarchy again. The split into a hardware independent and a hardware dependent part turned out to be unnecessary and complicated matters.
Another issue was that the new stencil setup code was having a few subtle problems, so this recreates the original ones with indirect API calls.
- Works similarly to CanCollideWith.
- Passive means the caller is trying to be resurrected by 'other'.
- Non-passive means the caller is trying to resurrect 'other'.
* Colors can npw be defined per sidedef, not only per sector.
* Gradients can be selectively disabled or vertically flipped per wall tier.
* Gradients can be clamped to their respective tier, i.e top and bottom of the tier, not the front sector defines where it starts.
The per-wall colors are implemented for hardware and softpoly renderer only, but not for the classic software renderer, because its code is far too scattered to do this efficiently.
Apparently they can indeed happen with broken map setups like isolated linedefs somewhere in the wild (see Strife MAP08.)
Although they are a problem for triangulation, this isn't what sections get used for currently so it's of no real concern.
In case this is needed later their work data gets marked as 'bad' for the time being.
Until now this wasn't doable because these could have come from hw_FakeFlat which only were local copies on the stack.
With the recent change these faked sectors live long enough so that they can be passed around here.
src/p_udmf.cpp:2052:6: error: no matching member function for call to 'OpenMem'
src/sc_man.h:24:7: note: candidate function not viable: expects an l-value for 2nd argument
src/sc_man.h:23:7: note: candidate function not viable: requires 3 arguments, but 2 were provided
src/resourcefiles/file_directory.cpp:198:32: error: use of undeclared identifier 'Filename'; did you mean 'FileName'?
An exception is made for the sprite drawer which needs to call this in the worker thread on some occasions for as-yet unprocessed sectors.
This case may not alter the cache to avoid having to add thread synchronization to it.
The main reason for this change is that pointers to such manipulated sectors can now be considered static in the renderer.
Due to them being short lived local buffers it was not possible to carry them along with the render data for information retrieval.
Otherwise this may contain residual data from the last call.
One can only hope that this doesn't cause other side effects - this entire code is one horrendous mess of bad ideas.
This portal got fixed in a later re-release of KDiZD and no other portal needs this runtime fix to my knowledge.
The main problem here is that this runtime fix requires some manipulation of the render data that does not work anymore.
Should other maps need this fix as well they are probably best served with a compatibility entry.
This also removes one piece of code that was used to cope with the missing clip planes on old ATI cards, so support for those will most likely have to be dropped in the near future.
A section is a continuous part of a sector or in some case of several nearby continuous parts. For sectors with far away parts multiple sections will be created, especially when they lie in disjoint parts of the map.
This is mainly supposed to cut down on time for linking dynamic lights. Since they need to traverse subsectors to find all touching sidedefs a more coarse data structure that only contains the info needed for this is more suitable. In particular, this does not contain any intra-sector lines, i.e. those with both sides in the same sector.
- Added a function to the Actor class to get its spawn time relative to the current level.
- Added spawn time information to the output of the "info" console command.
src/hwrenderer/dynlights/hw_lightbuffer.h:51:29: warning: comparison between signed and unsigned integer expressions
[-Wsign-compare]
src/hwrenderer/scene/hw_renderstate.h:196:44: warning: operation on '((FRenderState*)this)->FRenderState::mVertexOffsets[0]' may
be undefined [-Wsequence-point]
This had absolutely no sanity checks and unconditionally picked the source texture if one existed.
It should only be done for wall textures, only for those defined in TEXTUREx and only for those where the scale is identical with the underlying texture.
- Uses the same code as Thing_ProjectileIntercept to aim and move the projectile.
- targ: The actor the caller will aim at.
- speed: Used for calculating the new angle/pitch and adjusts the speed accordingly. Default is -1 (current speed).
- aimpitch: If true, aims the pitch in the travelling direction. Default is true.
- oldvel: If true, does not replace the velocity with the specified speed. Default is false.
- Split the code from Thing_ProjectileIntercept and have that function call VelIntercept.
Calling the old method with a pointer to an array of unspecified length 'dirty' would be an understatement.
Now it uses a TArray to store the single elements
I thought this wasn't needed but apparently the buffer refactoring caused this not to be done automatically anymore.
Best have it once at the start of each frame where the cost is negligible.
Since the job nodes were already taken from a static array, the added linked list isn't really needed. All we need is a read and a write pointer into the array, This can even be done without a spinlock as long as we assume that the list never overflows.
