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.
