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.
The destination mode sould be 'One', not 'InvSrcColor'.
Now both of these are available as explicit modes, not just through the optional mapping.
# Conflicts:
# src/hwrenderer/scene/hw_sprites.cpp
# src/r_data/renderstyle.cpp
# src/r_data/renderstyle.h
With additional render styles from " - abstraction of render style in render state.". drfrag
# Conflicts:
# src/r_data/renderstyle.cpp
# src/r_data/renderstyle.h
With additional render styles from "- made the screen blend work for the software renderer.". drfrag
* 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.
# Conflicts:
# src/hwrenderer/scene/hw_renderstate.h
# src/hwrenderer/scene/hw_walls.cpp
# Conflicts:
# src/gl/scene/gl_walls_draw.cpp
Testing with Adventures of Square this mostly works, but it is clear that a list of old and deleted CVARs still needs to be added so that any items referring to those can be eliminated as well. Some stuff is still slipping through that refers to features which no longer exist.
This is to ensure that the Class pointer can be set right on creation. ZDoom had always depended on handling this lazily which poses some problems for the VM.
So now there is a variadic Create<classtype> function taking care of that, but to ensure that it gets used, direct access to the new operator has been blocked.
This also neccessitated making DArgs a regular object because they get created before the type system is up. Since the few uses of DArgs are easily controllable this wasn't a big issue.
- did a bit of optimization on the bots' decision making whether to pick up a health item or not.
This is only the parsing part, the arrays are not yet getting evaluated.
This required quite a hacky workaround because the gramma couldn't be made to accept the rule. The scanner will check if a 'static' token is immediately followed by a 'const' token and will combine both to a new 'staticconst' token that does not create conflicts with other rules.
This method was chosen because it avoids adding variable declarations to the global namespace which would have required a lot more work while polluting the grammar.
This way the global variables can be handled by a small bit of special coding in the struct generator.
- handle these powerups by actual item checks instead of cheat flags. (The same should also be done for the Frightener and Buddha but those are a bit more complex because they are also real cheats.)