If this is done within the intermission code, both intermission and menu will write to the same global variables and destroy their data, this became very apparent when it altered the screen scale for the conversation.
Now, all menus will use the same scale, i.e. it only depends on the screen width and a base size of 640. This nearly universally yields better results than trying to make a 320x200 screen fit.
The only exceptions to this are the intermission screens and the level summary. These, unlike the menu need to try to make a 320x200 screen fit, but without all the hackery that was present to adjust the menu display.
Note that since this affects globally visible script variables, both the intermission and summary drawers will not use their own set but instead temporarily override the global setting as long as they run their own code.
Changing the use of variables here might cause much worse problems with menu code so it wasn't attempted
* re-added screen blends for images from the hardware renderer.
* moved all postprocessing of the image out of the renderers.
* cleaned out a large piece of cruft for handling the palette in the frame buffer class. This was all a remnant of the old paletted backend that no longer exists. Nowadays the screen blend is just a postprocessing effect drawn over the 3D screen, there is no need to maintain any of it as global state anymore.
* since the engine doesn't produce paletted screenshots anymore there is no need to have handling for it in the generation code. This depended on otherwise obsolete information so it got removed along with that information.
currentUILevel is now primaryLevel.
For ZScript, currentVMLevel was added. This is also exported as 'level' and will change as needed.
This also means that no breaking deprecations will be needed in the future, because in order to sandbox a level only 4 variables need to be handled: level, players, playeringame and consoleplayer.
The remaining global variables are not relevant for the level state.
The static 'level' has been mostly removed from the code except some places that still need work.
This made reviewing the code for accessing the global state hard, because the doomdef.h contains mainly constants, this particular item was the only thing in there that represents actual engine state.
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.
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 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 setup has been a constant source of problems so now I reviewed all uses of FName to make sure that everything that needs to be initialized is done manually.
This also merges the player_t constructor into the class definition as default values.
Lots of this was still laid out for DirectDraw. This removes most of Begin2D so that it can be done more cleanlz.
Note that this commit renders weapon sprites and screen blends incorrectly. Those will be fixed in an upcoming commit.
src/gl/renderer/gl_renderer.cpp:775:39: warning: comparison of two values with different enumeration types ('F2DDrawer::ETextureDrawMode' and 'TexMode') [-Wenum-compare]
src/gl/renderer/gl_renderer.cpp:776:39: warning: comparison of two values with different enumeration types ('F2DDrawer::ETextureDrawMode' and 'TexMode') [-Wenum-compare]
src/gl/renderer/gl_renderer.cpp:777:39: warning: comparison of two values with different enumeration types ('F2DDrawer::ETextureDrawMode' and 'TexMode') [-Wenum-compare]
src/gl/renderer/gl_renderer.cpp:778:45: warning: comparison of two values with different enumeration types ('F2DDrawer::ETextureDrawMode' and 'TexMode') [-Wenum-compare]
src/gl/renderer/gl_renderer.cpp:779:40: warning: comparison of two values with different enumeration types ('F2DDrawer::ETextureDrawMode' and 'TexMode') [-Wenum-compare]
src/gl/renderer/gl_renderer.cpp:780:45: warning: comparison of two values with different enumeration types ('F2DDrawer::ETextureDrawMode' and 'TexMode') [-Wenum-compare]
src/v_draw.cpp:1144:51: warning: '&' within '|' [-Wbitwise-op-parentheses]
src/textures/texture.cpp:1050:20: warning: comparison of integers of different signs: 'int' and 'unsigned long' [-Wsign-compare]
src\intermission\intermission.cpp(80): warning C4101: 'lumpnum': unreferenced local variable
This removes the entire palette switch and all the special checks to ensure that no menu can be drawn over this image.
Instead it gives this texture its special palette in the texture manager so that the proper image is created right away.
I decided against exposing this as an editing feature because it is far too specific to this particular image and the raw page format it uses.
A quick check of /idgames shows no project ever replacing it - especially no ZDoom-based project - so no extended handling is needed to make this work with other texture formats.
This was done mainly to reduce the amount of occurences of the word FTexture but it immediately helped detect two small and mostly harmless bugs that were found due to the stricter type checks.
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 addresses the main issue with TObjPtr, namely that using it required pulling in the entire class hierarchy in basic headers like r_defs which polluted nearly every single source file in the project.
This will store class meta properties in a separate memory block so that it won't have to muck around with PClass - which made the implementation from the scripting branch relatively useless because extending the data wasn't particularly easy and also not well implemented. This can now be handled just like the defaults.
This means that with the exception of 3 pointers the DrawTexture interface only accepts numeric values now.
Still need to get rid of the last 3 to have this ready for scripting.
This was done to ensure it can be properly overridden in scripts without causing problems when called during engine shutdown for the type and symbol objects the VM needs to work and to have the scripted version always run first.
Since the scripted OnDestroy method never calls the native version - the native one is run after the scripted one - this can be simply skipped over during shutdown.
Needless to say, this is simply too volatile and would require constant active maintenance, not to mention a huge amount of work up front to get going.
It also hid a nasty problem with the Destroy method. Due to the way the garbage collector works, Destroy cannot be exposed to scripts as-is. It may be called from scripts but it may not be overridden from scripts because the garbage collector can call this function after all data needed for calling a scripted override has already been destroyed because if that data is also being collected there is no guarantee that proper order of destruction is observed. So for now Destroy is just a normal native method to scripted classes
